LINUX.ORG.RU

Продуктивность разработки на C++.

 , ,


6

12

Уважаемые программисты!

Предлагаю порассуждать о продуктивности разработки на C++ по сравнению с так называемыми скриптовыми языками. Вот, принято считать, что языки на вроде Python позволяют работать программисту более продуктивно по сравнению с C++. И что, дескать, на C++ надо писать только узкие места и всё такое.

Мне же хочется четкого понимания. Может быть это миф? А может быть это просто инерция, потому что так вот принято считать и все тут. Вот сегодня в C++ уже не надо думать об освобождении памяти, так как есть умные указатели. Сегодня есть уже более-менее нормальные IDE для C++. Так? Так.

Так что же тогда мешает писать на C++ столь же продуктивно, как на том же Python? Какие будут рассуждения? Может быть есть какие-то реальные обоснования на этот счёт, кроме как «в конторе Y так делают, значит смысл есть, они умные, им виднее». А может быть есть какие-то рецепты по продуктивности работы на C++?

Ответ на: комментарий от pawnhearts

Скобочки решают целый класс проблем, которые Гвидо внес на ровном месте своим букварским синтаксом, и которых больше нет нигде. А выражения решают унылый бойлерплейт def blabla; return blabla, и еще много подобного тру-императивного уныния.

anonymous ()
Ответ на: комментарий от rustonelove

SFINAE существует уже после инстанцирования, а после уже никаких шаблонов нет

SFINAE - это игнорирование ошибочных инстанцирований.

Отлично, больной, определённо наблюдается положительная динамика лечения.

Шаблоны - это тупая подстановка, как и макросы.

Тем не менее лечение нужно продолжить...

SFINAE - это игнорирование ошибочных инстанцирований.

SFINAE это невозможность вывода типов в параметрах шаблона кандидата, а не ошибка инстанцирования. Из чего следует одно из основных отличий от макросов: шаблоны типизированы. Благодаря типизации возможны SFINAE и специализация что уже позволяет делать многое из STL.

anonymous ()
Ответ на: комментарий от Virtuos86

Как бы в вашем примере совсем не видно, чем лямбда-функция лаконичнее, удобнее и читаемее обычной.

Видно же (словами: сэкономили либо строчки, либо символы)

def name(x): return x
def name(x):
    return x
name = lambda x: x
Лябмда однозначно лучше, а бездумные засовыватели PEP8 во все щели, мягко говоря, дурачки. Гвидо довльно сильно перегнул палку запретив в языке многие удобные конструкции (например, традиционный тернарный оператор) и подкинув дурачкам PEP8. Из-за boilerplate по всем фронтам читабельноть кода не лучше конкурентов.

anonymous ()
Ответ на: комментарий от rustonelove

std::chrono - это не про форматировнный вывод, не про гуйню, а именно про работу с временем. И для этой работы никакие строки не нужны. Такие дела.

Я не говорю, что std::chrono обязан содержать работу со временем в строков представлении. Но я не соглашусь, что строки не нужны для работы со временем. Хотя бы как я могу задать точку во времени? Внутреннее представление от меня скрыто, эпоху я тоже не знаю, хотя догадываюсь. Остается использовать time_t, но было бы намного удобнее просто получить временную точку из строки да еще с учетом пояса. Это я к слову про продуктивность плюсов.

yetanother ()
Ответ на: комментарий от eao197

Под миксинами я подразумеваю возможность генерации кода во время компиляции и его подстановка тут же по месту. Причем произвольного кода, не шаблонных объявлений. Но без рефлексии это не нужно. Смысл в том, что например, рефлексия позволяет автоматически генерировать операторы для пользовательских типов. Фишка этого в том, что вы имеете сложные иерархические структуры данных, а операторы сравнения для них генерируются автоматически, что снижает/исключает вероятность ошибки.

Имея рефлексию вы можете пробежаться по всем полям структуры и те поля, которые имеют тип с плавающей запятой вы сравниваете с учетом nan и epsilon, которые целые типы просто сравниваете, а агрегатные типы, например, сравниваете каким-либо другим способом. И теперь если вы изменяете свою структуру, добавляете поля, изменяете их имена и т.д. - компилятор автоматически обработает это. Правда, если у вас код идеальный, вы сразу пишете на века и не делаете рефакторинг, то вам это, конечно, не нужно.

yetanother ()
Ответ на: комментарий от d_a

так что system_clock::to_time_t() / system_clock::from_time_t() + функции из <ctime> первый и он же последний вариант.

Да я согласен так-то, мне понятно откуда это и почему. Но в контексте продуктивности языка возможность получить дату и время сразу из строки трудно переоценить.

