На хабре вышла хорошая статья от ПВС о новшествах С++17: https://habrahabr.ru/company/pvs-studio/blog/340014/

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, Kluev, Вы писали:

K>>>>Опережающее описание для вложенных классов в каком тысячелетии сделают?

S>>>А это что?

K>>Опережающее описание. Для вложенных классов.

S>В виде примеров кода вы свои хотелки выразить можете? Как по поводу вложенных классов, так и по поводу строк в качестве параметров для шаблонов.

S>Или в ваши намерения конструктивное общение не входит?

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

Здравствуйте, alex_public, Вы писали:

_>1. Конечно Boost.Metaparse требуется не всему сообществу. Более того, оно необходимо явному меньшинству. Только вот если говорить об оставшемся большинстве, то его адекватная часть никогда не заявит чего-то вроде "ну мне лично эта функциональность не нужна, поэтому и в языке она не нужна". В худшем случае они скажут, что подобное нововведение в язык им безразлично (ни лучше, ни хуже им от него не будет), а в лучшем случае порадуются за коллег, которым станет намного проще жить. И только неадекватная часть сообщества будет против подобного нововведение по причине отсутствия у них подобных задач. Я как-то надеялся что на этом форуме неадекватные не встретятся...

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

_>2. Я не думаю что авторам Boost.Metaparse нравятся те жуткие костыли с передачей строк в шаблоны. Но другого способа в C++ сейчас просто нет.

Хорошего способа нет, но нужно обязательно сделать парсинг в compile-time через строки в параметрах шаблона. Потом пожаловаться, что получается коряво, и нужно дать больше возможностей для строк в параметрах шаблона. Ну OK. Тоже вариант.

_>Ну ты можешь предложить любое другое решение (без шаблонов) из других языков для решения этой же задачи? )

CTFE и mixin-ы из D. Без шаблонов. На вход функции подается строка с DSL-ем внутри, на выходе строка с D-шным кодом, результирующая строка скармливается mixin-у. Очень простой подход, легко тестировать и отлаживать.

Никогда не работал с макросами Rust-а и Scala. Но, на макросах Rust-а делается весьма себе продвинутый print!, в compile-time.

Есть язык Gosu для JVM, в котором сделали систему плагинов для компилятора и некую штуку под названием Open Type System. Позволяет использовать вообще разные DSL-и (здесь небольшой пример с XSD описывается).

_>>>Кстати, если было нужно только имя типа для лога, то с этим по идее банальный RTTI справился бы. )
S>>Нет.

_>Почему? ) В данном случае же он статический, так что даже теоретических провалов в производительности быть не может. Какие ещё возражения то? )

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

_>Ну лично мне просто очень нравится ряд возможностей языка D и я считаю, что можно абсолютно безболезненно перенести процентов 80 их в C++, чтобы он стал действительно отличным инструментом. В первую очередь статическую интроспекцию, потом элементы метапрограммирования (вычисления на этапе компиляции, функцию mixin, нормальные параметры шаблонов и т.п.), всякие мелкие удобства (типа особых перегруз операторов и т.п.) и т.д. Ну и кстати в не большой степени этот процесс идёт (из последнего это "constexpr if" — 100% копия "static if" из D), но как-то очень медленно...

AFAIK, static if в D может применяться в гораздо большем числе контекстов, чем if constexpr в C++. Так, static if в D может использоваться, например, для формирования содержимого класса. В C++, насколько я знаю, внутри класса if constexpr использоваться не может, только внутри функций. Так что не 100% копия.

Здравствуйте, Анатолий Широков, Вы писали:

АШ>На хабре вышла хорошая статья от ПВС о новшествах С++17: https://habrahabr.ru/company/pvs-studio/blog/340014/
Первая мысль была что они проверили реализацию одного из компиляторов.

Alexander G:

AG>Я бы не сказал, что union не может хранить non-POD типы. Уже есть unrestricted unions начиная с С++11.
Еще бы рефлексию хорошую, и можно будет эффектно взламывать private

johny5:

ДФ>>Еще бы рефлексию хорошую, и можно будет эффектно взламывать private
J>#define private public
Неа. Саттер раскритиковал такое рещение как неуниверсальное.
У методов с разным спецификатором доступа может быть разный мэнглинг.

Здравствуйте, Kluev, Вы писали:

АШ>>На хабре вышла хорошая статья от ПВС о новшествах С++17: https://habrahabr.ru/company/pvs-studio/blog/340014/

K>Опережающее описание для вложенных классов в каком тысячелетии сделают?

А это что?

K>строка как параметр шаблона?

Вроде как только в D такое есть. Насколько часто это там используется? Можно пример того, что бы вам хотелось сделать в C++ с помощью данной фичи?

K>enum в строку и обратно?

Когда добавят compile-time рефлексию и/или метаклассы, это появится. Т.е. в С++20 или C++23 можно ждать.

K>PS: Ящитаю, что язык давно пора объявлять deprecated. Хотя бы назначить дату прекращения разработки вместо того чтобы продолжать на пол шишечки насиловать труп.

А с мегатоннами легаси что делать?

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, Kluev, Вы писали:

АШ>>>На хабре вышла хорошая статья от ПВС о новшествах С++17: https://habrahabr.ru/company/pvs-studio/blog/340014/

K>>Опережающее описание для вложенных классов в каком тысячелетии сделают?

S>А это что?

Опережающее описание. Для вложенных классов.

S>Когда добавят compile-time рефлексию и/или метаклассы, это появится. Т.е. в С++20 или C++23 можно ждать.

все это было нужно еще в с++98

K>>PS: Ящитаю, что язык давно пора объявлять deprecated. Хотя бы назначить дату прекращения разработки вместо того чтобы продолжать на пол шишечки насиловать труп.

S>А с мегатоннами легаси что делать?

для легаси можно использовать С++RipEdition

Также, в отличие от union, std::variant позволяет хранить non-POD типы.

Я бы не сказал, что union не может хранить non-POD типы. Уже есть unrestricted unions начиная с С++11.

Здравствуйте, Анатолий Широков, Вы писали:

АШ>На хабре вышла хорошая статья от ПВС о новшествах С++17: https://habrahabr.ru/company/pvs-studio/blog/340014/

pdf-ку бы

Здравствуйте, Анатолий Широков, Вы писали:

