BFE>>Допустим у вас есть где-то в коде перечисление: BFE>>
BFE>>enum class ABC { a, b, c };
BFE>>
BFE>>И для этого enum хотите написать код, который позволит пройти во всем значениям перечисления: BFE>>
BFE>>for(const auto e : { ABC::a, ABC::b, ABC::c}) /*...*/;
BFE>>
BFE>>Всё хорошо, пока кто-то не добавит ещё одно значение в ABC: BFE>>
BFE>>enum class ABC { a, b, c, d };
BFE>>
BFE>>После такого изменения цикл становится некорректным. Но если цикл рождает кодогенератор, то проблем нет. Делать такое в custom build steps затруднительно, а вот компилятор мог бы, но...
R>Нет необходимости убеждать меня в полезности кодогенерации — я сам на эту тему ммогу лекцию прочитать. Только при чем здесь C++ времени компиляции, которому посвящена данная тема? Давайте не будем заниматься подменой понятий.
А когда ещё? Во время компиляции код уже разобран (и известно где какие поля и функции), а иначе нам придётся парсить код ещё раз и не факт, что код будет рапарсен одинаково.
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, rg45, Вы писали:
BFE>>>Может быть полезно для кодогенерации.
R>>Для кодогенерации сущесвуют custom build steps, куда можно запихать что угодно и сгенерировать что угодно. BFE>Только вот в некоторых случаях для это нужно иметь инструменты равные компилятору по сложности.
R>> Правда к С++ времени компиляции это имеет мало отношения. C++ времени компиляции — это седьмая фаза трансляции и единственно возможная кодогенерация в этот период — это генерация translation units, которую выполняет сам компилятор.
BFE>Допустим у вас есть где-то в коде перечисление: BFE>
BFE>enum class ABC { a, b, c };
BFE>
BFE>И для этого enum хотите написать код, который позволит пройти во всем значениям перечисления: BFE>
BFE>for(const auto e : { ABC::a, ABC::b, ABC::c}) /*...*/;
BFE>
BFE>Всё хорошо, пока кто-то не добавит ещё одно значение в ABC: BFE>
BFE>enum class ABC { a, b, c, d };
BFE>
BFE>После такого изменения цикл становится некорректным. Но если цикл рождает кодогенератор, то проблем нет. Делать такое в custom build steps затруднительно, а вот компилятор мог бы, но...
BFE>А когда ещё? Во время компиляции код уже разобран (и известно где какие поля и функции), а иначе нам придётся парсить код ещё раз и не факт, что код будет рапарсен одинаково.
Необязательно парсить, можно генерить из условного питона, где эти a,b,c и d задаются.
Здравствуйте, B0FEE664, Вы писали:
R>>Нет необходимости убеждать меня в полезности кодогенерации — я сам на эту тему ммогу лекцию прочитать. Только при чем здесь C++ времени компиляции, которому посвящена данная тема? Давайте не будем заниматься подменой понятий.
BFE>А когда ещё? Во время компиляции код уже разобран (и известно где какие поля и функции), а иначе нам придётся парсить код ещё раз и не факт, что код будет рапарсен одинаково.
Похоже, я чего-то не понял. А что за файлы будут генерироваться при этом? Компилятор будет генерировать какие-то файлы, которые сам же потом и будет обрабатывать что ли? Или Shmj будет генерировать какие-то файлы в компайл-тайме, а компилятор должен будет их подхватить и откомпилировать?
Здравствуйте, McQwerty, Вы писали:
S>>> Файл создать — никак?
N>>Зойчем?
MQ>А потом его #include.
Я, конечно, помню ещё, что когда язык крестовых шаблонов стал тьюринг-полным, он потеснил с пьедестала "самого извращённого функционального языка" находившегося там лет 30 m4, и он претендует на нишу, имеющую много общего.
Но если ставить в принципе задачу что-то сгенерировать из исходников в момент выполнения make, и не форсировать себе использование средств определённого типа — возможности резко расширяются.
Здравствуйте, rg45, Вы писали:
BFE>>А когда ещё? Во время компиляции код уже разобран (и известно где какие поля и функции), а иначе нам придётся парсить код ещё раз и не факт, что код будет рапарсен одинаково. R>Похоже, я чего-то не понял. А что за файлы будут генерироваться при этом? Компилятор будет генерировать какие-то файлы, которые сам же потом и будет обрабатывать что ли? Или Shmj будет генерировать какие-то файлы в компайл-тайме, а компилятор должен будет их подхватить и откомпилировать?
Вечность впереди — много или мало?
Считаю, что в конечном итоге из C++ должен получится монстр включающий все возможные техники и парадигмы программирования. Поэтому — да, рефлексия будет добавлена в том или ином виде. Добавить генерацию файлов в компайл-тайме — чем плохо? И чем плохо это делать через внешние файлы? У нас есть успешные примеры с внешними инструментами (тот же Qt). Как по мне, так это лучше сделать с помощью компилятора, чем внешнего инструмента.
Здравствуйте, B0FEE664, Вы писали:
BFE>Считаю, что в конечном итоге из C++ должен получится монстр включающий все возможные техники и парадигмы программирования.
Т.е. вы настолько оптимистичны, что считаете, что этого еще не случилось?
Здравствуйте, B0FEE664, Вы писали:
BFE>Считаю, что в конечном итоге из C++ должен получится монстр включающий все возможные техники и парадигмы программирования. Поэтому — да, рефлексия будет добавлена в том или ином виде. Добавить генерацию файлов в компайл-тайме — чем плохо? И чем плохо это делать через внешние файлы? У нас есть успешные примеры с внешними инструментами (тот же Qt). Как по мне, так это лучше сделать с помощью компилятора, чем внешнего инструмента.
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, B0FEE664, Вы писали:
R>Нет необходимости убеждать меня в полезности кодогенерации — я сам на эту тему ммогу лекцию прочитать.
Посоветуйте тогда (оба ) ЯП с кодогонерацией, в той же нише, что и плюсы. Т.е. без виртуальной машины (не .Net/JVM/JS). Спрашиваю для расширения кругозора, без конкретной цели.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, B0FEE664, Вы писали:
BFE>>Считаю, что в конечном итоге из C++ должен получится монстр включающий все возможные техники и парадигмы программирования.
S>Т.е. вы настолько оптимистичны, что считаете, что этого еще не случилось?
Ну вот call/cc, например, в него не успели встроить. А ведь есть языки, где это база, через которую строится всё остальное.
Думаю, к C++41 вполне успеют.
Закостылять на корутинах и лямбдах можно, но путано и дорого.
S>PS. Простите, не удержался...
Здравствуйте, Alekzander, Вы писали:
A>Посоветуйте тогда (оба ) ЯП с кодогонерацией, в той же нише, что и плюсы. Т.е. без виртуальной машины (не .Net/JVM/JS). Спрашиваю для расширения кругозора, без конкретной цели.
Ты имеешь в виду ран-тайм кодогенерацию, наподобие дотнетовых Emit и CodeDOM, или же генерацию исходного текста программ?
Здравствуйте, rg45, Вы писали:
A>>Посоветуйте тогда (оба ) ЯП с кодогонерацией, в той же нише, что и плюсы. Т.е. без виртуальной машины (не .Net/JVM/JS). Спрашиваю для расширения кругозора, без конкретной цели.
R>Ты имеешь в виду ран-тайм кодогенерацию, наподобие дотнетовых Emit и CodeDOM, или же генерацию исходного текста программ?
Типа макросов Nemerle А если этот ЯП в итоге транспилируется в C++ (как сами плюсы изначально транспилировались в си), то я даже знаю, где применить
Здравствуйте, Alekzander, Вы писали:
A>Типа макросов Nemerle А если этот ЯП в итоге транспилируется в C++ (как сами плюсы изначально транспилировались в си), то я даже знаю, где применить
Здравствуйте, Alekzander, Вы писали:
R>>Ты имеешь в виду ран-тайм кодогенерацию, наподобие дотнетовых Emit и CodeDOM, или же генерацию исходного текста программ?
A>Типа макросов Nemerle
Из относительно массовых только rust наверно, там есть полноценные процедурные макросы, правда гораздо менее удобные чем в немерле, так как из коробки работают только с токенами, но есть библиотеки который их поднимают до уровня квазицитирования. С файловой системой, и даже с сетью, эти макросы отлично могут работать Разработчик показал, как получить SSH-ключ с помощью compile-time макроса в Rust в VSCode просто при открытии приложения
A>А если этот ЯП в итоге транспилируется в C++ (как сами плюсы изначально транспилировались в си), то я даже знаю, где применить
Тут разве что nim, там есть макросы близкие к процедурным и шаблоны уровня C++, еще возможно haxe но не помню как там с макросами. Оба умеют транслироваться в си, а nim и в с++.
Здравствуйте, netch80, Вы писали:
S>>Т.е. вы настолько оптимистичны, что считаете, что этого еще не случилось?
N>Ну вот call/cc, например, в него не успели встроить.
А что, call/cc -- это необходимое условие для того, чтобы язык считался монстром?
Одной россыпи UB в языке (как унаследованной из C, так и собственной) уже вполне достаточно. А если добавить сюда еще и список способов инициализации локальных переменных...
Здравствуйте, sergii.p, Вы писали:
SP>кстати вопрос не такой смешной. Открытием для меня стало, что файл открыть в расте таки можно. После этого мне кажется до конопли остался один шаг
Справедливости ради, это макрос. В константных функциях раста так не получится.
Здравствуйте, Alekzander, Вы писали:
R>>Нет необходимости убеждать меня в полезности кодогенерации — я сам на эту тему ммогу лекцию прочитать. A>Посоветуйте тогда (оба ) ЯП с кодогонерацией, в той же нише, что и плюсы. Т.е. без виртуальной машины (не .Net/JVM/JS). Спрашиваю для расширения кругозора, без конкретной цели.
Я про другие языки ничего не скажу, а вот в C/C++ кодогенерация применяется, но с помощью внешних инструментов (всякие там Lex и YACC). Как правило генерация производится на основании некого формального (на спец. языке) описания структуры/интерфейса/устройства/данных, которое подаётся на вход инструмента, а на выходе получается код на С/С++. Простейший вариант — это взять картинку и сгенерировать массив пикселей этой картинки вида: const unsigned int imageLogo[40][180] = {{61309,1309,61309,61309, ...};.
А вот если надо взять код на C++ и на его основе сгенерировать какой-то добавочный код, вот тогда это уже довольно редко бывает. На практике для этих целей применяется, наверное, только Qt moc. По крайней мере других таким инструментов я не использовал. Отчасти это понятно, так как однажды сгенерированный код можно просто добавить в проект, а отслеживание изменений переложить на программиста, но иногда хочется большего.