yetanother ()
Ответ на: комментарий от yetanother

Под миксинами я подразумеваю возможность генерации кода во время компиляции и его подстановка тут же по месту.

Очевидно, что под миксинами вы можете понимать каких-то тараканов в своей голове. Поэтому я и попросил привести примеры.

eao197 ★★★★★ ()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от eao197

Очевидно, что под миксинами вы можете понимать какие-то тараканы в своей голове. Поэтому я и попросил привести примеры.

Согласен с вашей осторожностью. Я сталкивался с миксинами только в контексте кодогенерации с помощью рефлексии. Так как в плюсах рефлексии нет, то показать на С++ пример где был бы полезен миксин я не могу. В D например, с помощью миксинов и статической диспетчеризации я сгенерировал биндинг к плюсовой библиотеке, где дишные вызовы типа:

    AggregateType at;
    at.field1 = 123;
    at.field2 = "some text";
    auto var = at.field2;
автоматически транслировались в плюсовые
    AggregateType at;
    at.set_field1(123);
    at.set_field2("some text");
    auto var = at.get_field2();
в компайл-тайме без накладных расходов. Мне это позволило подменить одну библиотеку другой без переписывания кода. Иначе пришлось бы везде прописывать геттеры/сеттеры, да и код выглядел бы сложнее. Такой миксин занял у меня 26 строчек с комментариями, что намного проще, чем переписывание кода. Без миксинов этого бы не получилось. Это не яркий пример полезности миксинов, больше на сахар похоже, но яркий пример на примере плюсов показать не получится.

yetanother ()
Ответ на: комментарий от yetanother

Так как в плюсах рефлексии нет, то показать на С++ пример где был бы полезен миксин я не могу.
Это не яркий пример полезности миксинов, больше на сахар похоже, но яркий пример на примере плюсов показать не получится.

Ну как-то и непонятно, зачем в C++ возможность подмешивать какой-то «левый» код в классы. Если бы были наглядные примеры, то может быть надобность в подобном подмешивании была бы очевидна большему количеству народа.

А вообще есть ощущение, что в C++14 и более поздних, различные фокусы возможны посредством вот такой вот магии.

eao197 ★★★★★ ()
Ответ на: комментарий от yetanother

Но в контексте продуктивности языка возможность получить дату и время сразу из строки трудно переоценить.

Есть std::get_time, std::put_time. Но они разумеется никак не касаются упомянутого <chrono>.

d_a ★★★★★ ()
Ответ на: комментарий от monk

И половина задач становятся нерешаемыми совсем. Начиная от простого двусвязного списка.

Точно половина? unsafe нужен еще для ввода-вывода и только если этого нету в std. Таких кейсов почти нет. Для написания драйверов или OS нужно делать свою std, очевидно же.

vlad9486 ()
Ответ на: комментарий от anonymous

просто обязан

Только на краях, но не внутри. С просто обязан и внутри тоже. Чем больше програма тем меньше удельный вес краев.

vlad9486 ()
Ответ на: комментарий от vlad9486

Там где-то выше царь вещал про два типа разработки: низкоуровневые компоненты и скриптуха. Вот плюсану его, растаманы мыслят исключительно в рамках скриптухи. Кто-то свыше даст им волшебные либы, где будет все safe и cool, а они привычно займутся переливом даты из пустого в порожнее. Мда, без мозиллы язык быстро загнется. Даже стремительно.

bread ()
Ответ на: комментарий от eao197

Ну как-то и непонятно, зачем в C++ возможность подмешивать какой-то «левый» код в классы.

Сейчас вместо миксинов в плюсах используются макросы для подмешивания «левого» кода в классы. Например `msgpack` использует макросы для генерации кода сериализации/десериализации. Буст использует макросы в хвост и гриву. Про то что макросы в текущем виде это костыль, я думаю всем известно. Замена макросов препроцессора на миксины, полноценно поддерживаемые компилятором дало бы языку только плюсы.

yetanother ()
Ответ на: комментарий от bread

Низкоуровневые компоненты состоят из ввода вывода?

Растаманы (некоторые) понимают что задачи ввода вывода в 99% случаев можно обобщить, засунуть в какой-то IStream и забыть. Только отбитые сишники хотят кодить как диды кодили и каждый раз делать то, что давно уже сделанно.

vlad9486 ()
Ответ на: комментарий от anonymous

Как бы в вашем примере совсем не видно, чем лямбда-функция лаконичнее, удобнее и читаемее обычной.

Видно же (словами: сэкономили либо строчки, либо символы)

def name(x): return x
def name(x):
    return x