АШ>На хабре вышла хорошая статья от ПВС о новшествах С++17: https://habrahabr.ru/company/pvs-studio/blog/340014/

Наконец-то нормальный язык начал получаться

А не встречали подобных статей по 11/14ым стандартам?

Кстати, какая студия 17ый стандарт поддерживает?

Здравствуйте, Marty, Вы писали:

M>Кстати, какая студия 17ый стандарт поддерживает?

Можно здесь отслеживать и фичи и версии, в которых они реализованы: http://en.cppreference.com/w/cpp/compiler_support

Здравствуйте, Дрободан Фрилич, Вы писали:

ДФ>Alexander G:

ДФ>Еще бы рефлексию хорошую, и можно будет эффектно взламывать private

#define private public

Здравствуйте, Анатолий Широков, Вы писали:

АШ>На хабре вышла хорошая статья от ПВС о новшествах С++17: https://habrahabr.ru/company/pvs-studio/blog/340014/
То самое чувство когда вместо модулей колбасы привезли сахар. Причём в кубиках.

Вопрос:
Когда будет нормальное управление инлайнингом для time critical кода или тоже потом? Вот прямо сейчас два уважающих (или нет?) компилятора Visual Studio 2015 и Intel Parallel Studio 2017 сосут лапу (или что покрупнее?) на инлайне, так что приходится ему подсказывать через __forceinline. По другому эти творения инженерной мысли не понимают.

Здравствуйте, Vain, Вы писали:

V>Вопрос:
V>Когда будет нормальное управление инлайнингом для time critical кода или тоже потом? Вот прямо сейчас два уважающих (или нет?) компилятора Visual Studio 2015 и Intel Parallel Studio 2017 сосут лапу (или что покрупнее?) на инлайне, так что приходится ему подсказывать через __forceinline. По другому эти творения инженерной мысли не понимают.

По идее, ты можешь участвовать в формировании языка, направляя предложения в комитет по стандартизации С++ через рабочую группы: https://stdcpp.ru/

Здравствуйте, Анатолий Широков, Вы писали:

АШ>На хабре вышла хорошая статья от ПВС о новшествах С++17: https://habrahabr.ru/company/pvs-studio/blog/340014/

Опережающее описание для вложенных классов в каком тысячелетии сделают?
switch по строкам?
строка как параметр шаблона?
enum в строку и обратно?

PS: Ящитаю, что язык давно пора объявлять deprecated. Хотя бы назначить дату прекращения разработки вместо того чтобы продолжать на пол шишечки насиловать труп.

Здравствуйте, Kluev, Вы писали:

K>>>Опережающее описание для вложенных классов в каком тысячелетии сделают?

S>>А это что?

K>Опережающее описание. Для вложенных классов.

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

Или в ваши намерения конструктивное общение не входит?

Здравствуйте, so5team, Вы писали:

K>>строка как параметр шаблона?
S>Вроде как только в D такое есть. Насколько часто это там используется? Можно пример того, что бы вам хотелось сделать в C++ с помощью данной фичи?

Очень много чего можно делать с помощью этой возможности, о чём в C++ можно только мечтать. Вот http://vibed.org/docs#html-templates известный пример (если что, приложение собирается без всяких препроцессоров, только компилятором D). В общем можно задавать различные EDSL в качестве строк (при этом разбираемым в процессе компиляции и превращаемыми в код). Правда для удобной работы с подобными инструментами требуется не только задание строки, как параметра шаблона, но и нормальная работа со строками (применение различных строковых функций и т.п.) во время компиляции. Но это уже проще добавить, собственно развитие подхода constexpr движется в этом направление, только очень медленно.

Кстати, в современном C++ уже написано множество страшнейших велосипедов для эмуляции слабого подобия подобной функциональности из D, в основном через посимвольное задание строк времени компиляции. Так что очевидно, что имеется огромная проблема в этой области.

Здравствуйте, alex_public, Вы писали:

K>>>строка как параметр шаблона?
S>>Вроде как только в D такое есть. Насколько часто это там используется? Можно пример того, что бы вам хотелось сделать в C++ с помощью данной фичи?

_>Очень много чего можно делать с помощью этой возможности, о чём в C++ можно только мечтать. Вот http://vibed.org/docs#html-templates известный пример (если что, приложение собирается без всяких препроцессоров, только компилятором D).

Покажите, пожалуйста, пальцем на конкретный пример из документации. Может быть речь идет вот об этом?:

router.get("/", staticTemplate!"index.dt");

Если так, то что staticTemplate делает с именем "index.dt" в компайл-тайм? Загружает содержимое файла с именем "index.dt" и генерирует из него D-шный код?

Здравствуйте, so5team, Вы писали:

_>>Очень много чего можно делать с помощью этой возможности, о чём в C++ можно только мечтать. Вот http://vibed.org/docs#html-templates известный пример (если что, приложение собирается без всяких препроцессоров, только компилятором D).
S>Покажите, пожалуйста, пальцем на конкретный пример из документации. Может быть речь идет вот об этом?:
S>

router.get("/", staticTemplate!"index.dt");

S>Если так, то что staticTemplate делает с именем "index.dt" в компайл-тайм? Загружает содержимое файла с именем "index.dt" и генерирует из него D-шный код?

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

Здравствуйте, alex_public, Вы писали:

S>>Если так, то что staticTemplate делает с именем "index.dt" в компайл-тайм? Загружает содержимое файла с именем "index.dt" и генерирует из него D-шный код?

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

Ну тогда ключевой момент здесь вовсе не в строковом параметре шаблона, а в двух свойствах D-шной конструкции mixin, которой вообще нет в C++: a) возможность взять содержимое внешнего файла и b) возможность отдать компилятору строку для включения ее содержимого в процесс компиляции (строка может быть сформирована и в compile-time). При наличии возможности инжекции нового кода в C++ можно было бы обойтись и без строковых параметров шаблонов, только за счет constexpr. Тогда, теоретически, можно было бы сделать что-то вроде:

constexpr auto index_template() {
  return R"template{...}template";
}
...
router.get("/", make_page(index_template());
...
}

Проблема отсутствия таких средств в C++ на данный момент в большей степени в отсутствии средств инжекции (вероятно, Саттер сейчас эту тему продвинет) и, возможно, в более слабых возможностях constexpr-функций/типов в C++ по сравнению с CTFE в D.

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

