Здравствуйте, AeroSun, Вы писали:
AS>Я изначально учил и дрючил шаблоны, очень нравилось, но потом попробовал кодогенерацию и понеслась! AS>В текущем виде плюсовые шаблоны — это самый классический говнокод шлакоблок. Кроме простых и очевидных случаев применения их больше нигде нет смысла использовать.
std::variant, std::function — к каким случаям относишь? А их реализацию? Или например std::iterator_traits?
Или это всё тоже предлагаешь генерировать?
AS>попытка в DSL на плюсах
Не просто DSL, а EDSL, со всеми вытекающими.
AS>Кодогенерация пишется максимум за 1 день,
Зависит от. Какая-то и за 5 минут, иная же может намного дольше — в зависимости от навороченности входного описания, и интеграцией с остальным C++ кодом.
То о чём ты говоришь — скорей всего какой-то один конкретный случай попавшийся тебе лично
AS>код красивый и чистый как слеза, оптимизация/отладка идеальна
Только теперь этот код на двух разных языках, точнее даже на трёх — ибо обычно есть ещё третий входной язык для генератора.
В итоге, в случае проблемы — придётся скакать между всеми тремя. А учитывая что там везде склейка строчек — нормальная типизация как правило отсутствует и ошибки вылазят только при финальной компиляции (если вообще ловятся ею) — при этом информация скудная, обычно только из целевого языка без полного callstack'а.
AS>А и возможности кодогенерации безграничны — в отличии от шаблонов ты не зациклен как поставить компилятор раком, чтобы получилось хоть что-то отдалённо похожее на требуемое решение, а работаешь непосредственно над задачей.
Если не впадать в крайности, то обычно используются и то и другое, а и ещё и макросы препроцессора, ибо везде есть уникальные преимущества, так и уникальные недостатки.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>std::variant, std::function — к каким случаям относишь?
К случаям борьбы с ветряными мельницами. Это должно быть встроенными типами.
AS>>попытка в DSL на плюсах EP>Не просто DSL, а EDSL, со всеми вытекающими.
Да, да, неудобно и убого. Кроме как proof of concept больше ни на что не годится.
AS>>Кодогенерация пишется максимум за 1 день, EP>Зависит от. Какая-то и за 5 минут, иная же может намного дольше — в зависимости от навороченности входного описания, и интеграцией с остальным C++ кодом. EP>То о чём ты говоришь — скорей всего какой-то один конкретный случай попавшийся тебе лично
При любом раскладе добиться похожего результата с помощью метапрограммирования займёт в лучшем случае на порядок больше времени. Только вот кодогенерация и в дальнейшем будет работать идеально, а в случае метапрограммированием с ним придётся бороться всё время. Достаточно полгода не работать с либой, а потом шаг в сторону — и начинаем прокручивать лог ошибок: метр, метр, километр, метр, метр....
AS>>код красивый и чистый как слеза, оптимизация/отладка идеальна
EP>Только теперь этот код на двух разных языках, точнее даже на трёх — ибо обычно есть ещё третий входной язык для генератора. EP>В итоге, в случае проблемы — придётся скакать между всеми тремя. А учитывая что там везде склейка строчек — нормальная типизация как правило отсутствует и ошибки вылазят только при финальной компиляции (если вообще ловятся ею) — при этом информация скудная, обычно только из целевого языка без полного callstack'а.
Да хоть в десяти местах, если это проще, быстрее и удобнее.
Только вот скакать придётся как раз по шаблонам в куче мест. А в случае генератора в 99% случаев требуется проверить лишь вход.
Про проблему отладки и типизации это ты видимо только с наколеночными (типа python-генераторами) сталкивался. в более серьёзных генераторах даже присутствует наиболее оптимальный выбор типа/алгоритма.
Прикрутив тот же clang получаем доступ к AST плюсов в удобном естественном виде. Далее у нас фактически получается расширение компилятора: можем из плюсов генерить другие языки (SQL например), из других языков — плюсы, из плюсов преобразовывать в плюсы, из других языков преобразовывать в другие языки, подсовывать самые оптимальные типы, выбирать самые оптимальные алгоритмы и т.д и т.п. И всё это на этапе компиляции. И везде будет чистый и понятный синтаксис без грамма говнокода. И всё это будет очень просто отлаживать, даже не просто, а элементарно. И скорость компиляции будет реактивная. И IDE с подсказками будут работать идеально. И т.д. и т.п.
Метапрограммирование в текущем виде в плюсах — просто не тот уровень.
EP>Если не впадать в крайности, то обычно используются и то и другое, а и ещё и макросы препроцессора, ибо везде есть уникальные преимущества, так и уникальные недостатки.
Макросы??? Последний раз их использование видел в 2005-2006. Далее во всех компаниях где работал они запрещены (кроме простейших случаев) внутренними соглашениями. Появление любого макроса в коде — это чуть ли не автоматический провал code review. Доказать необходимость его использования — практически неподъемная задача.
И это правильно — макросы, как и метапорнография — это хрестоматийный пример говнокода: куча неявных/неочевидных событий/преобразований происходит вне фокуса внимания, зависимость не только от локального контекста, синтаксический мусор не имеющий никакого отношения к решаемой проблематике.
AS>Да хоть в десяти местах, если это проще, быстрее и удобнее. AS>Только вот скакать придётся как раз по шаблонам в куче мест. А в случае генератора в 99% случаев требуется проверить лишь вход. AS>Про проблему отладки и типизации это ты видимо только с наколеночными (типа python-генераторами) сталкивался. в более серьёзных генераторах даже присутствует наиболее оптимальный выбор типа/алгоритма. AS>Прикрутив тот же clang получаем доступ к AST плюсов в удобном естественном виде. Далее у нас фактически получается расширение компилятора: можем из плюсов генерить другие языки (SQL например), из других языков — плюсы, из плюсов преобразовывать в плюсы, из других языков преобразовывать в другие языки, подсовывать самые оптимальные типы, выбирать самые оптимальные алгоритмы и т.д и т.п. И всё это на этапе компиляции. И везде будет чистый и понятный синтаксис без грамма говнокода. И всё это будет очень просто отлаживать, даже не просто, а элементарно. И скорость компиляции будет реактивная. И IDE с подсказками будут работать идеально. И т.д. и т.п.
Ух ты.. хочу.. Есть какие то конкретные готовые прикладные тулы которые все это делают? Чтобы взять, прикрутить и вперед. Накидай названий серьезных генераторов плз?
Здравствуйте, AeroSun, Вы писали:
AS>... в более серьёзных генераторах даже присутствует наиболее оптимальный выбор типа/алгоритма. AS>Прикрутив тот же clang получаем доступ к AST плюсов в удобном естественном виде. Далее у нас фактически получается расширение компилятора: ... И всё это будет очень просто отлаживать, даже не просто,
А можно взглянуть на это чудо? Нам нужны пруфы Билли.
Здравствуйте, AeroSun, Вы писали:
AS>2 vopl & YuriV:
AS>Сириусли? Не видели готовых генераторов кода? Да тупо что у всех на слуху: gsoap, protobuf, thrif ...
Сириусли. Это костыли. По сравнению с ними метакомпайлер от культей или ODB — верх удобства, т.к. есть EDSLи. Каждый из этих генераторов узко-специализирован и для каждого свой язык, свои тулзы и необходимость включать это всё в билд-систему, а по сему сразу в топку. Как только проект начинает расти поддержка всего этого барахла перевешивает профит от него.
В вопросе я подразумевал что-то обобщённое типа Nitra но для С/С++ и кросплатформу, но ничего подобного вы не продемонстрировали. Из всего этого я делаю вывод, что в прямом свободном/коммерческом доступе такой системы нет, а посему выбор не велик либо чистые плюсы с метапрограммированием, либо ё**ля в присядку с приведённым выше. И вообще, прежде чем расхваливать райские кущи неплохо было бы иметь туда доступ.
AS>Для генерации чего-то большего из исходников — такого никто не даст, ибо у каждого своё know-how, но принцип тупо в первых строчках гугла.
У нас есть нечто подобное — EDSL, который через плагин встроен в гцц, работающий со своим парсером С/С++ и своим представлением PT и AST (по функциональности это приблизительно Nitra). Но эта инфраструктура развивалась в течении ~10 лет и попадёт ли она в публичный доступ не знаю, хотя внутри конторы разговоры ведуться. Мотивацией к созданию своего языка была неповоротливость комитета по С++. Изначально это был более продвинутый макропроцессор, а потом перерос в то, что есть. Кстати, модули и компоненты в нём появились лет 5 назад, сейчас их только причёсывают для соответствия wg21 пейперам.
Здравствуйте, YuriV, Вы писали:
YV>и необходимость включать это всё в билд-систему, а по сему сразу в топку. Как только проект начинает расти поддержка всего этого барахла перевешивает профит от него.
Генерация настраивается раз (в жизни) в отдельную либу. Дальше вся "интеграция" и "поддержка" сводится к копипасте при создании проекта. Всё.
Здравствуйте, smeeld, Вы писали:
S>std::shared_ptr, конечно, шаблон, только это больше библиотечный шаблон. Выше имел ввиду не тупо использование чего-то из STL или boost, а написание своего кода, используя параметризацию типов (своих, не библиотечных).
shared_ptr в стандарте с 2011-ого, а, например, я пользовался самописным аналогом с 1997-ого. Значит ли это, что у меня до 2011-ого была низкая квалификация, а после принятия стандарта резко повысилась?
Здравствуйте, AeroSun, Вы писали:
EP>>std::variant, std::function — к каким случаям относишь? AS>К случаям борьбы с ветряными мельницами. Это должно быть встроенными типами.
С чего-бы это?
Вот если в каком-то конкретном случае мне нужны некоторые другие характеристики, будь то скорость, layout, или гибкость — я могу без проблем сделать свои реализации, заточенные под мои нужды, даже без всяких внешних генераторов.
В случае же со прибитым в язык фичами — такой возможности как правило нет И что, прикручивать генератор под каждую вариацию на тему std::function?
AS>>>Кодогенерация пишется максимум за 1 день, EP>>Зависит от. Какая-то и за 5 минут, иная же может намного дольше — в зависимости от навороченности входного описания, и интеграцией с остальным C++ кодом. EP>>То о чём ты говоришь — скорей всего какой-то один конкретный случай попавшийся тебе лично AS>При любом раскладе добиться похожего результата с помощью метапрограммирования займёт в лучшем случае на порядок больше времени.
В одном из каких-то конкретных случаев — вполне возможно. И я только за кодогенерацию где она оправданна.
Но в целом есть много областей где метапрограммирование рвёт внешние генераторы за счёт тесной интеграции с языком.
AS>Только вот скакать придётся как раз по шаблонам в куче мест. А в случае генератора в 99% случаев требуется проверить лишь вход. AS>Про проблему отладки и типизации это ты видимо только с наколеночными (типа python-генераторами) сталкивался.
Я про примитивную конкатенацию строчек генерируемого кода. "кодогенерация маскимум за 1 день" как раз об этом.
AS>Прикрутив тот же clang получаем доступ к AST плюсов в удобном естественном виде.
Предлагаешь вручную лопатить AST на каждый чих типа variant, function или shared_ptr? И как потом это всё совмещать с друг другом? Например variant от разных function, или function с variant'ом в сигнатуре. И это всё можно положить в кастомный list, с кастомным pool'ом. С шаблонами — это всё комбинируется автоматом, из коробки — так как всё рамках системы типов языка.
С внешним генератором либо нет никакой комбинируемости, либо в итоге те же шаблоны и получаются, только это как чесать левой пяткой правое ухо
EP>>Если не впадать в крайности, то обычно используются и то и другое, а и ещё и макросы препроцессора, ибо везде есть уникальные преимущества, так и уникальные недостатки. AS>Макросы??? Последний раз их использование видел в 2005-2006. Далее во всех компаниях где работал они запрещены (кроме простейших случаев) внутренними соглашениями. Появление любого макроса в коде — это чуть ли не автоматический провал code review. Доказать необходимость его использования — практически неподъемная задача.
А, небось ещё и goto с глобальными переменными запрещены
Здравствуйте, AeroSun, Вы писали:
AS>2 vopl & YuriV: AS>Сириусли? Не видели готовых генераторов кода? Да тупо что у всех на слуху: gsoap, protobuf, thrif ... AS>Для генерации чего-то большего из исходников — такого никто не даст, ибо у каждого своё know-how, но принцип тупо в первых строчках гугла. AS>Вот презенташка: https://www.slideshare.net/corehard_by/clang-55533071
Все перечисленные случаи — это примитивная генерация кода из схемы данных — такое действительно накидывается за день.
Только в первых трёх схема описывается явно, а в четвёртом парсингом C++ объявлений (а-ля Swig или ODB).
Шаблоны/макросы для этой цели хоть и применяются иногда (а-ля BOOST_{FUSION,HANA}_DEFINE_STRUCT, Boost.PFR), далеко не является единственной и исчерпывающей областью их применимости (и да, в некоторых подобных контекстах я предпочитал кодогенерацию).
И судя по приведённым тобой примерам, моя гипотеза о том что говоря о кодогерации рвущей шаблоны ты имеешь в виду какую-то одну область — оказалась верна
хочу.. Есть какие то конкретные готовые прикладные тулы которые все это делают? Чтобы взять, прикрутить и вперед. Накидай названий серьезных генераторов плз?