name = lambda x: x

def name(x): print x
name = lambda x: __import__("sys").stdout.write("%s\n" % x) # бу-га-га)))

Лябмда однозначно лучше, а бездумные засовыватели PEP8 во все щели, мягко говоря, дурачки.

PEP8 обязателен только для stdlib, поэтому соглашусь со второй частью утверждения.

Гвидо довльно сильно перегнул палку запретив в языке многие удобные конструкции (например, традиционный тернарный оператор) и подкинув дурачкам PEP8. Из-за boilerplate по всем фронтам читабельноть кода не лучше конкурентов.

В Python отличный тернарный оператор, который соотносится с, например, существовавшим еще до него синтаксисом guard'ов в list comprehension: [x for range(10) if x < 5]. В этом плане этот синтаксис просто обобщили на весь язык. Типично питоновское решение — не тащить лишнюю пунктуацию в язык, если можно использовать уже существующие сущности.

Virtuos86 ★★★★★ ()
Ответ на: комментарий от d_a

Есть std::get_time, std::put_time. Но они разумеется никак не касаются упомянутого <chrono>.

Это понятно. Моя мысль про то, что мне понравился ход мыслей авторов chrono, они спрятали детали реализации, сделали все более логичным, разделили system и steady, добавили трейтов и т.д. Но преобразование в/из строки они оставили в стороне, видимо рассудив, что достаточно имеющихся средств. Да, средства имеются, но было бы (имхо, конечно же) логичнее их добавить в chrono. Потому что сейчас получается ты работаешь с chrono в ее духе, а потом переключается на сишные структуры для форматирования. Вылазит некая нецелостность языка, сформированная легаси. И все это, опять же, имхо, снижает продуктивность языка. Те же {put|get}_time работают не с time_point, не с time_t, а с tm. Что несколько обескураживает.

yetanother ()
Ответ на: комментарий от yetanother

Если вы говорите про mixin-ы исходя из опыта их использования только в D (тогда как в Scala, например, mixin-ами называются другие вещи), то вы предлагаете штуку, которая ничуть не лучше макросов. И работает она в D потому, что в D вы имеете compile-time рефлексию и compile-time function evaluation. Две эти штуки используются для генерации некой строки которая затем инжектится в код. По такому же принципу, по которому работают макросы.

Далеко не все хотят видеть в C++ такой способ работы с кодом.

Отдельный вопрос о надобности compile-time рефлексии в C++. Эту фичу многие хотят и работы в этом направлении начались. Правда, шансов поиметь это в C++20 немного.

eao197 ★★★★★ ()
Ответ на: комментарий от yetanother

Вылазит некая нецелостность языка, сформированная легаси.

Но это есть суть стандартный C++, он весь такой :)

d_a ★★★★★ ()
Ответ на: комментарий от anonymous

Отлично, больной, определённо наблюдается положительная динамика лечения.

Зачем ты пытаешься нести ахинею, вася? Поймать меня? В параллельной вселенной у тебя это получиться и то не факт.

Первое никак не противоречит второму. SFINAE - это методика, которая используется особенность работы инстанцирования, и именно игнорирование синтаксические неверных инстансов.

Самая же методика основана на том, что что это невалидное не попадает в кандидаты для перегрузки и всё это существует уже после инстанцирования.

Тем не менее лечение нужно продолжить...

Продолжаем.

SFINAE это невозможность вывода типов в параметрах шаблона кандидата, а не ошибка инстанцирования.

Это именно шибка инстанцирования - невалидная синтаксически конструкция.

То, о чём пытаешься петь - ты всё перепутал. Игнорирование ошибок распространяется только на типы, но из этого ничего не следует - это лишь ограничение.

Из чего следует одно из основных отличий от макросов: шаблоны типизированы. Благодаря типизации возможны SFINAE и специализация что уже позволяет делать многое из STL.

Неверное. Ахинею какую-то насрал. Неработоспособность SFINAE для не-типов это лишь ограничение и не более того.

А типы там, хренотипы, либо что ещё - никакого отношения не имеет к шаблонам.

С шаблонами оно связано только через то, что генерируется эта конструкция «на лету» и именно поэтому для неё отдельные правила. Именно поэтому оно не ломается сразу.

Да и шаблоны как раз таки не типизированы - ты опять всё напутал. Типизированным может быть только инстанс, а сам шаблон к типам имеет отношение только через то, что в параметр-тип можно передать только тип. На этом их «типизация» заканчивается.

Т.е. макросы и шаблоны никак не отличаются за исключением того, что одни реализованы на уровне языка. В остальном это такая же тупая подстановка.