Здравствуйте, so5team, Вы писали:

_>>Да, именно так. Причём всё это делается исключительно средствами метапрограммирования на шаблонах, такого же идеологически, как и в C++, только гораздо более продвинутого.
S>Ну тогда ключевой момент здесь вовсе не в строковом параметре шаблона, а в двух свойствах D-шной конструкции mixin, которой вообще нет в C++: a) возможность взять содержимое внешнего файла и b) возможность отдать компилятору строку для включения ее содержимого в процесс компиляции (строка может быть сформирована и в compile-time). При наличии возможности инжекции нового кода в C++ можно было бы обойтись и без строковых параметров шаблонов, только за счет constexpr. Тогда, теоретически, можно было бы сделать что-то вроде:
S>

constexpr auto index_template() {
S>  return R"template{...}template";
S>}
S>...
S>router.get("/", make_page(index_template());
S>...
S>}

S>Проблема отсутствия таких средств в C++ на данный момент в большей степени в отсутствии средств инжекции (вероятно, Саттер сейчас эту тему продвинет) и, возможно, в более слабых возможностях constexpr-функций/типов в C++ по сравнению с CTFE в D.

S>Изначальный же вопрос, на который хотелось бы получить ответ, касается именно использования строк как параметров шаблонов. Если в 99% процентах случаев в D строки-параметры нужны только для последующих mixin-ов, то понятно. Если есть какие-то другие кейсы, то интересно было бы их увидеть.

Безусловно функция mixin из D является очень мощным инструментом, которого так же не хватает в C++. Однако для создания различных EDSL она совершенно не обязательна. Это можно легко увидеть на примере тех же C++ реализаций разные EDSL, типа sqlpp11, boost.spirit, boost.xpressive и т.п. — для генерации кода не требуется обязательное задание его строками. Это нужно только для такого редкого случая (кстати в языке шаблонов vibe.d как раз этот случай), когда данный DSL позволяет делать произвольные вставки на базовом языке. И то наверное можно выкрутиться (например через лямбды) и обойтись без mixin, хотя это будет уже не так красиво.

А вот полноценная работа со строками в шаблонах позволяет делать совершенно другие вещи. Например можно будет вместо такой "db(select(all_of(p)).from(p).where(p.id > id))" строки на sqlpp11 написать что-то вроде "query("select * from Person where id>{}", id)", что намного симпатичнее. При этом сохранив проверку корректности sql запроса и соответствия типов параметров во время компиляции. Ну и кстати данное направление сейчас активно развивается в C++ и в виде различных библиотек (например https://github.com/irrequietus/typestring) и в виде предложений в стандарт (например http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4121.pdf) и собственно в Boost'е есть некоторые решения (http://www.boost.org/doc/libs/1_65_1/libs/hana/doc/html/structboost_1_1hana_1_1string.html). Однако это всё выглядит какими-то кривыми костылями на фоне чистого и красивого решения в D...

Здравствуйте, alex_public, Вы писали:

Простите, но вы уходите в сторону от первоначального вопроса. Речь не про то, нужна ли в C++ работа со строками в compile-time (она нужна, но она может быть получена и применена разными способами (свежий пример)). Вопрос конкретно в строковых шаблонных параметрах. Таковые, afaik, есть только в D. Если они там широко применяются, то интересно взглянуть на примеры оного. Если 99% таких примеров ведет в конечном итоге к вызову mixin, то вопрос закрыт. Если есть еще какие-то примеры, то на них хочется посмотреть.

Здравствуйте, so5team, Вы писали:

S>Простите, но вы уходите в сторону от первоначального вопроса. Речь не про то, нужна ли в C++ работа со строками в compile-time (она нужна, но она может быть получена и применена разными способами (свежий пример)). Вопрос конкретно в строковых шаблонных параметрах.

А какой ещё в C++ есть механизм вычислений во время компиляции, как не через шаблоны? )))

S>Таковые, afaik, есть только в D. Если они там широко применяются, то интересно взглянуть на примеры оного. Если 99% таких примеров ведет в конечном итоге к вызову mixin, то вопрос закрыт. Если есть еще какие-то примеры, то на них хочется посмотреть.

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

Здравствуйте, alex_public, Вы писали:

S>>Простите, но вы уходите в сторону от первоначального вопроса. Речь не про то, нужна ли в C++ работа со строками в compile-time (она нужна, но она может быть получена и применена разными способами (свежий пример)). Вопрос конкретно в строковых шаблонных параметрах.

_>А какой ещё в C++ есть механизм вычислений во время компиляции, как не через шаблоны? )))

constexpr-функции и user-defined literals, как в примере по ссылке, показанной выше.

S>>Таковые, afaik, есть только в D. Если они там широко применяются, то интересно взглянуть на примеры оного. Если 99% таких примеров ведет в конечном итоге к вызову mixin, то вопрос закрыт. Если есть еще какие-то примеры, то на них хочется посмотреть.

_>Так в предыдущем сообщение я как раз ответил на этот вопрос, причём с конкретными примерами. Надо ещё больше разжевать?)

Давайте еще раз. Примеры из D, которые в итоге сводятся к D-шной фиче mixin, понятны. Интересны другие примеры, когда строка как параметр шаблона нужна, а mixin при этом не используется. Это уже несколько раз подчеркивалось.

Здравствуйте, Анатолий Широков, Вы писали:

АШ>На хабре вышла хорошая статья от ПВС о новшествах С++17: https://habrahabr.ru/company/pvs-studio/blog/340014/

оно ещё не сдохло? а то я уже учить собрался.

Здравствуйте, so5team, Вы писали:

S>>>Простите, но вы уходите в сторону от первоначального вопроса. Речь не про то, нужна ли в C++ работа со строками в compile-time (она нужна, но она может быть получена и применена разными способами (свежий пример)). Вопрос конкретно в строковых шаблонных параметрах.
_>>А какой ещё в C++ есть механизм вычислений во время компиляции, как не через шаблоны? )))
S>constexpr-функции и user-defined literals, как в примере по ссылке, показанной выше.

constexpr-функции C++ не умеют работать со строками, опять же в отличие от D. Если бы умели, то возможно это было бы часть решения проблемы.

