Здравствуйте, Григорьев Вячеслав Владимирович, Вы писали:
ГВВ>Статья:
ГВВ>Реализация новых парадигм программирования в C++: плюсы и минусыАвтор(ы): Григорьев Вячеслав Владимирович
Дата: 29.12.2011
В статье кратко рассматриваются плюсы и минусы реализации на C++ библиотек / сред, предлагающих разработчику новые парадигмы программирования или новое подмножество языка (Domain Specific Language). В качестве примера обсуждаются реализации функционального программирования в библиотеках boost::lambda и boost::phoenix.
Что-то как-то ни о чем.
Насчет отдельно стоящего функтора и прыжков по разным файлам — если функтор попал в отдельный файл, значит, он используется в нескольких местах и с лямбдой по месту будет в результате гораздо больше писанины и copy-paste, чем с вызовом функтора. В моей практике больше 70% воткнутых по месту лямбд в результате преобразовывались в функторы, так как требуемая функциональность требовалась в нескольких местах и поддерживать единообразие гораздо проще, когда у тебя один функтор, а не 20 раз повторенная в разных местах лямбда.
Плюс написано о C++0x, но при этом ниже по тексту старое доброе
Во-первых, это поддержка от одного до N параметров, N обычно задаётся каким-нибудь макроопределением при компиляции библиотеки. Для поддержки переменного числа параметров в каждом функторе делается не один, а N операторов вызова – для 1, 2, 3… N аргументов. Например, так:
template <typename T1> void operator()(T1 &t1)
{
_l(t1) << _r(t1);
}
template <typename T1, typename T2> void operator()(T1 &t1, T2 &t2)
{
_l(t1, t2) << _r(t1, t2);
}
template <typename T1, typename T2, typename T3> void operator()(T1 &t1, T2 &t2, T3 &t3)
{
_l(t1, t2, t3) << _r(t1, t2, t3);
}
//...
вместо простого и понятного C++0x:
template <typename T...> void operator()(T&... t...)
{
_l(t...) << _r(t...);
}
//...
Насчет сообщений об ошибках — во-первых, в С++0x есть static_assert (BOOST_STATIC_ASSERT), который печатает текстовое сообщение об ошибке, так что можно не возиться с массивами.
Во-вторых, автор, видимо, забыл или не знает о макросах типа BOOST_MPL_ASSERT_MSG, которые печатают вполне читабельные сообщения с кучей звездочек вокруг, так что они замечательно видны в выводе компилятора (а с использованием постпроцессора сообщений компилятора об ошибках вообще все становится замечательно, см. пример ниже), и плюс в них можно запихать типы — крайне полезная вещь в метапрограммировании на типах.
Хотя, естественно, с сообщениями компилятора они не сравнятся, но это гораздо больше, чем "массив или комментарий".
Плюс есть специальные техники (функции-перехватчики), позволяющие сильно уменьшить "простыню", генерируемую компилятором в процессе компиляции некорректного кода.
Далее, автор слегка лукавит, когда говорит, что есть два способа — имена и комментарии, так как комментарий сам по себе никому не виден. Эти способы используются вместе, чтоб по сообщению об ошибке типа
************NON_INTEGRAL_TYPES_ARE_NOT_ALLOWED(void*)************
можно было прямо в студии сразу же прыгнуть на то место, где она сгенерирована, и прочитать комментарий (в котором могут быть, например, инструкции, как исправить пользовательский код, если это распространенная ошибка).
Замечание
Примечание: кстати, выражение (g_a << _1)(“test”) успешно компилируется и выполняется с использованием тестового кода микро-библиотеки, описанной выше.
вообще выглядит издевательством — еще бы оно не работало, если там везде параметры передаются по неконстантной ссылке.
Ну и говорить о eDSL в С++, не упоминая Boost.Proto, как-то странно.
В целом статья своей поверхностностью оставляет тягостное впечатление и выглядит, как курсовая, написанная, чтоб отвязались.
Для поста на хабре это еще ничего, но на статью в ваковском журнале никак не тянет.
PS В любой статье, где обсуждается какая-либо библиотека или продукт, всегда нужно указывать точную версию, а не просто "буст".
Если даются примеры использования библиотеки, то надо указывать, какие хедеры предполагаются подключенными по умолчанию, чтобы читатели могли все проверить сами и поиграть с примерами.