Что ты своими убогими потугами пытаешься сказать - неясно. Нюансы работы есть и там и там, как и у твоей жопы. Но это не значит, что твоя жопа не жопа. Даже если она кривая.

Принципы работы шаблонов и макросов одинаковые. Всё остальное - нюансы и из них ничего не следует.

rustonelove ()
Ответ на: комментарий от eao197

Если вы говорите про mixin-ы исходя из опыта их использования только в D (тогда как в Scala, например, mixin-ами называются другие вещи), то вы предлагаете штуку, которая ничуть не лучше макросов.

Не только лучше, а на порядок. Миксины обрабатываются компилятором, а не препроцессором.

Две эти штуки используются для генерации некой строки которая затем инжектится в код.

Это вы про строковые миксины говорите, есть и шаблонные миксины, это совсем другой механизм.

По такому же принципу, по которому работают макросы.

Макросы обрабатываются препроцессором, а миксины компилятором. Поэтому компилятору доступна вся информация. Это другой механизм.

Отдельный вопрос о надобности compile-time рефлексии в C++.

Ну тут каждому свое, конечно. По мне так однозначно она нужна. Рефлексия позволяет автоматизировать многие вещи, это сильно повышает продуктивность.

yetanother ()
Ответ на: комментарий от yetanother

Это вы про строковые миксины говорите, есть и шаблонные миксины, это совсем другой механизм.

Так а вы про что говорите? И что хотели бы видеть в C++?

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

Так а вы про что говорите? И что хотели бы видеть в C++?

Однозначно хотел бы видеть компайл-тайм рефлексию. Я бы без нее жил, но когда увидел в D что это дает, мне ее реально не хватает в C++. Про миксины скажу, что их необходимость зависит от других средств языка поэтому пока отложим в сторону. Ну и внятных шаблонов бы хотелось, но это уже вряд ли. Конкретный пример необходимости рефлексии - имеется сложная иерархическая структура данных. При наличии рефлексии, как в D, для сериализации ее в формат msgpack нужно вызвать только одну шаблонную функцию - pack(); В плюсах это же действие требует добавить в каждую вложенную структуру макрос, генерирующий код сериализации/десериализации. В чем разница? Меньше затраты на сопровождение и меньше ошибок. Не надо модифицировать чужой код. Стоимость разработки уменьшается, в первую очередь по времени, ну а время - деньги, это тоже известно. При наличии рефлексии полностью исключается случай, что какое-то поле какой-то структуры забыли прописать в макросе и не нужно будет через полгода вникать в код исправляя неочевидный баг. Пусть компилятор пишет тот код, который он в состоянии написать.

yetanother ()
Ответ на: комментарий от vlad9486

Ну что же вы все такие тупые, вася. Ты понимаешь, что для твоего раста НИЧЕГО не сделано. Раст писался для того, чтобы ПЕРЕПИСАТЬ готовый рантайм, в рамках него ПЕРЕПИСЫВАЮТ готовый рантайм. Зачем, если он уже есть? Зачем новый движок, если есть старый - в рамках той же лисы? Ты понимаешь насколько убогую херню ты несёшь.

Есть люди, которые занимаются написанием этого того, что уже сделано. Появляются новые алгоритмы, новые механизмы, новое стандарты. Всё это надо делать. Всё это лоулевел. Новые девайсы, новые драйвера.

Кто это будет делать? Да, твои раст-ламерки не смогли реализовать исключения и стырили их из крестов, а если бы их не было - откуда бы ты их тырил? Они бы сами родились?

Тебе надо понять простую вещь. Если ты занимаешься криптухой, то сиди на жопе ровно и жуй. Тебя никто ни о чём не спрашивает. У тебя есть готовое, есть то, что тебе дали. Нового ты ничего не делаешь. Ты сборщик мебели.

И если сборщику мебели циркулярка не нужна, а есть готовое попиленное, то это готовое кто-то должен был попилить и поддерживать. Пойми это своей одно извилиной - это же так просто.

Слишком сложно мартышке объяснить то, что всё не растёт на деревьях. Поэтому объяснять тебе что-то не имеет смысла. Хотя я попытался.

rustonelove ()
Ответ на: комментарий от yetanother

какой макрос? ты болен. каждый элемент твоей иерархической структуры данных должен быть отнаследован он AbstractElement. AbstractEncoder должен знать о всех отнаследованых, а те, свою очередь, должны вызывать в нем соответсвующий метод с параметрами. потом ты такой

