- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
// histogram_data.c 550 Kb
int n_records = 100000;
unsigned char data[] = {
215, 100, 200, 204, 233, 50 , 85 , 196, 71 , 141, 122, 160, 93 , 131, 243, 234, 162, 183, 36 , 155,
4 , 62 , 35 , 205, 40 , 102, 33 , 27 , 255, 55 , 131, 214, 156, 75 , 163, 134, 126, 249, 74 , 197,
134, 197, 102, 228, 72 , 90 , 206, 235, 17 , 243, 134, 22 , 49 , 169, 227, 89 , 16 , 5 , 117, 16 ,
60 , 248, 230, 217, 68 , 138, 96 , 194, 131, 170, 136, 10 , 112, 238, 238, 184, 72 , 189, 163, 90 ,
176, 42 , 112, 225, 212, 84 , 58 , 228, 89 , 175, 244, 150, 168, 219, 112, 236, 101, 208, 175, 233,
123, 55 , 243, 235, 37 , 225, 164, 110, 158, 71 , 201, 78 , 114, 57 , 48 , 70 , 142, 106, 43 , 232,
26 , 32 , 126, 194, 252, 239, 175, 98 , 191, 94 , 75 , 59 , 149, 62 , 39 , 187, 32 , 203, 42 , 190,
19 , 243, 13 , 133, 45 , 61 , 204, 187, 168, 247, 163, 194, 23 , 34 , 133, 20 , 17 , 52 , 118, 209,
146, 193, 13 , 40 , 255, 52 , 227, 32 , 255, 13 , 222, 18 , 1 , 236, 152, 46 , 41 , 100, 233, 209,
91 , 141, 148, 115, 175, 25 , 135, 193, 77 , 254, 147, 224, 191, 161, 9 , 191, 213, 236, 223, 212,
250, 190, 231, 251, 170, 127, 41 , 212, 227, 19 , 166, 63 , 161, 58 , 179, 81 , 84 , 59 , 18 , 162,
57 , 166, 130, 248, 71 , 139, 184, 28 , 120, 151, 241, 115, 86 , 217, 111, 0 , 88 , 153, 213, 59 ,
172, 123, 123, 78 , 182, 46 , 159, 10 , 105, 178, 172, 163, 88 , 47 , 155, 160, 187, 84 , 189, 51 ,
235, 175, 167, 65 , 136, 22 , 66 , 224, 175, 23 , 28 , 92 , 147, 151, 170, 73 , 198, 73 , 84 , 48 ,
251, 0 , 211, 84 , 48 , 111, 245, 235, 195, 178, 31 , 175, 98 , 198, 241, 234, 220, 52 , 203, 140,
// over 5000 строк подобного
int expected_results[] = {
404, 389, 376, 394, 376, 342, 364, 364, 383, 396,
412, 409, 394, 409, 405, 383, 379, 401, 377, 400,
383, 410, 386, 383, 418, 416, 406, 349, 390, 388,
393, 372, 386, 386, 400, 384, 404, 355, 400, 361,
398, 371, 389, 383, 406, 414, 364, 389, 418, 391,
404, 396, 390, 397, 375, 389, 387, 392, 368, 430,
407, 387, 380, 380, 383, 352, 386, 413, 435, 413,
358, 453, 436, 409, 419, 393, 423, 398, 407, 372,
399, 353, 370, 389, 399, 376, 395, 439, 412, 379,
404, 374, 392, 393, 366, 377, 374, 395, 402, 380,
422, 407, 379, 398, 376, 410, 376, 392, 374, 409,
415, 382, 411, 398, 379, 385, 383, 374, 421, 371,
359, 403, 373, 396, 365, 365, 382, 383, 352, 399,
367, 439, 401, 418, 407, 403, 392, 373, 385, 374,
389, 365, 414, 415, 360, 384, 387, 381, 400, 410,
400, 406, 385, 395, 373, 381, 419, 362, 383, 399,
424, 379, 394, 401, 371, 426, 376, 375, 383, 370,
405, 402, 372, 404, 364, 419, 390, 376, 368, 405,
393, 386, 402, 393, 420, 388, 380, 364, 412, 383,
411, 357, 412, 377, 346, 389, 380, 371, 393, 408,
386, 425, 392, 338, 373, 382, 380, 365, 379, 394,
379, 378, 415, 394, 352, 378, 417, 403, 407, 388,
390, 433, 352, 394, 398, 407, 397, 409, 419, 378,
387, 359, 406, 384, 403, 385, 411, 418, 408, 371,
384, 386, 392, 422, 377, 399, 364, 381, 362, 379,
393, 383, 381, 400, 434, 404};
// example_vectors.c - 1.8 Mb
int vector_size=100000;
int vector_a[] = {
215 , 100 , 200 , 204 , 233 , 50 , 85 , 196 , 71 , 141 , 122 , 160 , 93 , 131 , 243 , 234 , 162 , 183 , 36 , 155 ,
4 , 62 , 35 , 205 , 40 , 102 , 33 , 27 , 255 , 55 , 131 , 214 , 156 , 75 , 163 , 134 , 126 , 249 , 74 , 197 ,
134 , 197 , 102 , 228 , 72 , 90 , 206 , 235 , 17 , 243 , 134 , 22 , 49 , 169 , 227 , 89 , 16 , 5 , 117 , 16 ,
60 , 248 , 230 , 217 , 68 , 138 , 96 , 194 , 131 , 170 , 136 , 10 , 112 , 238 , 238 , 184 , 72 , 189 , 163 , 90 ,
176 , 42 , 112 , 225 , 212 , 84 , 58 , 228 , 89 , 175 , 244 , 150 , 168 , 219 , 112 , 236 , 101 , 208 , 175 , 233 ,
123 , 55 , 243 , 235 , 37 , 225 , 164 , 110 , 158 , 71 , 201 , 78 , 114 , 57 , 48 , 70 , 142 , 106 , 43 , 232 ,
26 , 32 , 126 , 194 , 252 , 239 , 175 , 98 , 191 , 94 , 75 , 59 , 149 , 62 , 39 , 187 , 32 , 203 , 42 , 190 ,
19 , 243 , 13 , 133 , 45 , 61 , 204 , 187 , 168 , 247 , 163 , 194 , 23 , 34 , 133 , 20 , 17 , 52 , 118 , 209 ,
146 , 193 , 13 , 40 , 255 , 52 , 227 , 32 , 255 , 13 , 222 , 18 , 1 , 236 , 152 , 46 , 41 , 100 , 233 , 209 ,
91 , 141 , 148 , 115 , 175 , 25 , 135 , 193 , 77 , 254 , 147 , 224 , 191 , 161 , 9 , 191 , 213 , 236 , 223 , 212 ,
250 , 190 , 231 , 251 , 170 , 127 , 41 , 212 , 227 , 19 , 166 , 63 , 161 , 58 , 179 , 81 , 84 , 59 , 18 , 162 ,
57 , 166 , 130 , 248 , 71 , 139 , 184 , 28 , 120 , 151 , 241 , 115 , 86 , 217 , 111 , 0 , 88 , 153 , 213 , 59 ,
172 , 123 , 123 , 78 , 182 , 46 , 159 , 10 , 105 , 178 , 172 , 163 , 88 , 47 , 155 , 160 , 187 , 84 , 189 , 51 ,
235 , 175 , 167 , 65 , 136 , 22 , 66 , 224 , 175 , 23 , 28 , 92 , 147 , 151 , 170 , 73 , 198 , 73 , 84 , 48 ,
// over 15000 cтрок
Follow us!
>Сишное ООП - данные и код размещены вместе
Суть алгоритмов STL C++ в разделении кода и данных. Одна из сторон обобщённого программирования.
Элсо про гномика не понял.
Баян же
Если без зелёного, то это не совсем то. Одно из различий структурного/функционального программирования vs ООП - первые два подхода рассматривают данные и алгоритмы их обработки как независимые явления. ООП же подразумевает слияния данных и методов в единое понятие объекта. Собственно, по этому поводу и был мой не особо успешный зелёный тезис.
Вот он, крах объектной парадигмы. Наглядно. ''
Интересно как моя ава выглядит.
поставлю Colinux
приду домой и загружу линух. Wait me please.
Буду качать Lynx, установлю его и разбираться что там и как.
fixed
А я слышал труЪ-парни собирают из сырцов.
Но ты вместо того чтобы наговариваться лучше б скрин браузера выложил, под которым сидишь.
Одно другому не мешает
Это же настоящий BSDM-way.
Ну во дворе детишки и не такое говорят. На самом деле это все понты, чтобы отпугнуть настоящих людей из своей элитной группы. Они говорят, что поставили линукс и хотят выглядеть круче, поэтому рассказывают всякие сказки, типа: "я компиляю ведро 7 дней в неделю и САМ исправляю в нем ошибки компиляции" или "я сделал так, что мой линукс сам мне заваривает кофе, а психоаналитик из емакса исправляет мои нервопроблемы, вызванные настройкой плагина психоаналитика для емакса" или "я запустил скрипт ускорения ведра, создающий рамдиск со свопом, а сам рамдиск я разместил в гигантской видеопамяти моей топовой MsDirectX12-совместимой видеокарте, чтобы хоть как-то начать её использовать".
> Интересно как моя ава выглядит.
Как-то так: http://rghost.ru/40813462.view
Лол.
На словах-то ты Lynx-bro, а на деле ты гумно.
> Я всё ещё на работе.
А детский труд у нас не запрещен? ;)
:)
В ООП мы можем задать единый интерфейс для фигур, и добавление новых фигур будет легко и изящно вписываться в систему. Но как только мы решим добавить в интерфейс новую операцию, нам придётся изменить все реализации.
Если мы используем процедурный или функциональный подход, то фигуры представляют из себя структуры или АТД соответственно. Все операции над ними выражаются через функции, каждая из которых проверяет тип фигуры и выполняет нужные действия. Добавление новых операций не затрагивает систему, но при добавлении новых фигур приходится переписывать все функции в системе.
Итераторы и алгоритмы stl демонстрируют сочетание двух подходов.
А как ООП тут поможет? Если старые функции должны работать по-старому, то они точно так же смогут работать и над новыми фигурами, если же некоторые функции для новых фигур придётся переписать, то переписать их придётся в любой парадигме.
> А как ООП тут поможет?
Если у тебя есть абстрактный класс Shape с методами area, perimeter, contains_point, ... и есть подклассы Rectangle, Triangle, Circle, то добавление фигуры Poligon можно выполнить без переписывания существующего кода.
Если для нового типа логика другая, то один хуй придётся дописывать.
А полиморфизм на что? Если ты реализовал Shape так, что у тебя в нём содержится енум ShapeKind, то да, ООП тебе не поможет.
Что полиморфизм? Компилятор за тебя догадается, как описать код многоугольника, потому что полиморфизм? Или он всего-навсего подставит другую готовую функцию (причём скорее всего по втбл) в готовый метод?
Понятно, что для многоугольника придётся писать реализацию всех операций. Я о том, что при этом не нужно модифицировать код, относящийся к логике операций для других фигур. Т.е. добавляешь новый класс, реализуешь методы, PROFIT. В процедурном стиле тебе нужно добавить новую структуру и поправить ВСЕ существующие функции (что не очень круто, особенно, если у тебя нет сорцов).
С другой стороны, если тебя интересует не добавление новых фигур, а новых операций, ситуация обратная - в ООП тебе нужно изменить ВСЕ классы, в процедурщине достаточно дописать новую финкцию с очередным switch/case.
Ну и массив объектов разного типа (не ссылок, а объектов) ты не создашь на ООП, а на вариантых записях - как нефиг.
каждая из которых будет занимать место минимум равное размеру максимально толстой записи + накладные расходы
а потом, когда библиотека, знающая о 10 типах и создавшая такой массив, лежит уже в бинарном виде, ты добавляешь в иерархию 11й, чуть больше чем любой другой, и у тебя всё накрывается медным тазом
больше свободы в этих реализациях!
Зачастую это почти не влияет на размер.
> а потом, когда библиотека, знающая о 10 типах и создавшая такой массив, лежит уже в бинарном виде
С библиотеками, уже лежищими в бинарном виде, вообще тяжело, хрен что изменишь.
В функционалщине использовали алгебраические типы. Получилось много короче. Но на деле - это лишь утка. Эти АТД классы ожидает теже проблемы при попытке расширения иерархии, что и процедурный подход. Ну и прочие проблемы алгебраических типов, что обсуждались ниже
А почему нельзя дописать «Тор — хуй»?
Для этого не ООП нужно, а жёсткое разделение интерфейса от реализации.
Кто знает, как этот нёх обходить? Минимально пользоваться алгебраическими типами? Тогда это будет даже хуже ооп. В том же хахахакселе даже структур нет (впрочем я не про хаксел). А в других фяп пользоваться нормальным ооп можно обычно, но теряешь многие плюсы фп, тк в них оно прикручено как-то сбоку. Разве что несколько многословно, но более или менее красиво ооп прикручено в динамическитипизированные фяп или в OCaml/F#, хотя в последних тоже далеко не все красиво с ооп.
Не заменяют, они не для этого предназначены. В функциональных языках для этого есть другие инструменты. В CL есть обобщённые функции и довольно своеобразное ООП (+ мультиметоды), в Haskell есть typeclasses, в StandardML есть signatures.
В чем суть?
Есть:Объявятся конструктор Foo :: Int -> String -> Foo и два метода: fooID :: Foo -> Int, fooName :: Foo -> String.
> Посмотри на алгебраические типы
Алгебраический тип это самый обычный union с дополнительным полем, позволяющим отличить какой из вариантов сейчас активен. С такой конструкцией везде работают одинаково - либо крестоблядским свичом, либо паскалевским кейсом, либо хаскелевым паттернматчингом. Никакого ООП тут нет и в помине. Да и расширяемость у ADT оставляет желать лучшего.
ООП в хаскеле это именно его классы. Когда я описываю тип данных, и говорю что он является инстансом какого-либо класса (или классов).
selfix
Жаль, что классов типов нет не в Ocaml\F#, не в Nemerle (за чистый Ocaml 100% не ручусь, но вроде нет). Как там с этим в Scala?
Говорил же 100 раз, реализуются через имплиситы
Имплисит - оказывается это это обычный параметр по умолчанию. Придумали же новое название... Ох уж эти функциональщики... Вместо слова interface придумывают новое - type classes и так со всеми словами.
Это... А менее многословно не дано было сделать? Зачем этот говносинтаксис? Ну и не привычно оно.
Сделали бы:
1)Что-то я боюсь, что если вдруг высыпится неодназначность - на большом проекте с большим кол-вом использования одного имплисита - кодер начнет горевать.
2)Реализовывать по классу на каждый метод интерфейса (пусть и анонимному) как-то очень жестоко.
http://habrahabr.ru/company/tcsbank/blog/147759/
Хотелось бы взять лямбдочку или локальную функцию с замыканием. А пока это похоже на закат солнца вручную. По сравнению с Java, Scala - великий автоматизатор, а вот по сравнению с фяп - ололо я все делаю руками.
Когда дело доходит до функциональных конструкций, Haskell гораздо более простой и понятный язык, чем Scala. Я как-то пробовал реализовать эти typeclasses - трэш, угар, содомия и многа букав.
Это на хаскеле то? Вроже наоборот мало букф.
чтобы такого не случалось, stl демонстрирует хороший выход разделения структур и алгоритмов.
з.ы.: жаль, что санобляди в жабе не подумали сделать подобие stl, а размазали некие алгоритмы по утилитным классам. только apache-commons и спасает.
не поверите, в j2se даже сейчас нет такой элементарной операции, как join, грррр.
по теме - портянка цифр это норма
ясен хуй она вся из внешнего генератора
такое вот метапрограммирование ахахах
Для embended или system.
И похоже случай не из этих.
> особенно на андроиде, где файл хуй знает где и не факт что он не заархивирован и что не придётся ещё хуй знает как его открывать
С кирпичами цвета (164,198,57) за плечами...
На крайний случай можно написать пару-тройку строк кода, которые возьмут этот массив, преобразуют его как надо, и выдадут опять же в виде сяшного кода...