S>>>Таковые, afaik, есть только в D. Если они там широко применяются, то интересно взглянуть на примеры оного. Если 99% таких примеров ведет в конечном итоге к вызову mixin, то вопрос закрыт. Если есть еще какие-то примеры, то на них хочется посмотреть.
_>>Так в предыдущем сообщение я как раз ответил на этот вопрос, причём с конкретными примерами. Надо ещё больше разжевать?)
S>Давайте еще раз. Примеры из D, которые в итоге сводятся к D-шной фиче mixin, понятны. Интересны другие примеры, когда строка как параметр шаблона нужна, а mixin при этом не используется. Это уже несколько раз подчеркивалось.

И где во фразе "парсинг строковых DSL" есть хоть малейший намёк на применение mixin? )

Здравствуйте, alex_public, Вы писали:

_>>>А какой ещё в C++ есть механизм вычислений во время компиляции, как не через шаблоны? )))
S>>constexpr-функции и user-defined literals, как в примере по ссылке, показанной выше.

_>constexpr-функции C++ не умеют работать со строками, опять же в отличие от D. Если бы умели, то возможно это было бы часть решения проблемы.

И давно он разучился? https://wandbox.org/permlink/dtsaTlrlAXOMwL2t (обратите внимание на флаги, там чистый C++14, без гнутых расширений).

S>>Давайте еще раз. Примеры из D, которые в итоге сводятся к D-шной фиче mixin, понятны. Интересны другие примеры, когда строка как параметр шаблона нужна, а mixin при этом не используется. Это уже несколько раз подчеркивалось.

_>И где во фразе "парсинг строковых DSL" есть хоть малейший намёк на применение mixin? )

Парсинг строковых DSL в D, насколько мне известно, в большинстве случаев в итоге приводит к последующему mixin. Если это не так, то можно ли увидеть пример такого парсинга?

Здравствуйте, so5team, Вы писали:

_>>constexpr-функции C++ не умеют работать со строками, опять же в отличие от D. Если бы умели, то возможно это было бы часть решения проблемы.
S>И давно он разучился? https://wandbox.org/permlink/dtsaTlrlAXOMwL2t (обратите внимание на флаги, там чистый C++14, без гнутых расширений).

А теперь ct_strcat можно продемонстрировать? )))

S>>>Давайте еще раз. Примеры из D, которые в итоге сводятся к D-шной фиче mixin, понятны. Интересны другие примеры, когда строка как параметр шаблона нужна, а mixin при этом не используется. Это уже несколько раз подчеркивалось.
_>>И где во фразе "парсинг строковых DSL" есть хоть малейший намёк на применение mixin? )
S>Парсинг строковых DSL в D, насколько мне известно, в большинстве случаев в итоге приводит к последующему mixin. Если это не так, то можно ли увидеть пример такого парсинга?

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

mixin требуется только если в используемом DSL будет присутствовать внедрённый D/C++ код. Если же такого нет (например если мы напишем шаблон на vibe.d без встраиваемого D кода, что является абсолютно нормальным сценарием), то нет никакой необходимости в использование mixin. Или же если бы у нас была возможность в C++ распарсить во время компиляции такую "select * from Person where id=={}" строку, то нам не понадобилось бы введение ещё и функции mixin для решения задачи — распарсенные элементы запроса транслировались бы в уже существующие функции библиотеки sqlpp11.

P.S. Я в принципе не против введение в C++ и функции типа mixin — это тоже крайне полезный инструмент для определённых целей (особенно если добавить к этому возможность перегрузки произвольного оператора https://dlang.org/spec/operatoroverloading.html#dispatch — это позволяет делать уникальные вещи). Однако возможность полноценной работы со строками во время компиляции (в том числе и передача их в шаблоны) — это совершенно другой инструмент, намного более мощный и полезный.

Здравствуйте, alex_public, Вы писали:

_>>>constexpr-функции C++ не умеют работать со строками, опять же в отличие от D. Если бы умели, то возможно это было бы часть решения проблемы.
S>>И давно он разучился? https://wandbox.org/permlink/dtsaTlrlAXOMwL2t (обратите внимание на флаги, там чистый C++14, без гнутых расширений).

_>А теперь ct_strcat можно продемонстрировать? )))

Это, блин, что, конкурс на слабо? В Интернете полно примеров того, как в compile-time сделать конкатенацию строк в C++. Какие-то из них работают в C++14, какие-то нуждаются в C++17. Вы хотите, чтобы их вам нашли и показали?

Опять же, для работы со строками в compile-time не обязательно иметь конкатенацию строк. Если мы говорим про разбор SQL-выражения или JSON-а, то достаточно просто возможности проитерироваться по строке в compile-time. Например, этой возможностью пользуется библиотека json (https://github.com/nlohmann/json#serialization--deserialization).

_>Я же вроде уже всё подробно писал.

Вы написали свое мнение. Вопрос был о примерах. Примеров кода не было. Повторюсь, интересны примеры кода, где что-то вот такое:

some_class<"bla-bla-bla", "boo-boo-boo"> object;

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

_>mixin требуется только если в используемом DSL будет присутствовать внедрённый D/C++ код.

Mixin нужен не только для этого. Но и для того, чтобы в процессе парсинга строки в compile-time сгенерировать кусок нового D-шного кода и заинжектить его в D-шный код. Насколько я знаю, других способов инжектить код в compile-time в D нет. И, насколько я помню, для этих целей mixin в D применяется чрезвычайно широко.

Здравствуйте, so5team, Вы писали:

_>>А теперь ct_strcat можно продемонстрировать? )))
S>Это, блин, что, конкурс на слабо? В Интернете полно примеров того, как в compile-time сделать конкатенацию строк в C++. Какие-то из них работают в C++14, какие-то нуждаются в C++17. Вы хотите, чтобы их вам нашли и показали?

Безусловно. Более того, самые известные примеры решения этой задачи я как раз продемонстрировал в предыдущем сообщение. Но в том то и дело, что для решения этой задачи в C++ приходится изобретать дикие костыли (специальные уродливые типы строк), в то время как в D вся работа происходит обычными строковыми функциями с обычными строками, только во время компиляции (если все параметры у соответствующих функций являются "constexpr", причём это опять же не надо указывать руками, а компилятор определяет сам).