class msgpackencode: public AbstractEncoder {...}
msgpackencoder me;
your_tree.acceptEncoder(me);
и теперь смотри внимательно: добавили новый элемент в дерево - добавь метод в AbscractEncoder. и таким же образом в msgpackencoder иначе он не скомпилится из за пюр виртуаль методз. а кодирование элемента теперь делает сам элемент при помощи енкодера, который ему скормили. и это гиниально я щитаю. и те, кто до этого не допёр придумывают макросы, дайнемик касты, рефлексию и прочую ахинею, от которой даже мне подташнивает.

так что батенька у вас те же симптомы, про которые кричит толи анонимус, то ли ещё кто-то тут. есть куча неосиливших ооп, которые хотят что то писать. но у них не получается. и они думают что виноват язык. признаться себе что немощен сложно, обвинить язык - легко. в результате они хотят новый язык, в котором у них якобы получится. мне это кажется похожим на столяра, который ударив молотком по пальцу кричит молоток говно, давайте забивать гвозди ушными палочками.

короче, что рустеры, что вы просто не умеете готовить сиплюсплюс.

anonymous ()
Ответ на: комментарий от rustonelove

для твоего раста НИЧЕГО не сделано

Ты понимаешь, что раст - это язык, а не софт? Что же для него нужно такого сделать?

Всё это надо делать. Всё это лоулевел.

Да, согласен. unsafe здесь придется писать. Но я не согласен с тем что

И половина задач становятся нерешаемыми совсем.

Именно с этого началось обсуждение.

Слишком сложно мартышке объяснить

Некоторым слишком сложно умерить свое ЧСВ и усмотреть логику в тексте другого человека.

vlad9486 ()
Ответ на: комментарий от anonymous

каждый элемент твоей иерархической структуры данных должен быть отнаследован он AbstractElement.

Во-первых, вы ведете речь просто о другой библиотеке, не вникнув в суть. Которая заключается в том, что при наличии рефлексии пользователю библиотеки не нужно ничего делать, библиотека с помощью рефлексии разберет пользовательский тип данных и выполнит все необходимые манипуляции. И еще раз - пользователь просто создает свой тип данных, а библиотека все делает сама. С помощью рефлексии. Без наследования, энкодеров и прочего «гиниально я щитаю». Все остальные комментарии о неосиляторах, неумеющих готовить сиплюсплюс, которые уже просто набили оскомину, оставлю за бортом. Старайтесть вникать в суть того, что комментируете.

yetanother ()
Ответ на: комментарий от vlad9486

Ты понимаешь, что раст - это язык, а не софт? Что же для него нужно такого сделать?

Всё. Ты понимаешь вообще назначение раста? Хомячки орут «опенссл дерьмо - на расте будет круто», «наш движок дерьмо - на расте будет круто». Всё это уже есть и раст-адепты тем и занимаются, что пытаются всё переписывать под лозунгами «это будет круче и безопасней». Поэтому пойди к ним и скажи это то, что ты нёс тут. Да и ты вообще весь смысл существования раста на ноль помножил.

Именно с этого началось обсуждение.

Я не знаю кто там тебе и что писал. Я вижу ту ахинею, которую ты, косвенное, адресовал в мой адрес. Всё просто.

А так да, на срасте ты что-то сложнее хелворда не напишешь без ансейфа в лоулевел. Да и даже в рядовой системщине у тебя будут ой какие проблемы.

Некоторым слишком сложно умерить свое ЧСВ и усмотреть логику в тексте другого человека.

Да дело не в ЧСВ. Дело в том, что знаешь сколько я уже на подобную ахинею отвечаю? Каждый раз вылезает новый эксперт и срывает покровы. Всё там ему уже есть, всё там велосипедят.

Ты бы хоть почитал историю того, что ты защищаешь. Твой раст - это велосипед создайнный для написания велосипеда. Представляешь?

А по поводу твоей логики. Я уже писал, что safe раста - это манипуляция. Во всех языках у тебя есть такое же safe и единственное, что тебе даёт раст - это явное safe. И как я уже говорил - полезность этого крайне сомнительна.

rustonelove ()
Ответ на: комментарий от yetanother

Мы ушли куда-то в сторону. Надобность рефлексии мной в данный момент не рассматривается. Меня интересует, какие именно миксины вы хотели бы видеть в C++. Но тут вы с примерами как-то пасуете.

Сериализация, для которой достаточно пройтись по всем полям структуры-класса, это какой-то частный и примитивный случай сериализации. Вам повезло, что вы столкнулись именно с таким случаем. Не более того.

Пусть компилятор пишет тот код, который он в состоянии написать.

Компилятор тут не причем. Вы увидели в D возможность делать compile-time кодогенерацию и вам кажется, что это делает компилятор. Хотя это и не так.

