- 1
virtual ~T() {}-
C++ / Говнокод #12316
+10
нахуя?
у всех наследников то же самое и наличие чего-либо внутри не предполагается
Первая ссылка по гуглозапросу "c++ mersenne twister" выдаёт склад оопиозного говнокода:
http://www.bedaux.net/mtrand/Запостил:
TarasB,
19 Декабря 2012
Follow us!
В разных местах разная реализация.
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
state[i] & TARAS_B_CONSTANT
> (state[(i+1)%VEC_L]<<1)>>1
state[(i+1) % VEC_L] & ~TARAS_B_CONSTANT
> Нахуя?
Чтобы у класса был виртуальный деструктор. Если у базового класса не будет виртуального деструктора, ты получишь много приятных ощущений при удалении потомка через указатель на тот самый базовый класс...
Нахуй вообще хоть в одном месте иерархии в данном случае усрался хоть какой-то деструктор?
А вот нахуя тут иерархия и наследования - я не знаю. По хорошему тут аггрегация нужна, а не наследование, т.к. имеем отношение "реализован через MTRand_int32" а не "является MTRand_int32".
> delete mt;
Ну поюзает и что? Деструкторы-то блядь пустые и никогда, уверен, в них не появится ни-че-го!
А первый можно убрать только в том случае, если в документации явно написать - "тот кто будет юзать эту недоиерархию как иерархию - тот пидор".
Еще раз повторюсь. Отношение "A реализован через B" это совсем не повод для публичного наследования B от A. А если уж поюзал паблик наследование - будь добр, напиши виртуальный деструктор, не расставляй грабли другим.
P.S. Не написав виртуальный деструктор в иерархии ты нарушаешь принцип подстановки Лисков (один из принципов SOLID), т.к. в результате нельзя подставить объект вместо его предка.
Сравни:
http://ideone.com/2Ea8d4
http://ideone.com/5lB2cR
Не замечаешь кое-какой проблемы?
Тут же даже неподов в данных нет.
Даже если деструкторы пустые и использовалась перегрузка операторов new\delete, то если забыть виртуальные деструкторы в базовом, то delete может вызоватся не торт.
От этой иерархии могут отнаследоваться и всё пойдет псу под хвост, если там деструкторы не пустые будут
P.S. По хорошему - из кода, который ты кидал в топике, нужно выкинуть всю эту ебучую иерархию к хуям, и собрать все это в один простой и понятный класс... (При этом не забыв написать в доке, что наследоваться от него нельзя). Тогда и деструктор не нужен.
Ну дык а я о чём.
Вот открыл я код, увидел МТ в виде иерархии, и какой вопрос сразу же возник у меня? Правильно, "нахуя".
Ну и статические члены, да, но я типа честный рекламщик, выдаю интригующие вещи, а самые вкусные оставляю только для тех, кто всё-таки посмотрит, а то некоторые все фишки в рекламе показывают и потом смотреть нечего, некруто нифига.
P.S. Код в твоем первом комменте под номером 1 это я так понимаю код японца-автора МТ? Тогда он и корректен.
Но насколько я понимаю http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html это официальный сайт МТшки и попутно хоумпага Makoto Matsumoto, который является одним из авторов.
哲学的問題
C++ разные бывают. В каких-то есть, в каких-то нет :P
А вообще с++ под такие контроллеры - это жесть какая-то. Места практически нет, стек маленький и рискует наползти на память... Чисто ради Си с шаблонами?
Я бы такого умника уволил, чтобы не игрался на работе. Прикинь потом код с этим блядством комуто придется поддерживать?
#include <boost/random.hpp>
ну или <boost/random/mersenne_twister.hpp>
там 0 виртуальных методов
Хотелось бы услышать аргументированную критику. Не то чтобы я сильно сох по скале (меня больше интересуют решения, чем средства), просто ты нам недавно (http://govnokod.ru/12041) явно продемонстрировал, как прост, элегантен и краток код на Nemerle.
Ну и уже сейчас видна куча ненужного синтаксического сахара, ухудшаещего читабильность из-за ерунды, увеличивающего число способов записи программы и разрушая единый стиль написания кода, без нужды усложняющего компилятор.
Например:
(4 -> "ko") синоним для (4, "ko")
или
obj.method(5) синоним obj method 5 со всеми проблемами: с приоритетами, читабильностью и частичным применением.
или эта любовь все заворачивать в объекты, даже локальные функции, притом не автоматом, а руками, расписывая поэмы
или
это частичное применение аля хаскель:
func (1) ("arg2") (ko) и не лень же кому-то расставлять скобки...
В целом ничего научного, эволюционного, инновационного или революционного, но как замена жабы, побеждающая большинство её жабапроблем - сойдет...
> func (1) ("arg2") (ko)
Правильнее это назвать результатом каррирования, конечно
Макросы там не особо нужны, и это основная причина того, что их там ещё нет. Продвигают их фанатики типа тебя.
> DSL и прочие метапрограммисткие приемы - на нуле
DSL, к твоему сведению, имеет весьма косвенное отношение к метапрограммированию, можешь почитать Фаулера и DSL in Action по этому поводу.
Очень многого можно добиться одними лишь имплиситами, сохраняя типобезопасность. К примеру, покажи, как реализовать в Nemerle такой код:
> куча ненужного синтаксического сахара
Тот пример, что ты привёл - это не синтаксический сахар, это неявное преобразование, объявленное в Predef - довольно простой и универсальный механизм. Нет специального правила в компиляторе трактовать стрелочку как запятую.
> любовь все заворачивать в объекты, даже локальные функции
Это ограничение жабо-машины - классы и объекты - основные кирпичики. Нужно сказать спасибо скале, что позволяет смотреть на функции как на функции: на значения типа (TI => TO).
> Паттерн-матчинг в скале примитивно слаб
А вот тут можно поподробнее? По-моему, экстракторы рвут классический ПМ, т.к. позволяют сохранить инкапсуляцию, предоставлять View для структур.
Один из немногих способов организации EDSL и DSL: создание кода среды программирования на основе кода *DSL, но конечно не единственный.
>Scalable Component Abstractions
Ковариация и контравариация и обобщённое программирование есть даже C#, не говоря уж о Nemerle. То что в jvm этого нет и поэтому ты принял скалу за божественное проведение - тут ничего не поделать.
>Это ограничение жабо-машины
Вот только с некоторыми из них справляется скала, а так больше ничего нового.
Ты не читал, а уже делаешь выводы. Это не то, что лежит в основе языка.
> ты принял скалу за божественное проведение
Лол. Это всего лишь очередной язык, со своими преимуществами и недостатками. Как и Nemerle. Он мне нравится потому, что в основе лежит неплохая оригинальная идея, а не просто желание напихать побольше фишечек (по этому пути, с моей точки зрения, сейчас идёт c#).
Я видел там красивые иерархии наследования между всеми типами, по аналогии как с тайпклассами в хаскел. Понятно что это один из способов организации обобщенного программирования, впрочем более медлительный, чем тот, что принят в хаскеле или С++.
Идея в том, чтобы предоставлять софт в виде настраиваемых компонентов. При этом компонент - это не какая-то новая сущность. Интерфейс модуля выражается как класс или трэйт. Сам модуль - объект. Модуль может содержать другие модули для своей работы, и т.п.
Конфигурация задаётся не тупыми xml, а наследованием и переопределением ссылок на модули - зависимости (DI с компайл-тайм проверкой наличия всех зависимостей).
Это одна из ключевых (но не единственная) идей, лежащих в основе языка.
Основная причина, почему их там нет - то что в язык уже поздно добавлять макросы, тк изначально язык не разрабатывался, как совместимый с добавлением макросов.
>Очень многого можно добиться одними лишь имплиситами
Метапрограммировать через костыли? В крестах тоже можно метапрограммировать на шаблонах, но каков результат? И то на крестах это делать удобнее.
val duration = 5 seconds
Ну это можно реализовать поразному и с разными целями. Начни с себя и покажи код реализации этого.
держи
требует окончания s на конце по правилам английского языка
101 seconds
да, я знаю, ступил
> можно реализовать поразному и с разными целями
давай, порази нас элегантностью и мощью Nemerle, я весь день жду
Scala должна была за тебя проверить правильность окончания. Так делают настоящие EDSL и DSL.
http://rsdn.ru/forum/src/1823225.all
Чуть позже дам на F#.
Нет, вы не подумайте...
Цель - предоставить удобный интерфейс для задания временных интервалов, такие вещи часто реализуются через monkey patching. Твоя очередь.
> А вот тут можно поподробнее? По-моему, экстракторы рвут классический ПМ
Мм. Экстракторы? Пример? Пока я видел только многословный детский сильноограниченный сад в ПМ скалы.
Поведай об ограничениях, которые ты нашёл, по сравнению с остальными языками, поддерживающими функциональную парадигму.
Я еще тогда хотел упомянуть что возможно Гумно не осилило скалу.
Сам краем глаза поглядываю. Не понравились всякие антиинтуитивные значки, ну ладно там стрелочки - это понятно. Но когда я увидел такое: :: ::: то сразу вспомнил о крестах.
А в немерле мне дико нравится концепция "всё - выражение", и простой язык на макросах.
return try{ "Hi Taras!" } catch {null}
Что может быть удобней?
В целом не скажу что скала сильно в чем-то сливает, и на ней невозможно писать.
По сути срач должен состоять JVM vs CLR. Тут JVM выигрывает по скорости, распространнёности.
В скала тоже многое выражени, в том числе и это.
Это, конечно, эквивалентно следующему:
Естественно, возникает вопрос: как же так, язык объектно-ориентированный; есть методы у объектов — как это всё сочетается с наличием обычных функций, не методов? Ну вот взять, например,
Здесь очевидно, что f1 — метод, а f2 — функция. Какая разница между f1 и f2? Можно ли написать val f3 = f1? Нет, нельзя. Чтобы превратить метод класса в полноправную функцию (т. е., экземпляр типа Function), нужно, формально говоря, добавить подчёркивание после пробела:
val f3 = f1 _
Максимум осилила:
Хороший годный пример унификации интерфейсов. Желаю такого же всем языкам.
Nemerle:
пример:
Что регекспы (хоть и слабее Немерловых), что XML встроен в язык Scala. Ну и наркоманство разращивать и переусложнять компилятор Scala, хотя вполне можно было не добавлять такую ерунду в язык, а сделать на уровне библиотеки, как это сделано а Nemerle. И это притом, что регекспы в скале не такие красивые и краткие, как в немерле, хотя XML в обоих языках по синтаксису и удобству абсолютно одинаковые.
Сахар регекспов реализован через экстракторы, т.е. к усложнению компилятора никак не относится.
Nemerle:
Гугл ТАМ ==>
Код, как код. Что тебе там не понравилось? Рекурсивная стейт-машина. Ты просто не осилил паттерн.
но ты реально задумайся над бустом для ndk
тонко
буст неизбежен, как победа коммунизма
там могут быть косяки только с исключениями в ndk (в ndk нет исключений, да?)
Да, нет, кажется.
И это единственное что в нём хорошо.
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
Посоны, почему вызывается operator=? У меня пол уходит из под ног.
http://liveworkspace.org/code/3g7M9U$16
А это эпо гей крестоповедения:
http://liveworkspace.org/code/3g7M9U$15
Легким движением руки, если забыл вызвать конструктор копирования базового класса в конструкторе копирования потомка, то вызывается конструктор поумолчанию базового класса и все члены базового класса вместо копирования - конструируются поумолчанию. Олололо
Что и требовалось доказать. Tracer a из базового класса B не скопировался, а дефаултсконструировался (sic!). Как мои программы до этого вообще работали? Это - крестопиздец (неожиданный, но пора уж привыкнуть и ждать), а я - нубьё!
ясен хер, потому что в копирующем конструкторе в списке инициализации ты не указал копирующий конструктор базового класса, т.е. базовый класс конструируется по умолчанию
http://liveworkspace.org/code/3g7M9U$25
> Посоны, почему вызывается operator=?
*this = other; в конструкторе копирования (sic!)
Е*ать! Какой петух этот snipet сделал?
Обычно operator= по правилам принято делать через конструктор копирования, а не наоборот.
Это можно считать синонимом того, что есть конструктор поумолчанию Tracer(void) и конструктор из строки Tracer(const std::string & name) одновременно или хоть где-нибудь в варианте с конструкторе с опциональным параметром будет различие в поведение с 2хконструкторным вариантом?
одной записью
два конструктора () и (string = "default") будут конфликтовать при попытке компиляции Tracer t;
>() и (string = "default")
а:
() и (string) - такая 2хконструкторная запись полностью эквивалентна по семантике и поведению с одноконструкторным вариантом (string = "default") или есть тонкие различия, которые обязательно вылезут когда-нибудь?
причем зачастую T(another const & = another(...)) делают explicit, если это нужно, что не влияет на семантику "дефолтный конструктор"
я говорил именно что
explicit T(another const & = another(...)) убивает сразу несколько зайцев
1) работает как конструктор от another,
2) работает как дефолтный конструктор, фактически ведя себя как конструктор от another с определенным аргументом,
3) благодаря explicit не позволит сделать
another a;
T b = a; (типа std::vector<int> v = 2;)
но позволит T b(a);