Типы экспрессии прото являются POD (Plain Old Data) и не имеют конструкторов. Они инициируются скобками следующим образом:

terminal<int>::type const _i = {1};

Причина в том, что объекты выражения, подобные<_i>выше, могут бытьстатически инициализированы. Почему важна статическая инициализация? Терминалы многих встраиваемых доменных языков, вероятно, будут глобальными объектами, такими как<_1>и<_2>из библиотеки Boost Lambda. Если бы эти объекты требовали инициализации во время выполнения, можно было бы использовать эти объекты до их инициализации. Это было бы плохо. Статически инициализированные объекты не могут быть использованы неправильно.

Любой, кто заглядывал в исходный код Proto, вероятно, задавался вопросом: "Почему весь грязный препроцессор порвался? Разве все это не могло быть реализовано поверх таких библиотек, как MPL и Fusion? Ответ заключается в том, что Proto мог быть реализован таким образом, и на самом деле был в какой-то момент. Проблема в том, что метапрограммирование шаблонов (TMP) обеспечивает более длительное время компиляции. В качестве основы, на которой будут построены другие библиотеки с TMP, Proto должен быть максимально легким. Это достигается путем предпочтения препроцессорного метапрограммирования шаблонному метапрограммированию. Расширение макроса гораздо эффективнее, чем создание шаблона. В некоторых случаях для компиляции «чистой» версии требуется в 10 раз больше времени, чем для «грязной».

«Чистая и медленная» версия Proto все еще можно найти по адресу http://svn.boost.org/svn/boost/branches/proto/v3. Любой, кто заинтересован, может загрузить его и убедиться, что он, на самом деле, необоснованно медленно компилируется. Обратите внимание, что разработка этой ветки была прекращена, и она не соответствует текущему интерфейсу Proto.

Много уже было написано о диспетчеризации на чертах типа с использованием методов SFINAE (Substitution Failure Is Not An Error) на C++. Есть библиотека Буст, Буст. Enable_if, чтобы сделать технику идиоматической. Прото-отправления по признакам типа широко, но он не очень часто используется<enable_if<>>. Скорее, это отправки, основанные на наличии или отсутствии вложенных типов, часто типизированных для пустоты.

Взять хотя бы<is_expr<>>. Можно было бы написать что-то вроде этого:

template<typename T>
struct is_expr
  : is_base_and_derived<proto::some_expr_base, T>
{};

Скорее, он реализуется следующим образом:

template<typename T, typename Void = void>
struct is_expr
  : mpl::false_
{};
template<typename T>
struct is_expr<T, typename T::proto_is_expr_>
  : mpl::true_
{};

Это зависит от того, что специализация будет предпочтительной, если<T>имеет вложенную<proto_is_expr_>, которая является типдефом для<void>. Все типы экспрессии Proto имеют такой вложенный типдеф.

Почему Proto делает это именно так? Причина в том, что, проведя обширные тесты, пытаясь улучшить время компиляции, я обнаружил, что этот подход компилируется быстрее. Требуется ровно один шаблон. Другой подход требует по крайней мере 2:<is_expr<>>и<is_base_and_derived<>>, плюс любые шаблоны<is_base_and_derived<>>.

В некоторых местах Прото должен знать, можно ли вызвать объект функции<Fun>с определенными параметрами и предпринять резервное действие, если нет. Это происходит в<proto::callable_context<>>и в<proto::call<>>преобразовании. Откуда Прото знает? Это включает в себя сложное метапрограммирование. Вот как.

Другой способ постановки вопроса заключается в попытке реализовать следующую булеву метафункцию<can_be_called<>>, которая проверяет, можно ли вызвать объект функции<Fun>с параметрами типа<A>и<B>:

template<typename Fun, typename A, typename B>
struct can_be_called;

Во-первых, мы определяем следующую структуру<dont_care>, которая имеет неявное преобразование из чего-либо. И не просто любое неявное преобразование; оно имеет преобразование эллипса, которое является наихудшим возможным преобразованием для целей разрешения перегрузки:

struct dont_care
{
    dont_care(...);
};

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

struct private_type
{
    private_type const &operator,(int) const;
};
typedef char yes_type;      // sizeof(yes_type) == 1
typedef char (&no_type)[2]; // sizeof(no_type)  == 2
template<typename T>
no_type is_private_type(T const &);
yes_type is_private_type(private_type const &);

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

template<typename Fun>
struct funwrap2 : Fun
{
    funwrap2();
    typedef private_type const &(*pointer_to_function)(dont_care, dont_care);
    operator pointer_to_function() const;
};

Со всеми этими битами и частями мы можем реализовать<can_be_called<>>следующим образом:

template<typename Fun, typename A, typename B>
struct can_be_called
{
    static funwrap2<Fun> &fun;
    static A &a;
    static B &b;
    static bool const value = (
        sizeof(no_type) == sizeof(is_private_type( (fun(a,b), 0) ))
    );
    typedef mpl::bool_<value> type;
};

Идея состоит в том, чтобы сделать так, чтобы<fun(a,b)>всегда компилировалась, добавляя нашу собственную перегрузку двоичной функции, но делая это таким образом, чтобы мы могли определить, была ли выбрана наша перегрузка или нет. И мы подтасовываем его так, чтобы наша перегрузка была выбрана, если действительно нет лучшего варианта. Вот как это работает<can_be_called<>>.

Мы обертываем<Fun>в тип, который имеет неявное преобразование в указатель на двоичную функцию. Объект<fun>типа класса можно вызвать как<fun(a,b)>, если он имеет такого оператора преобразования, но поскольку он включает в себя оператора преобразования, определенного пользователем, он менее предпочтителен, чем перегруженный<operator()>, который не требует такого преобразования.

Указатель функции может принимать любые два аргумента в силу типа<dont_care>. Последовательность преобразования для каждого аргумента гарантированно является наихудшей возможной последовательностью преобразования: неявное преобразование через эллипсис и определяемое пользователем преобразование в<dont_care>. В целом это означает, что<funwrap2<Fun>()(a,b)>всегда будет компилировать, но он выберет нашу перегрузку только в том случае, если действительно нет лучшего варианта.

Если есть лучший вариант - например, если<Fun>имеет перегруженную функцию оператора вызова, такую как<void operator()(Aa,Bb)>- тогда<fun(a,b)>решит вместо этого. Теперь вопрос заключается в том, как определить, какая функция была выбрана при разрешении перегрузки.

Обратите внимание, как<fun(a,b)>появляется в<can_be_called<>>:<(fun(a,b),0)>. Почему мы используем оператор запятой? Причина в том, что мы используем это выражение в качестве аргумента для функции. Если тип возврата<fun(a,b)>является<void>, он не может юридически использоваться в качестве аргумента для функции. Оператор запятой обходит проблему.

Это также должно объяснить цель оператора перегруженной запятой в<private_type>. Тип возврата указателя к функции<private_type>. Если разрешение перегрузки выбирает нашу перегрузку, то тип<(fun(a, b), 0)><private_type>. В противном случае<int>. Этот факт используется для отправки на любую перегрузку<is_private_type()>, которая кодирует его ответ в размере его типа возврата.

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