eao197 ★★★★★ ()
Ответ на: комментарий от anonymous

рефлексию и прочую ахинею, от которой даже мне подташнивает.

Нет, это ты болен. Каким же больным надо быть, чтобы назвать рефлексию ахинеей.

При этом в крестах это будет не просто рефлексия, а это ещё и то, что заставит наконец-то пересмотреть ущербанскую архитектуру крестов. А это намного важнее.

То же самое и с теми же концептами. Там выше такой же больной(а может это и ты) пытается куарекать о типизации шаблонов, которой просто нет. И концепты её добавляют.

И вот после того, как эта типизация будет, тогда уже всякая кастылепараша типа сфинаи нахрен не нужна будет.

А пока больные жрут дерьмо и других заставляются жрать то же самое дерьмо. Тысячу лет жрали make_pair() парашу, чтобы наконец-то осилить deduction guides. Наверное надо было и дальше жрать make_pair()-парашу, да?

Эти заявления просто смешны.

в результате они хотят новый язык

Неверно. Ты перепутал. Есть люди, которым мало С++ - они хотят больше. Больше возможностей. Ничего из этого нет нигде, а никаким образом ты кресты на сишарпик не поменяешь.

Те, кто так орут - не осилили кресты и они пуще всего боятся всего нового.

Большинство крестовиков/сишников, да и остальных - это однотрюковые мартышки, которые выучили этот самый один (набор)трюк. И именно все эти неосиляторы бояться нового, более мощного.

И пока их там спустя 10лет питух в жопу не клюнет, хотя их осиляторство заканчивается после того, как они научились везде пастить std::forward.

Ты похоже из их числа, который привык сидеть в болоте и трястись перед усложнениями.

rustonelove ()
Ответ на: комментарий от rustonelove

Мне вообще пофиг что орут хомячки. Человек пишет что половина полезного лоулевел кода содержит ансейф, это не верно. Я же пишу что не половина, а 1%.

А так да, на срасте ты что-то сложнее хелворда не напишешь без ансейфа в лоулевел.

Вот здесь http://joeduffyblog.com/2015/11/03/blogging-about-midori/ человек рассказывает как сделал (с коммандой) с C# аналог раста и написал на нем OS с минимумом ансейфа. Мне лень повторять его аргументы, но они лучше чем твои.

Рекомендую почитать для расширения кругозора.

vlad9486 ()
Ответ на: комментарий от eao197

Мы ушли куда-то в сторону. Надобность рефлексии мной в данный момент не рассматривается. Меня интересует, какие именно миксины вы хотели бы видеть в C++. Но тут вы с примерами как-то пасуете.

Действительно пасую. Потому что необходимость миксинов у меня возникала только при использовании рефлексии. Были конкретные случаи, когда нужен был миксин, причем именно строковый. Но это же зависит от конкретного языка и здесь его приводить в пример нет смысла. Поэтому и пасую, потому что неясно что за рефлексия будет в плюсах и какие средства понадобятся.

Сериализация, для которой достаточно пройтись по всем полям структуры-класса, это какой-то частный и примитивный случай сериализации. Вам повезло, что вы столкнулись именно с таким случаем. Не более того

Ну вы странно занизили значимость возможности пройтись по всем полям. Это очень важно. Ведь поля, которые вам не нужны, вы можете не обрабатывать и все. Это как раз самый что ни на есть общий случай. И это не только сериализация. Например, я генерирую гуй (раскладку элементов) в компайл тайме на основе переданного типа данных, а в райтайме отображаю содержимое. И в зависимости от типа полей отображаю их необходимым образом. Это далеко не тривиальная логика и хотя это можно сделать в рантайме и конечный эффект будет тот же, рефлексия очень упрощает код и его сопровождение.

Компилятор тут не причем. Вы увидели в D возможность делать compile-time кодогенерацию и вам кажется, что это делает компилятор. Хотя это и не так.

Это уже более философский вопрос, кто/что делает. В любом случае с помощью рефлексии можно переложить рутинные задачи на плечи компилятора. Рефлексию можно эмулировать в плюсах, заранее в структуры данных добавляя трейты и прочее, но если не добавили, то все. А с рефлексией это все не нужно. Код банальнее чище и возможностей больше. Без шаманства.

yetanother ()
Ответ на: комментарий от Virtuos86

Уже соглашаешься с царём?

Да. Но тут важнее было его скастовать, чтобы тред не потух.

bread ()
Ответ на: комментарий от vlad9486

Мне вообще пофиг что орут хомячки. Человек пишет что половина полезного лоулевел кода содержит ансейф, это не верно. Я же пишу что не половина, а 1%.

