- 1
virtual ~T() {}
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+10
virtual ~T() {}
нахуя?
у всех наследников то же самое и наличие чего-либо внутри не предполагается
Первая ссылка по гуглозапросу "c++ mersenne twister" выдаёт склад оопиозного говнокода:
http://www.bedaux.net/mtrand/
TarasB 19.12.2012 13:35 # +1
В разных местах разная реализация.
1.
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/CODES/MTARCOK/mt19937ar-cok.c
2.
http://www.cplusplus.com/forum/beginner/79754/
Блядь, это разные вещи, какую же выбрать-то?
Походу на крестосайте забыли написать
(state[i]>>31)<<31
bormand 19.12.2012 16:53 # +2
state[i] & TARAS_B_CONSTANT
> (state[(i+1)%VEC_L]<<1)>>1
state[(i+1) % VEC_L] & ~TARAS_B_CONSTANT
Steve_Brown 20.12.2012 12:45 # 0
bormand 19.12.2012 13:44 # +1
> Нахуя?
Чтобы у класса был виртуальный деструктор. Если у базового класса не будет виртуального деструктора, ты получишь много приятных ощущений при удалении потомка через указатель на тот самый базовый класс...
TarasB 19.12.2012 13:45 # +1
Нахуй вообще хоть в одном месте иерархии в данном случае усрался хоть какой-то деструктор?
bormand 19.12.2012 13:51 # 0
А вот нахуя тут иерархия и наследования - я не знаю. По хорошему тут аггрегация нужна, а не наследование, т.к. имеем отношение "реализован через MTRand_int32" а не "является MTRand_int32".
TarasB 19.12.2012 13:54 # 0
> delete mt;
Ну поюзает и что? Деструкторы-то блядь пустые и никогда, уверен, в них не появится ни-че-го!
bormand 19.12.2012 14:02 # +4
А первый можно убрать только в том случае, если в документации явно написать - "тот кто будет юзать эту недоиерархию как иерархию - тот пидор".
Еще раз повторюсь. Отношение "A реализован через B" это совсем не повод для публичного наследования B от A. А если уж поюзал паблик наследование - будь добр, напиши виртуальный деструктор, не расставляй грабли другим.
P.S. Не написав виртуальный деструктор в иерархии ты нарушаешь принцип подстановки Лисков (один из принципов SOLID), т.к. в результате нельзя подставить объект вместо его предка.
bormand 19.12.2012 14:07 # +6
bormand 19.12.2012 14:17 # +1
Сравни:
http://ideone.com/2Ea8d4
http://ideone.com/5lB2cR
Не замечаешь кое-какой проблемы?
TarasB 19.12.2012 14:35 # 0
Тут же даже неподов в данных нет.
LispGovno 19.12.2012 15:44 # +1
Даже если деструкторы пустые и использовалась перегрузка операторов new\delete, то если забыть виртуальные деструкторы в базовом, то delete может вызоватся не торт.
LispGovno 19.12.2012 15:46 # 0
От этой иерархии могут отнаследоваться и всё пойдет псу под хвост, если там деструкторы не пустые будут
TarasB 19.12.2012 15:51 # +1
bormand 19.12.2012 16:23 # 0
P.S. По хорошему - из кода, который ты кидал в топике, нужно выкинуть всю эту ебучую иерархию к хуям, и собрать все это в один простой и понятный класс... (При этом не забыв написать в доке, что наследоваться от него нельзя). Тогда и деструктор не нужен.
TarasB 19.12.2012 16:27 # 0
Ну дык а я о чём.
Вот открыл я код, увидел МТ в виде иерархии, и какой вопрос сразу же возник у меня? Правильно, "нахуя".
Ну и статические члены, да, но я типа честный рекламщик, выдаю интригующие вещи, а самые вкусные оставляю только для тех, кто всё-таки посмотрит, а то некоторые все фишки в рекламе показывают и потом смотреть нечего, некруто нифига.
bormand 19.12.2012 16:38 # 0
P.S. Код в твоем первом комменте под номером 1 это я так понимаю код японца-автора МТ? Тогда он и корректен.
TarasB 19.12.2012 17:22 # 0
bormand 19.12.2012 17:32 # 0
Но насколько я понимаю http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html это официальный сайт МТшки и попутно хоумпага Makoto Matsumoto, который является одним из авторов.
bormand 19.12.2012 17:37 # 0
Yuuri 20.12.2012 16:26 # +3
zim 20.12.2012 18:08 # +3
bormand 20.12.2012 18:22 # +1
Yuuri 20.12.2012 19:27 # +2
3.14159265 20.12.2012 19:33 # +3
哲学的問題
suc-daniil 19.12.2012 17:35 # +1
bormand 19.12.2012 17:40 # +2
C++ разные бывают. В каких-то есть, в каких-то нет :P
absolut 19.12.2012 22:03 # 0
LispGovno 19.12.2012 22:21 # 0
LispGovno 19.12.2012 22:22 # 0
krypt 19.12.2012 22:40 # 0
bormand 20.12.2012 05:48 # +1
А вообще с++ под такие контроллеры - это жесть какая-то. Места практически нет, стек маленький и рискует наползти на память... Чисто ради Си с шаблонами?
Prabhakar_Srivastar 01.10.2021 18:04 # 0
absolut 20.12.2012 09:39 # +4
LispGovno 20.12.2012 10:20 # +2
Я бы такого умника уволил, чтобы не игрался на работе. Прикинь потом код с этим блядством комуто придется поддерживать?
krypt 19.12.2012 19:35 # 0
defecate-plusplus 19.12.2012 13:56 # +6
#include <boost/random.hpp>
ну или <boost/random/mersenne_twister.hpp>
там 0 виртуальных методов
roman-kashitsyn 19.12.2012 14:15 # +7
LispGovno 27.12.2012 19:43 # +2
3.14159265 27.12.2012 21:46 # +2
roman-kashitsyn 27.12.2012 23:58 # 0
Хотелось бы услышать аргументированную критику. Не то чтобы я сильно сох по скале (меня больше интересуют решения, чем средства), просто ты нам недавно (http://govnokod.ru/12041) явно продемонстрировал, как прост, элегантен и краток код на Nemerle.
LispGovno 28.12.2012 00:32 # 0
Ну и уже сейчас видна куча ненужного синтаксического сахара, ухудшаещего читабильность из-за ерунды, увеличивающего число способов записи программы и разрушая единый стиль написания кода, без нужды усложняющего компилятор.
Например:
(4 -> "ko") синоним для (4, "ko")
или
obj.method(5) синоним obj method 5 со всеми проблемами: с приоритетами, читабильностью и частичным применением.
или эта любовь все заворачивать в объекты, даже локальные функции, притом не автоматом, а руками, расписывая поэмы
или
это частичное применение аля хаскель:
func (1) ("arg2") (ko) и не лень же кому-то расставлять скобки...
В целом ничего научного, эволюционного, инновационного или революционного, но как замена жабы, побеждающая большинство её жабапроблем - сойдет...
LispGovno 28.12.2012 10:16 # 0
> func (1) ("arg2") (ko)
Правильнее это назвать результатом каррирования, конечно
roman-kashitsyn 28.12.2012 10:50 # 0
Макросы там не особо нужны, и это основная причина того, что их там ещё нет. Продвигают их фанатики типа тебя.
> DSL и прочие метапрограммисткие приемы - на нуле
DSL, к твоему сведению, имеет весьма косвенное отношение к метапрограммированию, можешь почитать Фаулера и DSL in Action по этому поводу.
Очень многого можно добиться одними лишь имплиситами, сохраняя типобезопасность. К примеру, покажи, как реализовать в Nemerle такой код:
> куча ненужного синтаксического сахара
Тот пример, что ты привёл - это не синтаксический сахар, это неявное преобразование, объявленное в Predef - довольно простой и универсальный механизм. Нет специального правила в компиляторе трактовать стрелочку как запятую.
> любовь все заворачивать в объекты, даже локальные функции
Это ограничение жабо-машины - классы и объекты - основные кирпичики. Нужно сказать спасибо скале, что позволяет смотреть на функции как на функции: на значения типа (TI => TO).
> Паттерн-матчинг в скале примитивно слаб
А вот тут можно поподробнее? По-моему, экстракторы рвут классический ПМ, т.к. позволяют сохранить инкапсуляцию, предоставлять View для структур.
LispGovno 28.12.2012 11:06 # 0
Один из немногих способов организации EDSL и DSL: создание кода среды программирования на основе кода *DSL, но конечно не единственный.
>Scalable Component Abstractions
Ковариация и контравариация и обобщённое программирование есть даже C#, не говоря уж о Nemerle. То что в jvm этого нет и поэтому ты принял скалу за божественное проведение - тут ничего не поделать.
>Это ограничение жабо-машины
Вот только с некоторыми из них справляется скала, а так больше ничего нового.
roman-kashitsyn 28.12.2012 11:12 # 0
Ты не читал, а уже делаешь выводы. Это не то, что лежит в основе языка.
> ты принял скалу за божественное проведение
Лол. Это всего лишь очередной язык, со своими преимуществами и недостатками. Как и Nemerle. Он мне нравится потому, что в основе лежит неплохая оригинальная идея, а не просто желание напихать побольше фишечек (по этому пути, с моей точки зрения, сейчас идёт c#).
LispGovno 28.12.2012 11:18 # 0
Я видел там красивые иерархии наследования между всеми типами, по аналогии как с тайпклассами в хаскел. Понятно что это один из способов организации обобщенного программирования, впрочем более медлительный, чем тот, что принят в хаскеле или С++.
roman-kashitsyn 28.12.2012 11:36 # 0
roman-kashitsyn 28.12.2012 11:56 # +3
Идея в том, чтобы предоставлять софт в виде настраиваемых компонентов. При этом компонент - это не какая-то новая сущность. Интерфейс модуля выражается как класс или трэйт. Сам модуль - объект. Модуль может содержать другие модули для своей работы, и т.п.
Конфигурация задаётся не тупыми xml, а наследованием и переопределением ссылок на модули - зависимости (DI с компайл-тайм проверкой наличия всех зависимостей).
Это одна из ключевых (но не единственная) идей, лежащих в основе языка.
LispGovno 28.12.2012 11:09 # 0
Основная причина, почему их там нет - то что в язык уже поздно добавлять макросы, тк изначально язык не разрабатывался, как совместимый с добавлением макросов.
>Очень многого можно добиться одними лишь имплиситами
Метапрограммировать через костыли? В крестах тоже можно метапрограммировать на шаблонах, но каков результат? И то на крестах это делать удобнее.
LispGovno 28.12.2012 11:12 # 0
val duration = 5 seconds
Ну это можно реализовать поразному и с разными целями. Начни с себя и покажи код реализации этого.
roman-kashitsyn 28.12.2012 11:34 # +3
держи
LispGovno 28.12.2012 19:09 # 0
LispGovno 28.12.2012 19:12 # 0
требует окончания s на конце по правилам английского языка
101 seconds
roman-kashitsyn 28.12.2012 19:32 # 0
да, я знаю, ступил
> можно реализовать поразному и с разными целями
давай, порази нас элегантностью и мощью Nemerle, я весь день жду
LispGovno 28.12.2012 19:47 # 0
Scala должна была за тебя проверить правильность окончания. Так делают настоящие EDSL и DSL.
roman-kashitsyn 28.12.2012 20:03 # +2
LispGovno 28.12.2012 20:16 # 0
LispGovno 28.12.2012 20:27 # 0
http://rsdn.ru/forum/src/1823225.all
Чуть позже дам на F#.
wvxvw 28.12.2012 19:57 # +2
Нет, вы не подумайте...
roman-kashitsyn 28.12.2012 20:03 # +3
roman-kashitsyn 28.12.2012 12:11 # +2
Цель - предоставить удобный интерфейс для задания временных интервалов, такие вещи часто реализуются через monkey patching. Твоя очередь.
LispGovno 28.12.2012 11:14 # 0
> А вот тут можно поподробнее? По-моему, экстракторы рвут классический ПМ
Мм. Экстракторы? Пример? Пока я видел только многословный детский сильноограниченный сад в ПМ скалы.
roman-kashitsyn 28.12.2012 11:59 # 0
Поведай об ограничениях, которые ты нашёл, по сравнению с остальными языками, поддерживающими функциональную парадигму.
3.14159265 28.12.2012 20:33 # +2
Я еще тогда хотел упомянуть что возможно Гумно не осилило скалу.
Сам краем глаза поглядываю. Не понравились всякие антиинтуитивные значки, ну ладно там стрелочки - это понятно. Но когда я увидел такое: :: ::: то сразу вспомнил о крестах.
А в немерле мне дико нравится концепция "всё - выражение", и простой язык на макросах.
return try{ "Hi Taras!" } catch {null}
Что может быть удобней?
В целом не скажу что скала сильно в чем-то сливает, и на ней невозможно писать.
По сути срач должен состоять JVM vs CLR. Тут JVM выигрывает по скорости, распространнёности.
LispGovno 28.12.2012 23:39 # 0
В скала тоже многое выражени, в том числе и это.
LispGovno 28.12.2012 23:44 # 0
Это, конечно, эквивалентно следующему:
LispGovno 28.12.2012 23:51 # 0
Естественно, возникает вопрос: как же так, язык объектно-ориентированный; есть методы у объектов — как это всё сочетается с наличием обычных функций, не методов? Ну вот взять, например,
Здесь очевидно, что f1 — метод, а f2 — функция. Какая разница между f1 и f2? Можно ли написать val f3 = f1? Нет, нельзя. Чтобы превратить метод класса в полноправную функцию (т. е., экземпляр типа Function), нужно, формально говоря, добавить подчёркивание после пробела:
val f3 = f1 _
LispGovno 28.12.2012 23:56 # 0
Максимум осилила:
roman-kashitsyn 29.12.2012 00:49 # +1
LispGovno 29.12.2012 05:58 # 0
LispGovno 29.12.2012 06:16 # 0
Хороший годный пример унификации интерфейсов. Желаю такого же всем языкам.
LispGovno 29.12.2012 00:07 # 0
Nemerle:
LispGovno 29.12.2012 00:25 # 0
пример:
Что регекспы (хоть и слабее Немерловых), что XML встроен в язык Scala. Ну и наркоманство разращивать и переусложнять компилятор Scala, хотя вполне можно было не добавлять такую ерунду в язык, а сделать на уровне библиотеки, как это сделано а Nemerle. И это притом, что регекспы в скале не такие красивые и краткие, как в немерле, хотя XML в обоих языках по синтаксису и удобству абсолютно одинаковые.
roman-kashitsyn 29.12.2012 00:52 # 0
Сахар регекспов реализован через экстракторы, т.е. к усложнению компилятора никак не относится.
LispGovno 29.12.2012 00:56 # 0
Nemerle:
LispGovno 29.12.2012 00:30 # 0
roman-kashitsyn 29.12.2012 00:54 # 0
LispGovno 29.12.2012 00:59 # 0
roman-kashitsyn 29.12.2012 01:02 # 0
Гугл ТАМ ==>
LispGovno 29.12.2012 01:26 # 0
LispGovno 28.12.2012 00:38 # 0
Код, как код. Что тебе там не понравилось? Рекурсивная стейт-машина. Ты просто не осилил паттерн.
rOBHOBO3Hblu_nemyx 4 дня назад # 0
Собирать говяшки по сортирам ещё веселее!
P.S. Роман тут чаще всех употреблял слово «говяшки».
MAPTbIwKA 4 дня назад # 0
на селе
rOBHOBO3Hblu_nemyx 4 дня назад # 0
rOBHOBO3Hblu_nemyx 4 дня назад # 0
Возил говяшки!
Zwei!
Возил говяшки!
Drei!
Говночист — заклинатель говна —
Нужен людям во все времена!
guest6 4 дня назад # 0
een, twee, drie
TarasB 19.12.2012 14:36 # 0
defecate-plusplus 19.12.2012 14:52 # +2
но ты реально задумайся над бустом для ndk
TarasB 19.12.2012 14:52 # 0
тонко
defecate-plusplus 19.12.2012 14:55 # +4
буст неизбежен, как победа коммунизма
там могут быть косяки только с исключениями в ndk (в ndk нет исключений, да?)
TarasB 19.12.2012 14:59 # +1
Да, нет, кажется.
И это единственное что в нём хорошо.
bormand 19.12.2012 15:28 # +5
The NDK toolchain supports C++ exceptions, since NDK r5, however all C++ sources are compiled with -fno-exceptions support by default, for compatibility reasons with previous releases.
To enable it, use the '-fexceptions' C++ compiler flag
Abbath 19.12.2012 15:51 # +1
LispGovno 20.12.2012 00:13 # 0
Посоны, почему вызывается operator=? У меня пол уходит из под ног.
LispGovno 20.12.2012 00:27 # 0
http://liveworkspace.org/code/3g7M9U$16
А это эпо гей крестоповедения:
http://liveworkspace.org/code/3g7M9U$15
Легким движением руки, если забыл вызвать конструктор копирования базового класса в конструкторе копирования потомка, то вызывается конструктор поумолчанию базового класса и все члены базового класса вместо копирования - конструируются поумолчанию. Олололо
LispGovno 20.12.2012 00:41 # 0
Что и требовалось доказать. Tracer a из базового класса B не скопировался, а дефаултсконструировался (sic!). Как мои программы до этого вообще работали? Это - крестопиздец (неожиданный, но пора уж привыкнуть и ждать), а я - нубьё!
LispGovno 20.12.2012 00:49 # 0
krypt 20.12.2012 03:50 # 0
absolut 20.12.2012 09:39 # +7
defecate-plusplus 20.12.2012 10:02 # +2
ясен хер, потому что в копирующем конструкторе в списке инициализации ты не указал копирующий конструктор базового класса, т.е. базовый класс конструируется по умолчанию
http://liveworkspace.org/code/3g7M9U$25
> Посоны, почему вызывается operator=?
*this = other; в конструкторе копирования (sic!)
LispGovno 20.12.2012 10:18 # 0
Е*ать! Какой петух этот snipet сделал?
Обычно operator= по правилам принято делать через конструктор копирования, а не наоборот.
LispGovno 20.12.2012 10:28 # 0
Это можно считать синонимом того, что есть конструктор поумолчанию Tracer(void) и конструктор из строки Tracer(const std::string & name) одновременно или хоть где-нибудь в варианте с конструкторе с опциональным параметром будет различие в поведение с 2хконструкторным вариантом?
defecate-plusplus 20.12.2012 10:33 # 0
одной записью
два конструктора () и (string = "default") будут конфликтовать при попытке компиляции Tracer t;
LispGovno 20.12.2012 10:37 # 0
>() и (string = "default")
а:
() и (string) - такая 2хконструкторная запись полностью эквивалентна по семантике и поведению с одноконструкторным вариантом (string = "default") или есть тонкие различия, которые обязательно вылезут когда-нибудь?
defecate-plusplus 20.12.2012 10:44 # +1
причем зачастую T(another const & = another(...)) делают explicit, если это нужно, что не влияет на семантику "дефолтный конструктор"
LispGovno 20.12.2012 10:49 # 0
TarasB 20.12.2012 10:55 # 0
defecate-plusplus 20.12.2012 11:32 # 0
я говорил именно что
explicit T(another const & = another(...)) убивает сразу несколько зайцев
1) работает как конструктор от another,
2) работает как дефолтный конструктор, фактически ведя себя как конструктор от another с определенным аргументом,
3) благодаря explicit не позволит сделать
another a;
T b = a; (типа std::vector<int> v = 2;)
но позволит T b(a);