_>>Я же вроде уже всё подробно писал.
S>Вы написали свое мнение. Вопрос был о примерах. Примеров кода не было. Повторюсь, интересны примеры кода, где что-то вот такое:
S>

some_class<"bla-bla-bla", "boo-boo-boo"> object;

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

Так, что-то это совсем стало утомлять. Давай ты русским языком объяснишь чем это "парсер DSL, заданных строками" (уже 3 раза указанный!) не является примером кода, в котором в C++ или D требуется использование передачи строки в качестве параметра шаблона.

_>>mixin требуется только если в используемом DSL будет присутствовать внедрённый D/C++ код.
S>Mixin нужен не только для этого. Но и для того, чтобы в процессе парсинга строки в compile-time сгенерировать кусок нового D-шного кода и заинжектить его в D-шный код. Насколько я знаю, других способов инжектить код в compile-time в D нет. И, насколько я помню, для этих целей mixin в D применяется чрезвычайно широко.

А с чего это DSL вообще понадобилось "генерировать новый код и инжектить его"? Что за глупости? ))) Если ты так считаешь, то видимо тогда для тебя boost.spirit и т.п. C++ библиотеки работают какой-то магией? ))) Потому как никаких mixin в C++ нет, а вот встраиваемые DSL'и вполне себе работают. Вот только задавать их строками не получается.

Здравствуйте, alex_public, Вы писали:

_>Но в том то и дело, что для решения этой задачи в C++ приходится изобретать дикие костыли (специальные уродливые типы строк), в то время как в D вся работа происходит обычными строковыми функциями с обычными строками, только во время компиляции (если все параметры у соответствующих функций являются "constexpr", причём это опять же не надо указывать руками, а компилятор определяет сам).

Коллега, пожалуйста, читайте то, что вам пишут. В частности:

Речь не про то, нужна ли в C++ работа со строками в compile-time (она нужна, но она может быть получена и применена разными способами (свежий пример)). Вопрос конкретно в строковых шаблонных параметрах.

Тогда у вас не будет складываться ощущения, что ваши слова игнорируются, а то, что вы отвечаете -- не читают.

S>>Вы написали свое мнение. Вопрос был о примерах. Примеров кода не было. Повторюсь, интересны примеры кода, где что-то вот такое:
S>>

some_class<"bla-bla-bla", "boo-boo-boo"> object;

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

_>Так, что-то это совсем стало утомлять. Давай ты русским языком объяснишь чем это "парсер DSL, заданных строками" (уже 3 раза указанный!) не является примером кода, в котором в C++ или D требуется использование передачи строки в качестве параметра шаблона.

Потому, что "парсер DSL, заданный строками" -- это не пример кода. Это описание примера кода, который (код в смысле), может быть где-то есть. Может быть и нет. Может быть он есть в виде proof-of-concept или курсовой какого-нибудь студента, попробовали, порадовались результату и нигде больше не используют.

Надеюсь во фразе "интересны примеры кода" понятны все буквы?

Пока из примеров кода была ссылка на vibe.d. Ok. Но что есть еще?

_>Очень много чего можно делать с помощью этой возможности, о чём в C++ можно только мечтать. Вот http://vibed.org/docs#html-templates известный пример (если что, приложение собирается без всяких препроцессоров, только компилятором D). В общем можно задавать различные EDSL в качестве строк (при этом разбираемым в процессе компиляции и превращаемыми в код).

IMHO, это прямой путь с write-only коду и фрагментации языка. Каждый начнет делать свой макроязык, понятный только ему. Разбираться в таком коде (как он работает) станет сильно сложнее (хотя герою-писателю такого кода будет, конечно, насрать на тех, кто в этом коде будет разбираться). Кодогенерация в исходнике — это классная игрушка для того, кто пишет код и неоправданное усложнение для того, кто его читает и поддерживает. Такие вещи нужно делать внешними инструментами типа Qt MOC или LibTooling.

Здравствуйте, so5team, Вы писали:

_>>Так, что-то это совсем стало утомлять. Давай ты русским языком объяснишь чем это "парсер DSL, заданных строками" (уже 3 раза указанный!) не является примером кода, в котором в C++ или D требуется использование передачи строки в качестве параметра шаблона.
S>Потому, что "парсер DSL, заданный строками" -- это не пример кода. Это описание примера кода, который (код в смысле), может быть где-то есть. Может быть и нет. Может быть он есть в виде proof-of-concept или курсовой какого-нибудь студента, попробовали, порадовались результату и нигде больше не используют.

Т.е. область применения сложно самому осмыслить и нужны конкретные исходники? ) Ну ОК. Смотри тогда например сюда http://www.boost.org/doc/libs/1_65_1/doc/html/metaparse.html — вроде как библиотека включённая в Boost уже не считается курсовой какого-нибудь студента? ))) А теперь взгляни как у них реализована передача строки в качестве параметров шаблонов (собственно это стандартный убогий костыль в современном C++): http://www.boost.org/doc/libs/1_65_1/doc/html/metaparse/getting_started_with_boost_metap.html#metaparse.getting_started_with_boost_metap.2_the_text_to_parse. Так вот, если ты озвучишь авторам этой библиотеки свою точку зрения о том, что в C++ нет особой необходимости в нормальном использование строк в шаблонах, то боюсь они тебя просто сожгут на костре. )))

S>Надеюсь во фразе "интересны примеры кода" понятны все буквы?
S>Пока из примеров кода была ссылка на vibe.d. Ok. Но что есть еще?

А что, мало? ) Так ты тогда озвучь сколько конкретно тебе надо примеров, чтобы это начало считаться для тебя аргументом. Один, десять, сто? )

Здравствуйте, alex_public, Вы писали:

_>Т.е. область применения сложно самому осмыслить и нужны конкретные исходники?

Блин, да я уже не знаю, как сказать это еще более понятно: нужность в C++ средств работы со строками в compile-time под сомнение не ставится. Ну вот вообще.

Нужны ли в C++ строки как параметры шаблона, чтобы кто-то мог написать:

super::duper::sql::statement<"select * from my_table where id={}"> stm{connection};

это тема отдельного разговора и по этому поводу могут быть разные мнения. В том числе тех, кому извращения из Boost-а нравятся и тех, кому не нравятся. Это тема _отдельного_ разговора.

S>>Пока из примеров кода была ссылка на vibe.d. Ok. Но что есть еще?