Ну в твоих мечтах, позможно.

Вот здесь http://joeduffyblog.com/2015/11/03/blogging-about-midori/ человек рассказывает как сделал (с коммандой) с C# аналог раста и написал на нем OS с минимумом ансейфа. Мне лень повторять его аргументы, но они лучше чем твои.

Ты,васян, вообще понимаешь что такое ОС? Ты понимаешь, что если ты высрешь хелворд и назовёшь это ОС - это будет не ОС?

Когда люди имеют ввиду реальный софт, реальную ОС - это значит конкурентоспособный реальности софт. А не неведомое дерьмо.

Это то, что должен понимать каждый всян пережде, чем пытаться что-то вонять. Но ты этого не понимаешь - почитай букварь.

Мой аргумент уже множит на ноль любую твою потугу. Рассуждения от нонейма с помойки, который выдёт нонейм-хелворд с той же самой помойки за ОС, за какой-то вменяемый пример - ему нужно срочно обратиться в психдиспансер - там его вылечат и всех его адептов.

И уже все твои потуги, как и потуги того, кого ты мне спастил идут лесом. И это работает очень просто.

rustonelove ()
Ответ на: комментарий от rustonelove

Этот нонейм - архитектор в майкрософт. И делают они там ОС уже почти 15 лет. И почему-то не на C и не на C++.

А в психодиспанчер нужно тому, кто не ознакомившись с сслылкой орет оскорбления.

vlad9486 ()
Ответ на: комментарий от vlad9486

Этот нонейм - архитектор в майкрософт. И делают они там ОС уже почти 15 лет. И почему-то не на C и не на C++.

Если что, 15 лет потратить на то, что оказалось мертворожденным, и что забросили и закрыли, - не особо хорошая характеристика, в том числе для «не С и не С++».

anonymous ()
Ответ на: комментарий от vlad9486

Этот нонейм - архитектор в майкрософт.

Да мне насрать кто это - это нонейм с помойки. А о майкрософт лучше вообще не заикаться. Какие там есть вменяемые проекты? Одна гуйня и ОС, которая существует только за счёт того, что левые вендоры прикрутили к этому говну хоть какие-то функции. Да сотни тысяч индуксов ваяют это дерьмо день и ночь. Всё.

Но даже микрософт осилил сделать броузер лучше лисы. Поэтому я даже не знаю кого хаять, а кого хвалить.

И делают они там ОС уже почти 15 лет.

Меня не волнует сколько нонейм с помойки делает нонейм-ОС с помойки. Она как была с помойки - там и осталась.

И почему-то не на C и не на C++.

И почему-то она на помойке. Вот незадача.

А в психодиспанчер нужно тому, кто не ознакомившись с сслылкой орет оскорбления.

Это не оскорбления - это констатация факта, пусть и в грубой форме.

Какой-то индус пишет о том, что он там что-то ваяет, чего никто не видел, что является хелвордом, который ничего не может, который полностью неконкурентоспособен. Тебе так понятнее будет?

Ты мне ещё лабу от адепта раста выдай за ОС. Будет то же самое.

Вот когда эти индусы осилят хоть что-то вменяемое сваять - тогда зови и приводи это в пример. А пока этого нет - я бы на твоём месте такой хёрнёй не страдал бы. Всё просто.

rustonelove ()
Ответ на: комментарий от vlad9486

The operating system was discontinued some time in 2015, though many of its concepts were rolled into other Microsoft projects.

Это что?

rustonelove ()
Ответ на: комментарий от rustonelove

Ты писал здесь (и наверное не только здесь)

Появляются новые алгоритмы, новые механизмы, новое стандарты. Всё это надо делать. Всё это лоулевел.

Вот это как раз пример того, что на самом деле появляется новое и как оно делается. Чтиво объемное и интересное для того, кто не называет все вокруг дерьмом не разобравшись.

vlad9486 ()
Ответ на: комментарий от vlad9486

Вася, вот читал бы ты мои посты про жизнь - ты бы понимал как вся эта кухня работает.

Все эти проекты - это развод на бабки. Работает это следующим образом. Мы выкатываем новую, инновационную супер-идею и впариваем её лохам. Безопасность всегда прокатывала. Вот мы и впариили лохам новую, супер-безопасную ОС.

Впаривая подобную херню мы снимаем с себя всю ответственность за результаты. Ведь если наша поделка не сможет даже болванку нарезать, то она не виновата - просто нужно ещё n-лярдов и 20лет на инновации, а там далее точно сможется. У нас же не какое-то там дырявое дерьмо на крестах - у нас свой супер-язык.

Именно поэтому никаких результатов никогда не будет. Потому что никому они не нужны. Маздайсофт похайпит на «новых технологиях», школота получит бабки за отсидку. Насруть тонну говнокода, который еле шевелится. После выкинут.

Это жизненный путь всего этого трешака. Так было, етсь и будет. Всегда.

rustonelove ()
Ответ на: комментарий от vlad9486

Вот это как раз пример того, что на самом деле появляется новое и как оно делается.

Нет, васян. Это булшит для подобных тебе ламерков. Ты мне не выкатишь ни одного свидетельства тому, что это дерьмо живо и кому-то нужно.

В такую херню может верить самая отбитая и лсная ламерюга.

Чтиво объемное и интересное для того, кто не называет все вокруг дерьмом не разобравшись.

Ты совсем поехавший, вася. Разобраться я должен был в чём? В твоих потугах, либо потугах какого-то и ндукса с помойки? Нет, мне это не интересно.

Тебе задали конректный вопрос - где и кому нужны твои инновации? Где они? Их нет, а то, чего нет - ты можешь засунуть себе только в жопу.

Я верю только в то, что могу пощупать. В то, что есть. В мусор для сектантов я не верю и верить не обязан.

Тебе задали конкретный вопрос - почему твоя поделка и твой индус в помойке? Это очень простой вопрос, который ты проигнорировал. Почему? Да потому что ты лсное трепло и жертва убогой пропаганды.

Тебе в твою пустую черепушку залили какую-то агитку, ты её и ретранслируешь мне тут. Подлечись. Полегчает.

rustonelove ()
Ответ на: комментарий от vlad9486

Вот здесь http://joeduffyblog.com/2015/11/03/blogging-about-midori/ человек рассказывает как сделал (с коммандой) с C# аналог раста и написал на нем OS с минимумом ансейфа. Мне лень повторять его аргументы, но они лучше чем твои.

Ну а до этого у них был не менее исследовательский проект с Singularity. Для которого они из C# сделали Spec#. И где это все сейчас?

Как только игрушки начинают переводить в реальный продакшен, то выясняется, что производительность и предсказуемость — это не пустые звуки. И за все нужно платить. Откуда количество safe начинает снижаться, а unsafe — увеличиваться.

eao197 ★★★★★ ()
Ответ на: комментарий от vlad9486

Меня сейчас из-за тебя, крайне одарённого, забанят нахрен. Такой отборной ахинеи я давно не видел. Я уж думал, что ты мне сейчас про боженьку начнёшь вещать.

Тебе говорят крайне простые вещи и задают очень простые вопросы, на которые у тебя нет ответов. И ты бы подумал над тем - почему их нет и почему ты ничего не можешь ответить. Это же очень просто.

rustonelove ()
Ответ на: комментарий от yetanother

Потому что необходимость миксинов у меня возникала только при использовании рефлексии.

Ну т.е. краеугольным оказывается все-таки требование о наличии рефлексии, а не миксинов.

Ну вы странно занизили значимость возможности пройтись по всем полям. Это очень важно.

Это может быть важно, когда у вас структуры данных заточены только под то, чтобы по ним пройтись рефлексией и что-то сделать.

Например, я генерирую гуй (раскладку элементов) в компайл тайме на основе переданного типа данных, а в райтайме отображаю содержимое. И в зависимости от типа полей отображаю их необходимым образом.

Интересно на такое посмотреть.

Ну и отдельный вопрос: должен ли C++ применяться там, где такое требуется. Есть мнение, что языки с GC и уже имеющие рефлексию (что compile-time, что run-time) будут справляться с этим гораздо лучше.

В любом случае с помощью рефлексии можно переложить рутинные задачи на плечи компилятора.

Остается открытым вопрос о том, много ли такой рутины в тех задачах, где C++у самое место.

А с рефлексией это все не нужно. Код банальнее чище и возможностей больше. Без шаманства.

Некоторые C++ники используют CRTP и не видят в этом никакого шаманства. Другие начинают вопить, что незачем трехэтажные шаблоны наворачивать, а то не понятно, кто и что делает.

eao197 ★★★★★ ()
Ответ на: комментарий от rustonelove

твоя поделка и твой индус в помойке?

У тебя нет свидетельств что в помойке. У меня нет свидетельств что не в помойке. Но его аргументы лучше твоих и он что-то делал в отличии от тебя.

vlad9486 ()
Ответ на: комментарий от eao197

И где это все сейчас?

Никто не хочет в продакшин что-то новое и непроверенное. Это все сейчас в столе, ждет спроса.

vlad9486 ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.