_>А что, мало? )

Да.

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

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

_>Один, десять, сто? )

Десяти разных, наверное, могло бы хватить. Только вот их не будет.

Здравствуйте, Masterspline, Вы писали:

M>IMHO, это прямой путь с write-only коду и фрагментации языка. Каждый начнет делать свой макроязык, понятный только ему. Разбираться в таком коде (как он работает) станет сильно сложнее (хотя герою-писателю такого кода будет, конечно, насрать на тех, кто в этом коде будет разбираться). Кодогенерация в исходнике — это классная игрушка для того, кто пишет код и неоправданное усложнение для того, кто его читает и поддерживает. Такие вещи нужно делать внешними инструментами типа Qt MOC или LibTooling.

Ну у подхода использования различных встраиваемых DSL есть как много сторонников, так и противников, так что это нормально. Но на мой личный взгляд библиотеки типа Boost.Spirit, Boost.Xpressive, Boost.MSM, Boost.Units, slqpp11 и т.п. реализующие свои DSL'и, весьма удобны.

Здравствуйте, so5team, Вы писали:

_>>Т.е. область применения сложно самому осмыслить и нужны конкретные исходники?
S>Блин, да я уже не знаю, как сказать это еще более понятно: нужность в C++ средств работы со строками в compile-time под сомнение не ставится. Ну вот вообще.
S>Нужны ли в C++ строки как параметры шаблона, чтобы кто-то мог написать:
S>

super::duper::sql::statement<"select * from my_table where id={}"> stm{connection};

это тема отдельного разговора и по этому поводу могут быть разные мнения. В том числе тех, кому извращения из Boost-а нравятся и тех, кому не нравятся. Это тема _отдельного_ разговора.

Правильно ли я понимаю, что ты можешь предложить способ написать аналог библиотеки Boost.Metaparse без использования шаблонов? )

_>>Так ты тогда озвучь сколько конкретно тебе надо примеров, чтобы это начало считаться для тебя аргументом.
S>Примеры нужны не для того, чтобы быть или не быть аргументами. А для того, чтобы можно было ознакомиться с чужим опытом и составить себе впечатление.

Т.е. ты не способен представить себе эффект от внесения подобной возможности в C++ и поэтому тебе требуются подсказки из других языков? )

_>>Один, десять, сто? )
S>Десяти разных, наверное, могло бы хватить. Только вот их не будет.

Я не вращаюсь в инфраструктуре D, так что вряд ли вспомню (а специально для форумной беседы искать сети не буду) что-то кроме vibe.d, с которым игрался когда-то. А вот зато в инфраструктуре языка C++ я как раз постоянно обитаю и тут совсем другая ситуация — думаю что в одном только Boost'e найдётся десяток библиотек, написание которых очень существенно упростится с введением возможности передачи строк в шаблоны. Очень странно, что ты (вроде как тоже из мира C++) не видишь этого очевидного факта.

Здравствуйте, alex_public, Вы писали:

_>Правильно ли я понимаю, что ты можешь предложить способ написать аналог библиотеки Boost.Metaparse без использования шаблонов? )

Не правильно. Речь не идет о том, как писать библиотеки вроде Boost.Metaparse. Пока интересно, кому еще в других языках потребовалось что-нибудь подобное, для каких целей это использовалось, насколько удачно и широко.

Конкретно же любителям извращений на плюсовых шаблонах остается напомнить пример с Boost.Lambda, которая выглядела редкостным говном и благополучно сдохла после появления нормальных лямбд в языке. Безотносительно того, что Boost.Lambda кем-то использовалась, она все равно была говном, затыкавшим временную дыру в возможностях тогдашнего C++.

_>Т.е. ты не способен представить себе эффект от внесения подобной возможности в C++ и поэтому тебе требуются подсказки из других языков? )

Подсказки из других языков дают расширение кругозора и лучшее понимание того, как делать какую-то функциональность в нормальном виде. Можно было радоваться возможностям Boost.Lambda, но при наличии опыта работы с _нормальными_ лямбдами в других языках впечатление от Boost.Lambda было уже совсем другим. Можно радоваться появлению std::variant и восторгаться экспериментам c Mach7, но это гораздо сложнее делать после знакомства с АлгТД из других ЯП. Тоже самое касается и строк в качестве параметров шаблонов. Может быть Boost.Metaparse и есть отличный пример того, что можно навелосипедить на шаблонах C++. А может быть это из-за того, что авторы упоролись и пытаются эмулировать в C++ то, что в других языках делается просто и естественно. И что в C++, возможно, нужно было бы делать иначе, а не так, как они это решили сделать.

_>>>Один, десять, сто? )
S>>Десяти разных, наверное, могло бы хватить. Только вот их не будет.

_>Я не вращаюсь в инфраструктуре D, так что вряд ли вспомню (а специально для форумной беседы искать сети не буду) что-то кроме vibe.d, с которым игрался когда-то.

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

_>А вот зато в инфраструктуре языка C++ я как раз постоянно обитаю и тут совсем другая ситуация — думаю что в одном только Boost'e найдётся десяток библиотек, написание которых очень существенно упростится с введением возможности передачи строк в шаблоны.

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

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

_>Очень странно, что ты (вроде как тоже из мира C++) не видишь этого очевидного факта.

Речь вообще не о том, что я вижу сейчас. Речь о том, чтобы узнать то, чего не вижу. И душеспасительные тексты о том, "как же ты не понимаешь" этому вообще не способствуют.

Здравствуйте, so5team, Вы писали:

_>>Правильно ли я понимаю, что ты можешь предложить способ написать аналог библиотеки Boost.Metaparse без использования шаблонов? )
S>Не правильно. Речь не идет о том, как писать библиотеки вроде Boost.Metaparse. Пока интересно, кому еще в других языках потребовалось что-нибудь подобное, для каких целей это использовалось, насколько удачно и широко.

Ну так это только тебе интересно, а остальное сообщество уже давно прояснило данный вопрос и как видишь во всю пилит решения, пускай и вынужденно костыльные.

S>Конкретно же любителям извращений на плюсовых шаблонах остается напомнить пример с Boost.Lambda, которая выглядела редкостным говном и благополучно сдохла после появления нормальных лямбд в языке. Безотносительно того, что Boost.Lambda кем-то использовалась, она все равно была говном, затыкавшим временную дыру в возможностях тогдашнего C++.

Безусловно. И если в C++ введут более продвинутые средства метапрограммирования (например типа макросов Nim'а, Rust'а или вообще Nemerle), то я буду только рад и забуду вообще о любых извращениях с шаблонами. Однако давай будем реалистами — это практически невероятный сценарий. Самое смелое предложение в этой области из реально обсуждаемых, это метаклассы, которые презентовал Саттер, и то я что-то сомневаюсь в реальности принятия подобного (хотя лично мне очень хотелось бы). Так что в данный момент и в обозримом будущем метапрограммирование в C++ реализовано на шаблонах и соответственно работа со строками в них крайне актуальна.

_>>Т.е. ты не способен представить себе эффект от внесения подобной возможности в C++ и поэтому тебе требуются подсказки из других языков? )
S>Подсказки из других языков дают расширение кругозора и лучшее понимание того, как делать какую-то функциональность в нормальном виде. Можно было радоваться возможностям Boost.Lambda, но при наличии опыта работы с _нормальными_ лямбдами в других языках впечатление от Boost.Lambda было уже совсем другим. Можно радоваться появлению std::variant и восторгаться экспериментам c Mach7, но это гораздо сложнее делать после знакомства с АлгТД из других ЯП. Тоже самое касается и строк в качестве параметров шаблонов. Может быть Boost.Metaparse и есть отличный пример того, что можно навелосипедить на шаблонах C++. А может быть это из-за того, что авторы упоролись и пытаются эмулировать в C++ то, что в других языках делается просто и естественно. И что в C++, возможно, нужно было бы делать иначе, а не так, как они это решили сделать.

Языков поддерживающих полноценное метапрограммирование в принципе не много. А из мейнстримовых языков такой вообще ровно один. Поэтому C++ крайне сложно что-то подсматривать в этой области у коллег. Да, есть близкие языки с более развитым МП (тот же D, Rust, Nim), но в силу их гораздо меньшей популярности они не могут охватить весь спектр решаемых C++ проблем и соответственно продемонстрировать какие-то инновационные решения. Например на том же D можно элементарно переписать большую часть библиотек Boost'a, сократив их код в разы. Но этого никто не делает. Не потому что не надо, т.к. есть лучшие решения, а потому что просто некому этим заниматься.

_>>А вот зато в инфраструктуре языка C++ я как раз постоянно обитаю и тут совсем другая ситуация — думаю что в одном только Boost'e найдётся десяток библиотек, написание которых очень существенно упростится с введением возможности передачи строк в шаблоны.
S>В мире C++ найдется достаточно людей, которые держатся от Boost-а подальше. Во многом из-за того, что там есть вот эти самые библиотеки. Поскольку в каких-то нишах от этих библиотек нет вообще никакого толку.

От каких-то библиотек безусловно нет пользы. И что? Кто-то требует использовать весь Boost сразу? )))

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

Кстати, если было нужно только имя типа для лога, то с этим по идее банальный RTTI справился бы. )

_>>Очень странно, что ты (вроде как тоже из мира C++) не видишь этого очевидного факта.
S>Речь вообще не о том, что я вижу сейчас. Речь о том, чтобы узнать то, чего не вижу. И душеспасительные тексты о том, "как же ты не понимаешь" этому вообще не способствуют.

Ну т.е. ты пришёл в данную темку форума не чтобы высказывать своё мнение, а чтобы набраться знаний, правильно? Если так, то тогда извини — я просто не правильно понял твою позицию. )

Здравствуйте, alex_public, Вы писали:

_>Ну так это только тебе интересно, а остальное сообщество уже давно прояснило данный вопрос и как видишь во всю пилит решения, пускай и вынужденно костыльные.

Не нужно говорить за все сообщество. Есть множество людей, которые стараются держаться максимально далеко от Boost.Spirit, Boost.Xpressive, Boost.Metaparse и подобных библиотек. При этом они пишут вполне работающий и полезный для пользователей софт. Мир C++ очень широк и очень сегментирован. Не нужно полагать, что костыли, которые нравятся авторам Boost.Metaparse -- это однозначно поддержаный всеми мейнстрим в C++.

_>Однако давай будем реалистами — это практически невероятный сценарий. Самое смелое предложение в этой области из реально обсуждаемых, это метаклассы, которые презентовал Саттер, и то я что-то сомневаюсь в реальности принятия подобного (хотя лично мне очень хотелось бы). Так что в данный момент и в обозримом будущем метапрограммирование в C++ реализовано на шаблонах и соответственно работа со строками в них крайне актуальна.

Boost.Lambda тоже рассматривалась "в данный момент и в обозримом будущем". Только на практике было и просто, и дешево вообще обходиться без нее. Так что можно по-разному смотреть на реальность и воздействовать на нее. Можно соглашаться с авторами Boost.Metaparse и желать, чтобы в C++ были строковые параметры для шаблонов (хотя уже тут все идет в жопу на простом вопросе -- а что за строки, в каком представлении: const char*, string_view, constexpr_string,...? в какой кодировке: ASCII, UTF-8, UCS-2, UCS-4? В том же D с этим проблем нет, т.к. там есть родной тип string, встроенный).

А можно говорить: это не правильно, нужно по-другому (уже это может быть полезно, чтобы в стандарт не пролезло какое-нибудь мертворожденное говно). И, заодно, можно помогать тому же Саттеру. Или же предлагать свои варианты.

_>Кстати, если было нужно только имя типа для лога, то с этим по идее банальный RTTI справился бы. )

Нет.

_>Ну т.е. ты пришёл в данную темку форума не чтобы высказывать своё мнение, а чтобы набраться знаний, правильно?

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

Здравствуйте, so5team, Вы писали:

_>>Ну так это только тебе интересно, а остальное сообщество уже давно прояснило данный вопрос и как видишь во всю пилит решения, пускай и вынужденно костыльные.
S>Не нужно говорить за все сообщество. Есть множество людей, которые стараются держаться максимально далеко от Boost.Spirit, Boost.Xpressive, Boost.Metaparse и подобных библиотек. При этом они пишут вполне работающий и полезный для пользователей софт. Мир C++ очень широк и очень сегментирован. Не нужно полагать, что костыли, которые нравятся авторам Boost.Metaparse -- это однозначно поддержаный всеми мейнстрим в C++.

1. Конечно Boost.Metaparse требуется не всему сообществу. Более того, оно необходимо явному меньшинству. Только вот если говорить об оставшемся большинстве, то его адекватная часть никогда не заявит чего-то вроде "ну мне лично эта функциональность не нужна, поэтому и в языке она не нужна". В худшем случае они скажут, что подобное нововведение в язык им безразлично (ни лучше, ни хуже им от него не будет), а в лучшем случае порадуются за коллег, которым станет намного проще жить. И только неадекватная часть сообщества будет против подобного нововведение по причине отсутствия у них подобных задач. Я как-то надеялся что на этом форуме неадекватные не встретятся...

2. Я не думаю что авторам Boost.Metaparse нравятся те жуткие костыли с передачей строк в шаблоны. Но другого способа в C++ сейчас просто нет.

3. Включение библиотеки в Boost является вполне себе определённым признанием в мире C++.

_>>Однако давай будем реалистами — это практически невероятный сценарий. Самое смелое предложение в этой области из реально обсуждаемых, это метаклассы, которые презентовал Саттер, и то я что-то сомневаюсь в реальности принятия подобного (хотя лично мне очень хотелось бы). Так что в данный момент и в обозримом будущем метапрограммирование в C++ реализовано на шаблонах и соответственно работа со строками в них крайне актуальна.
S>Boost.Lambda тоже рассматривалась "в данный момент и в обозримом будущем". Только на практике было и просто, и дешево вообще обходиться без нее. Так что можно по-разному смотреть на реальность и воздействовать на нее.

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

S>Можно соглашаться с авторами Boost.Metaparse и желать, чтобы в C++ были строковые параметры для шаблонов (хотя уже тут все идет в жопу на простом вопросе -- а что за строки, в каком представлении: const char*, string_view, constexpr_string,...? в какой кодировке: ASCII, UTF-8, UCS-2, UCS-4? В том же D с этим проблем нет, т.к. там есть родной тип string, встроенный).

Ну я вроде уже кидал ссылку на какое-то из предложений в Комитете по этой теме. Хотя сам в детали не вникал — вот примут, тогда изучу. )))

_>>Кстати, если было нужно только имя типа для лога, то с этим по идее банальный RTTI справился бы. )
S>Нет.

Почему? ) В данном случае же он статический, так что даже теоретических провалов в производительности быть не может. Какие ещё возражения то? )

_>>Ну т.е. ты пришёл в данную темку форума не чтобы высказывать своё мнение, а чтобы набраться знаний, правильно?
S>Да. Подумалось, что если человеку нужны строки в качестве шаблонных параметров, то он может привести примеры. И это может помочь чему-нибудь научиться. Например, узнать про проблемы, с которыми раньше не сталкивался.

Ну лично мне просто очень нравится ряд возможностей языка D и я считаю, что можно абсолютно безболезненно перенести процентов 80 их в C++, чтобы он стал действительно отличным инструментом. В первую очередь статическую интроспекцию, потом элементы метапрограммирования (вычисления на этапе компиляции, функцию mixin, нормальные параметры шаблонов и т.п.), всякие мелкие удобства (типа особых перегруз операторов и т.п.) и т.д. Ну и кстати в не большой степени этот процесс идёт (из последнего это "constexpr if" — 100% копия "static if" из D), но как-то очень медленно...

Здравствуйте, so5team, Вы писали:

_>>1. Конечно Boost.Metaparse требуется не всему сообществу. Более того, оно необходимо явному меньшинству. Только вот если говорить об оставшемся большинстве, то его адекватная часть никогда не заявит чего-то вроде "ну мне лично эта функциональность не нужна, поэтому и в языке она не нужна". В худшем случае они скажут, что подобное нововведение в язык им безразлично (ни лучше, ни хуже им от него не будет), а в лучшем случае порадуются за коллег, которым станет намного проще жить. И только неадекватная часть сообщества будет против подобного нововведение по причине отсутствия у них подобных задач. Я как-то надеялся что на этом форуме неадекватные не встретятся...
S>Да, всех, кто не разделяет вашу точку зрения, нужно объявить неадекватной частью сообщества. Это очень адекватный подход.

Если они не разделяют по принципу "мне не надо, а значит и в языке не надо", то да, неадекваты.

_>>Ну ты можешь предложить любое другое решение (без шаблонов) из других языков для решения этой же задачи? )
S>CTFE и mixin-ы из D. Без шаблонов. На вход функции подается строка с DSL-ем внутри, на выходе строка с D-шным кодом, результирующая строка скармливается mixin-у. Очень простой подход, легко тестировать и отлаживать.

У большого объёма кода заданного строками есть очевидные минусы: он не поддерживается IDE и т.п. Т.е. когда DSL (априори не поддерживаемый IDE, не считая специфических случаев типа Nemerle/Nitra и т.п.) задаётся строками — это одно, а когда ты рядовой код C++/D код будешь задавать строками — это уже неудобно.

S>Никогда не работал с макросами Rust-а и Scala. Но, на макросах Rust-а делается весьма себе продвинутый print!, в compile-time.

Да, про макросы Rust'а я как раз писал, что с удовольствием увидел бы их в C++. Но ты же надеюсь понимаешь, что это нереально? Кстати, советую тебе ещё взглянуть на язык Nim — там тоже мощное решение.

S>Есть язык Gosu для JVM, в котором сделали систему плагинов для компилятора и некую штуку под названием Open Type System. Позволяет использовать вообще разные DSL-и (здесь небольшой пример с XSD описывается).

Прямо похоже на Nemerle и т.п. ))) Но это точно путь не для C++.

_>>>>Кстати, если было нужно только имя типа для лога, то с этим по идее банальный RTTI справился бы. )
S>>>Нет.
_>>Почему? ) В данном случае же он статический, так что даже теоретических провалов в производительности быть не может. Какие ещё возражения то? )
S>Главное возражение: вы не знаете условий задачи, но предлагаете способ и настаиваете на его применимости.

Так я собственно и спрашиваю, какие ещё проблемы с таким решением. )))

S>И ну мелкое возражение: нужен короткий идентификатор, не зависящий от компилятора, который можно зафиксировать в документации к фреймворку.

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