Getting Proto

Вы можете получить Proto, загрузив Boost (Proto в версии 1.37 и более поздней), или зайдя в репозиторий SVN Boost на SourceForge.net.http://svn.boost.org/trac/boost/wiki/BoostSubversionи следовать инструкциям для анонимного доступа к SVN.

Building with Proto

Proto - это библиотека шаблонов только для заголовков, что означает, что вам не нужно изменять скрипты сборки или ссылаться на какой-либо отдельный файл lib, чтобы использовать его. Все, что вам нужно сделать, это<#include <boost/proto/proto.hpp>>. Или вы можете просто включить ядро Proto<#include <boost/proto/core.hpp>>и какие контексты и преобразования вы используете.

Requirements

Прото зависит от Boost. Вы должны использовать либо версию Boost 1.34.1 или выше, либо версию в багажнике SVN.

Supported Compilers

В настоящее время, Boost. Известно, что Proto работает над следующими компиляторами:

	Note
	Пожалуйста, отправьте любые вопросы, комментарии и отчеты об ошибках в ericboostprocom.

Proto - это большая библиотека, которая, вероятно, не похожа ни на одну библиотеку, которую вы использовали раньше. Proto использует некоторые согласованные соглашения об именах, чтобы упростить навигацию, и они описаны ниже.

Functions

Все функции Прото определены в пространстве имен<boost::proto>. Например, существует функция под названием<value()>, определенная в<boost::proto>, которая принимает терминальное выражение и возвращает значение терминала.

Metafunctions

Прото определяетметафункции, которые соответствуют каждой из свободных функций Прото. Метафункции используются для вычисления типов возврата функций. Все метафункции Прото живут в пространстве имен<boost::proto::result_of>и имеют то же название, что и функции, которым они соответствуют. Например, существует шаблон класса<boost::proto::result_of::value<>>, который можно использовать для вычисления типа возврата функции<boost::proto::value()>.

Function Objects

Прото определяетобъект функцииэквиваленты всех его свободных функций. (Объект функции — это экземпляр типа класса, который определяет функцию члена<operator()>.) Все типы объектов функции Прото определены в пространстве имен<boost::proto::functional>и имеют то же название, что и их соответствующие свободные функции. Например,<boost::proto::functional::value>— класс, который определяет объект функции, который делает то же самое, что<boost::proto::value()>свободная функция.

Primitive Transforms

Прото также определяетпримитивные преобразования— типы классов, которые могут использоваться для составления более крупных преобразований для манипулирования деревьями экспрессии. Многие свободные функции Прото имеют соответствующие примитивные преобразования. Они живут в пространстве имен<boost::proto>, и их имена имеют важное значение. Например, преобразование, соответствующее функции<value()>, называется<boost::proto::_value>.

В нижеследующей таблице резюмируется вышеупомянутое обсуждение:

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

#include <iostream>
#include <boost/proto/proto.hpp>
#include <boost/typeof/std/ostream.hpp>
using namespace boost;
proto::terminal< std::ostream & >::type cout_ = { std::cout };
template< typename Expr >
void evaluate( Expr const & expr )
{
    proto::default_context ctx;
    proto::eval(expr, ctx);
}
int main()
{
    evaluate( cout_ << "hello" << ',' << " world" );
    return 0;
}

Эта программа предусматривает следующее:

hello, world

Эта программа создает объект, представляющий операцию вывода, и передает его функции<evaluate()>, которая затем выполняет его.

Основная идея шаблонов выражения состоит в том, чтобы перегрузить всех операторов, чтобы вместо немедленной оценки выражения они построили древовидное представление выражения, чтобы его можно было оценить позже. Для каждого оператора в выражении, по крайней мере, один операнд должен быть Protofied для того, чтобы оператор Proto был найден. В выражении...

cout_ << "hello" << ',' << " world"

Протофидное подвыражение<cout_>, которое является протоификацией<std::cout>. Наличие<cout_>«заражает» выражение и учитывает перегрузки оператора строительства деревьев Прото. Любые буквы в выражении затем Protofied, обернув их в терминал Proto, прежде чем они будут объединены в более крупные выражения Proto.

После того, как операторские перегрузки Proto построили дерево экспрессии, выражение может быть лениво оценено позже. Это то, что<proto::eval()>. Это общий оценщик выражений ходьбы по дереву, поведение которого настраивается черезконтекстпараметр. Использование<proto::default_context>присваивает операторам стандартные значения в выражении. (Используя другой контекст, вы можете дать операторам в своих выражениях различную семантику. По умолчанию Proto не делает никаких предположений о том, что на самом деле означают операторы.

Proto Design Philosophy

Прежде чем продолжить, давайте используем приведенный выше пример, чтобы проиллюстрировать важный принцип проектирования Proto. Шаблон выражения, созданный в примереHello World, является полностью общим и абстрактным. Он никоим образом не привязан к какой-либо конкретной области или приложению и не имеет какого-либо конкретного значения или поведения самостоятельно, пока не будет оценен вконтексте. Шаблоны выражения на самом деле просто неоднородные деревья, что может означать что-то в одной области, а что-то совершенно другое в другой.

Как мы увидим позже, существует способ создания деревьев выражения Прото, которые являются, а нечисто абстрактными, и которые имеют смысл и поведение, независимое от любого контекста. Существует также способ контролировать, какие операторы перегружены для вашего конкретного домена. Но это не поведение по умолчанию. Позже мы увидим, почему дефолт часто бывает хорошим.

"Здравствуй, мир" - это хорошо, но это не очень далеко. Давайте использовать Proto для создания EDSL (встроенного доменного языка) для калькулятора с ленивой оценкой. Мы посмотрим, как определить терминалы в мини-языке, как составить их в более крупные выражения и как определить контекст оценки, чтобы ваши выражения могли выполнять полезную работу. Когда мы закончим, у нас будет мини-язык, который позволит нам объявить лениво оцененное арифметическое выражение, такое как<(_2 -_1)/_2 *100>, где<_1>и<_2>являются держателями для значений, которые будут переданы при оценке выражения.

Defining Terminals

Первый из них – это<_1>и<_2>. Для этого мы используем метафункцию<proto::terminal<>>.

// Define a placeholder type
template<int I>
struct placeholder
{};
// Define the Protofied placeholder terminals
proto::terminal<placeholder<0> >::type const _1 = {{}};
proto::terminal<placeholder<1> >::type const _2 = {{}};

Поначалу инициализация может показаться немного странной, но есть веская причина для этого. Объекты<_1>и<_2>выше не требуют построения времени выполнения — онистатически инициализированы, что означает, что они по существу инициализированы во время компиляции. См. разделСтатическая инициализацияв приложенииОбоснованиедля получения дополнительной информации.

Constructing Expression Trees

Теперь, когда у нас есть терминалы, мы можем использовать перегрузки оператора Proto, чтобы объединить эти терминалы в более крупные выражения. Например, мы можем сразу сказать такие вещи, как:

// This builds an expression template
(_2 - _1) / _2 * 100;

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

До сих пор объект — это просто дерево, представляющее выражение. У него нет поведения. В частности, это еще не калькулятор. Ниже мы рассмотрим, как сделать его калькулятором, определив контекст оценки.

Evaluating Expression Trees

Не сомневайтесь, вы хотите, чтобы ваши шаблоны выражения на самом деледелаличто-то. Один из подходов заключается в определенииконтекста оценки. Контекст подобен объекту функции, который связывает поведение с типами узлов в дереве экспрессии. Следующий пример должен прояснить это. Это объясняется ниже.

struct calculator_context
  : proto::callable_context< calculator_context const >
{
    // Values to replace the placeholders
    std::vector<double> args;
    // Define the result type of the calculator.
    // (This makes the calculator_context "callable".)
    typedef double result_type;
    // Handle the placeholders:
    template<int I>
    double operator()(proto::tag::terminal, placeholder<I>) const
    {
        return this->args[I];
    }
};

В<calculator_context>мы укажем, как Proto должен оценивать терминалы заполнителя, определяя соответствующие перегрузки оператора вызова функции. Для любых других узлов в дереве экспрессии (например, арифметических операций или неплацентарных терминалов) Proto будет оценивать экспрессию «по умолчанию». Например, двоичный узел плюс оценивается путем первой оценки левого и правого операндов и добавления результатов. Оценка по умолчанию Proto использует библиотекуBoost.Typeofдля вычисления типов возврата.

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

calculator_context ctx;
ctx.args.push_back(45); // the value of _1 is 45
ctx.args.push_back(50); // the value of _2 is 50
// Create an arithmetic expression and immediately evaluate it
double d = proto::eval( (_2 - _1) / _2 * 100, ctx );
// This prints "10"
std::cout << d << std::endl;

Позже мы увидим, как определить более интересные контексты оценки и преобразования выражения, которые дают вам полный контроль над тем, как оцениваются ваши выражения.

Customizing Expression Trees

Наш калькулятор EDSL уже довольно полезен, и для многих сценариев EDSL больше не потребуется. Но давайте продолжим. Представьте, насколько было бы лучше, если бы все выражения калькулятора перегрузились<operator()>, чтобы их можно было использовать в качестве функциональных объектов. Мы можем сделать это, создав калькулятордомени сообщив Proto, что все выражения в домене калькулятора имеют дополнительные члены. Вот как определить домен калькулятора:

// Forward-declare an expression wrapper
template<typename Expr>
struct calculator;
// Define a calculator domain. Expression within
// the calculator domain will be wrapped in the
// calculator<> expression wrapper.
struct calculator_domain
  : proto::domain< proto::generator<calculator> >
{};

Тип<calculator<>>будет экспрессионной оберткой. Он будет вести себя так же, как выражение, которое он обертывает, но у него будут дополнительные функции, которые мы определим.<calculator_domain>- это то, что сообщает Прото о нашей обертке. Приведены ниже в определении<calculator<>>. Читайте дальше для описания.

// Define a calculator expression wrapper. It behaves just like
// the expression it wraps, but with an extra operator() member
// function that evaluates the expression.    
template<typename Expr>
struct calculator
  : proto::extends<Expr, calculator<Expr>, calculator_domain>
{
    typedef
        proto::extends<Expr, calculator<Expr>, calculator_domain>
    base_type;
    calculator(Expr const &expr = Expr())
      : base_type(expr)
    {}
    typedef double result_type;
    // Overload operator() to invoke proto::eval() with
    // our calculator_context.
    double operator()(double a1 = 0, double a2 = 0) const
    {
        calculator_context ctx;
        ctx.args.push_back(a1);
        ctx.args.push_back(a2);
        return proto::eval(*this, ctx);
    }
};

Структура<calculator<>>является выражениемрасширения. Он использует<proto::extends<>>для эффективного добавления дополнительных членов к типу выражения. При составлении более крупных выражений из более мелких Proto отмечает, в какой области находятся меньшие выражения. Большее выражение находится в том же домене и автоматически обернуто в обертку расширения домена.

Все, что еще предстоит сделать, это поместить наших держателей в область калькулятора. Мы делаем это, завернув их в нашу обертку<calculator<>>, как показано ниже:

// Define the Protofied placeholder terminals, in the
// calculator domain.
calculator<proto::terminal<placeholder<0> >::type> const _1;
calculator<proto::terminal<placeholder<1> >::type> const _2;

Любое более крупное выражение, содержащее эти заполнители, будет автоматически обернуто в обертку<calculator<>>и иметь нашу<operator()>перегрузку. Это означает, что мы можем использовать их в качестве функциональных объектов следующим образом.

double result = ((_2 - _1) / _2 * 100)(45.0, 50.0);
assert(result == (50.0 - 45.0) / 50.0 * 100));

Поскольку выражения калькулятора теперь являются действительными функциональными объектами, мы можем использовать их со стандартными алгоритмами, как показано ниже:

double a1[4] = { 56, 84, 37, 69 };
double a2[4] = { 65, 120, 60, 70 };
double a3[4] = { 0 };
// Use std::transform() and a calculator expression
// to calculate percentages given two input sequences:
std::transform(a1, a1+4, a2, a3, (_2 - _1) / _2 * 100);

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

Detecting Invalid Expressions

Возможно, вы заметили, что вам не нужно определять перегруженный<operator-()>или<operator/()>. Фактически, Proto перегружаетвсехоператоров для вас, даже если они могут ничего не значить на вашем доменном языке. Это означает, что может быть возможно создать выражения, которые являются недействительными в вашем домене. Вы можете обнаружить недействительные выражения с помощью Proto, определивграмматикувашего доменного языка.

Для простоты предположим, что наш калькулятор EDSL должен разрешать только сложение, вычитание, умножение и деление. Любое выражение, связанное с любым другим оператором, является недействительным. Используя Proto, мы можем определить это требование, определив грамматику калькулятора EDSL. Это выглядит следующим образом:

// Define the grammar of calculator expressions
struct calculator_grammar
  : proto::or_<
        proto::plus< calculator_grammar, calculator_grammar >
      , proto::minus< calculator_grammar, calculator_grammar >
      , proto::multiplies< calculator_grammar, calculator_grammar >
      , proto::divides< calculator_grammar, calculator_grammar >
      , proto::terminal< proto::_ >
    >
{};

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

	Note
	Эта грамматика на самом деле немного свободнее, чем нам бы хотелось. Только заполнители и буквалы, которые конвертируются в дублеры, являются действительными терминалами. Позже мы увидим, как выразить подобные вещи в протограмматике.

После того, как вы определили грамматику EDSL, вы можете использовать метафункцию<proto::matches<>>, чтобы проверить, соответствует ли данный тип выражения грамматике. Например, мы можем добавить следующее к нашей перегрузке<calculator::operator()>:

template<typename Expr>
struct calculator
  : proto::extends< /* ... as before ... */ >
{
    /* ... */
    double operator()(double a1 = 0, double a2 = 0) const
    {
        // Check here that the expression we are about to
        // evaluate actually conforms to the calculator grammar.
        BOOST_MPL_ASSERT((proto::matches<Expr, calculator_grammar>));
        /* ... */
    }
};

Добавление строки<BOOST_MPL_ASSERT()>приводит к тому, что мы оцениваем только те выражения, которые соответствуют грамматике калькулятора EDSL. С грамматикой Proto<proto::matches<>>и<BOOST_MPL_ASSERT()>очень легко дать пользователям ваши короткие и читаемые ошибки времени компиляции EDSL, когда они случайно неправильно используют ваш EDSL.

	Note
	<BOOST_MPL_ASSERT()>является частью Библиотеки повышения метапрограммирования. Для этого достаточно<#include<boost/mpl/assert.hpp>>.

Controlling Operator Overloads

Грамматики и<proto::matches<>>позволяют обнаружить, когда пользователь создал недействительное выражение, и выпустить ошибку времени компиляции. Но что, если вы хотите помешать пользователям создавать недействительные выражения? Используя грамматику и домены вместе, вы можете отключить любую из перегрузок оператора Proto, которые создадут недействительное выражение. Это так же просто, как указать грамматику EDSL при определении домена, как показано ниже:

// Define a calculator domain. Expression within
// the calculator domain will be wrapped in the
// calculator<> expression wrapper.
// NEW: Any operator overloads that would create an
//      expression that does not conform to the
//      calculator grammar is automatically disabled.
struct calculator_domain
  : proto::domain< proto::generator<calculator>, calculator_grammar >
{};

Единственное, что мы изменили, это добавили<calculator_grammar>в качестве второго параметра шаблона к<proto::domain<>>шаблону при определении<calculator_domain>. С помощью этого простого дополнения мы отключаем любые перегрузки оператора Proto, которые создадут недействительное выражение калькулятора.

... And Much More

Надеюсь, это даст вам представление о том, что Proto может сделать для вас. Но это только царапает поверхность. Остальная часть этого руководства пользователя будет более подробно описывать все эти функции и другие.

Счастливого метапрограммирования!

Как мы видели в примере с калькулятором из Введения, самый простой способ получить EDSL и запустить его - это просто определить некоторые терминалы следующим образом.

// Define a literal integer Proto expression.
proto::terminal<int>::type i = {0};
// This creates an expression template.
i + 1;

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

Определение терминалов — с агрегированной инициализацией — иногда может быть немного неудобным. Proto обеспечивает более простую в использовании обертку для букв, которая может быть использована для построения терминальных выражений Protofied. Он называется<proto::literal<>>.

// Define a literal integer Proto expression.
proto::literal<int> i = 0;
// Proto literals are really just Proto terminal expressions.
// For example, this builds a Proto expression template:
i + 1;

Также существует функция<proto::lit()>для построения<proto::literal<>>на месте. Вышеуказанное выражение можно просто записать как:

// proto::lit(0) creates an integer terminal expression
proto::lit(0) + 1;

Как только у нас есть некоторые терминалы Proto, выражения, включающие эти терминалы, строят деревья экспрессии для нас. Proto определяет перегрузки для каждого из перегружаемых операторов C++ в пространстве имен<boost::proto>. Пока один операнд является выражением Прото, результатом операции является узел дерева, представляющий эту операцию.

	Note
	Операторские перегрузки Proto живут в пространстве имен<boost::proto>и обнаруживаются через ADL. Вот почему выражения должны быть «запятнаны» Прото-несностью, чтобы Прото мог строить деревья из выражений.

В результате перегрузок оператора Proto можно сказать:

-_1;        // OK, build a unary-negate tree node
_1 + 42;    // OK, build a binary-plus tree node

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

Assignment, Subscript, and Function Call Operators

Прото также перегружает<operator=>,<operator[]>и<operator()>, но эти операторы являются функциями-членами шаблона выражения, а не свободными функциями в пространстве имён Прото. Ниже приведены действительные выражения Proto:

_1 = 5;     // OK, builds a binary assign tree node
_1[6];      // OK, builds a binary subscript tree node
_1();       // OK, builds a unary function tree node
_1(7);      // OK, builds a binary function tree node
_1(8,9);    // OK, builds a ternary function tree node
// ... etc.

Для первых двух строк, назначения и субскрипта, неудивительно, что результирующий узел выражения должен быть двоичным. В конце концов, в каждом выражении есть два операнда. Поначалу может показаться удивительным, что то, что кажется функцией вызова без аргументов<_1()>, фактически создает узел выражения с одним ребенком. Ребенок сам по себе<_1>. Также у выражения<_1(7)>двое детей:<_1>и<7>.

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

int i;
i = _1;         // ERROR: cannot assign _1 to an int
int *p;
p[_1];          // ERROR: cannot use _1 as an index
std::sin(_1);   // ERROR: cannot call std::sin() with _1

Кроме того, C++ имеет специальные правила для перегрузок<operator->>, которые делают его бесполезным для построения шаблонов выражения, поэтому Proto не перегружает его.

The Address-Of Operator

Proto перегружает адрес оператора для типов экспрессии, так что следующий код создает новый унарный адрес узла дерева:

&_1;    // OK, creates a unary address-of tree node

Онневозвращает адрес<_1>объекта. Однако в Proto есть специальный код, так что унарный адрес узла неявно конвертируется в указатель на его ребенка. Другими словами, следующий код работает и делает то, что вы можете ожидать, но не очевидным образом:

typedef
    proto::terminal< placeholder<0> >::type
_1_type;
_1_type const _1 = {{}};
_1_type const * p = &_1; // OK, &_1 implicitly converted

Если бы мы ограничивались только терминалами и перегрузками операторов, наши встроенные языки доменов не были бы очень выразительными. Представьте, что мы хотели расширить наш калькулятор EDSL с полным набором математических функций, таких как<sin()>и<pow()>, которые мы могли бы лениво вызвать следующим образом.

// A calculator expression that takes one argument
// and takes the sine of it.
sin(_1);

Мы хотели бы, чтобы вышеприведенное создало шаблон выражения, представляющий вызов функции. Когда это выражение оценивается, оно должно вызывать функцию. (По крайней мере, в этом смысл вызова функции, который мы хотели бы иметь в калькуляторе EDSL.) Вы можете определить<sin>следующим образом:

// "sin" is a Proto terminal containing a function pointer
proto::terminal< double(*)(double) >::type const sin = {&std::sin};

В приведенном выше описании мы определяем<sin>как терминал Proto, содержащий указатель на функцию<std::sin()>. Теперь мы можем использовать<sin>в качестве ленивой функции.<default_context>, который мы видели во Введении, знает, как оценивать ленивые функции. Рассмотрим следующее:

double pi = 3.1415926535;
proto::default_context ctx;
// Create a lazy "sin" invocation and immediately evaluate it
std::cout << proto::eval( sin(pi/2), ctx ) << std::endl;

Вышеприведенный код распечатывает:

1

Я не специалист по тригонометрии, но мне это кажется правильным.

Мы можем написать<sin(pi/2)>, потому что<sin>объект, который является терминалом Proto, имеет перегруженный<operator()()>, который строит узел, представляющий функцию вызова вызова. Тип<sin(pi/2)>на самом деле таков:

// The type of the expression sin(pi/2):
proto::function<
    proto::terminal< double(*)(double) >::type const &
    proto::result_of::as_child< double const >::type
>::type

Этот тип дополнительно расширяется до неприглядного типа узла с тегомтипа<proto::tag::function>и двумя детьми: первый представляет функцию, на которую следует ссылаться, а второй представляет аргумент функции. (Таги узлов описывают операцию, которая создала узел.) Разница между<a +b>и<a- b>заключается в том, что первый имеет тип тега<proto::tag::plus>, а второй имеет тип тега<proto::tag::minus>. Типы тегов - это чистая информация о времени компиляции.

	Note
	При вычислении типов<proto::result_of::as_child<>>является метафункцией, которая гарантирует, что ее аргумент является типом экспрессии Прото. Если это не так, он становится терминалом Proto. Мы узнаем больше об этой метафункции, вместе с<proto::as_child()>, ее аналогом во время выполнения,позже. На данный момент вы можете забыть об этом.

Важно отметить, что в терминалах, содержащих указатели функций, нет ничего особенного.ЛюбойВыражение прото имеет перегруженную функцию оператора вызова. Подумайте:

// This compiles!
proto::lit(1)(2)(3,4)(5,6,7,8);

Сначала это может показаться странным. Он создает целочисленный терминал с<proto::lit()>, а затем снова и снова вызывает его как функцию. Что это значит? Кто знает?! Вы можете решить, когда вы определяете контекст оценки или преобразование. Но об этом позже.

Making Lazy Functions, Continued

Что, если мы хотим добавить функцию<pow()>в наш калькулятор EDSL, которую пользователи могли бы вызвать следующим образом?

// A calculator expression that takes one argument
// and raises it to the 2nd power
pow< 2 >(_1);

Описанная выше простая техника создания<pow>терминала, содержащего указатель функции, здесь не работает. Если<pow>является объектом, то выражение<pow< 2>(_1)>не является действительным C++. (Ну, технически это так; это означает<pow>меньше, чем 2, больше, чем<(_1)>, что совсем не похоже на то, что мы хотим.)<pow>должен быть реальным шаблоном функций. Но это должна быть необычная функция: та, которая возвращает шаблон выражения.

С<sin>мы полагались на Proto, чтобы обеспечить перегруженный<operator()()>, чтобы построить узел выражения с типом тега<proto::tag::function>для нас. Теперь мы должны сделать это сами. Как и раньше, у узла будет двое детей: функция вызова и аргумент функции.

С<sin>функция вызова была необработанным указателем функции, завернутым в терминал Proto. В случае<pow>мы хотим, чтобы это был терминал, содержащий объект функции в стиле TR1. Это позволит нам параметризировать функцию на экспоненте. Ниже приведена реализация простой обертки в стиле TR1 для функции<std::pow>:

// Define a pow_fun function object
template< int Exp >
struct pow_fun
{
    typedef double result_type;
    double operator()(double d) const
    {
        return std::pow(d, Exp);
    }
};

Следуя примеру<sin>, мы хотим<pow< 1>( pi/2)>иметь такой тип:

// The type of the expression pow<1>(pi/2):
proto::function<
    proto::terminal< pow_fun<1> >::type
    proto::result_of::as_child< double const >::type
>::type

Мы могли бы написать функцию<pow()>, используя такой код, но она многословна и подвержена ошибкам; слишком легко ввести тонкие ошибки, забыв позвонить<proto::as_child()>, где это необходимо, в результате чего код, который, кажется, работает, но иногда не работает. Proto обеспечивает лучший способ построения экспрессионных узлов:<proto::make_expr()>.

Lazy Functions Made Simple With make_expr()

Proto помогает создавать шаблоны выражения под названием<proto::make_expr()>. Мы можем кратко определить функцию<pow()>с ней как ниже.

// Define a lazy pow() function for the calculator EDSL.
// Can be used as: pow< 2 >(_1)
template< int Exp, typename Arg >
typename proto::result_of::make_expr<
    proto::tag::function  // Tag type
  , pow_fun< Exp >        // First child (by value)
  , Arg const &           // Second child (by reference)
>::type const
pow(Arg const &arg)
{
    return proto::make_expr<proto::tag::function>(
        pow_fun<Exp>()    // First child (by value)
      , boost::ref(arg)   // Second child (by reference)
    );
}

Есть некоторые вещи, которые следует отметить в вышеупомянутом коде. Мы используем<proto::result_of::make_expr<>>для расчета типа возврата. Первый параметр шаблона - это тип тега для узла выражения, который мы строим - в данном случае<proto::tag::function>.

Последующие параметры шаблона<proto::result_of::make_expr<>>представляют собой дочерние узлы. Если тип ребенка еще не является выражением Прото, он автоматически превращается в терминал с<proto::as_child()>. Тип, такой как<pow_fun<Exp>>, приводит к терминалу, который удерживается значением, тогда как тип, такой как<Arg const&>(обратите внимание на ссылку), указывает, что результат должен удерживаться ссылкой.

В теле функции находится вызов времени выполнения<proto::make_expr()>. Это близко отражает расчет типа возврата.<proto::make_expr()>требует, чтобы вы указали тип тега узла в качестве параметра шаблона. Аргументами функции становятся дети узла. Когда ребенка нужно хранить по ценности, ничего особенного делать не надо. Когда ребенок должен храниться по ссылке, вы должны использовать функцию<boost::ref()>, чтобы обернуть аргумент.

И это все!<proto::make_expr()>- это способ ленивого человека сделать ленивую забаву.

В этом разделе мы узнаем все одоменах. В частности, мы узнаем:

double data[] = {1., 2., 3., 4.};
// Use the calculator EDSL to square each element ... HOW?
std::transform( data, data + 4, data, _1 * _1 );

The extends<> Expression Wrapper

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

// A type to be used as a domain tag (to be defined below)
struct calculator_domain;

Мы используем этот тип домена при расширении типа<proto::expr<>>, что мы делаем с шаблоном класса<proto::extends<>>. Вот наша обертка для выражения, которая наполняет выражение калькулятором. Это описано ниже.

// The calculator<> expression wrapper makes expressions
// function objects.
template< typename Expr >
struct calculator
  : proto::extends< Expr, calculator< Expr >, calculator_domain >
{
    typedef
        proto::extends< Expr, calculator< Expr >, calculator_domain >
    base_type;
    calculator( Expr const &expr = Expr() )
      : base_type( expr )
    {}
    // This is usually needed because by default, the compiler-
    // generated assignment operator hides extends<>::operator=
    BOOST_PROTO_EXTENDS_USING_ASSIGN(calculator)
    typedef double result_type;
    // Hide base_type::operator() by defining our own which
    // evaluates the calculator expression with a calculator context.
    result_type operator()( double d1 = 0.0, double d2 = 0.0 ) const
    {
        // As defined in the Hello Calculator section.
        calculator_context ctx;
        // ctx.args is a vector<double> that holds the values
        // with which we replace the placeholders (e.g., _1 and _2)
        // in the expression.
        ctx.args.push_back( d1 ); // _1 gets the value of d1
        ctx.args.push_back( d2 ); // _2 gets the value of d2
        return proto::eval(*this, ctx ); // evaluate the expression
    }
};

Мы хотим, чтобы выражения калькулятора были функциональными объектами, поэтому мы должны определить<operator()>, который принимает и возвращает удваивается. С помощью<proto::extends<>>обертки выше это делает<calculator<>>шаблон. Первый шаблон к<proto::extends<>>параметру — это тип выражения, который мы расширяем. Второй — это тип завернутого выражения. Третий параметр — это домен, с которым связана эта обертка. Тип обертки, такой как<calculator<>>, который наследует от<proto::extends<>>, ведет себя так же, как тип выражения, который он расширил, с любым дополнительным поведением, которое вы решите дать ему.

Note

Почему бы не наследовать от<proto::expr<>>? Вы можете подумать, что этот бизнес по расширению выражения излишне сложен. Почему C++ поддерживает наследование? Почему<calculator<Expr>>не может просто наследовать от<Expr>напрямую? Причина в том, что<Expr>, который предположительно является инстанциацией<proto::expr<>>, имеет перегрузки оператора построения шаблонов экспрессии, которые будут неверными для производных типов. Они будут хранить<*this>со ссылкой на<proto::expr<>>, эффективно отрезая любые производные части.<proto::extends<>>дает оператору производных типов перегрузки, которые не срезают дополнительных участников.

Хотя это и не является строго необходимым в данном случае, мы вводим<extends<>::operator=>в область применения макроса<BOOST_PROTO_EXTENDS_USING_ASSIGN()>. Это действительно необходимо, только если вы хотите, чтобы такие выражения, как<_1 =3>, создавали лениво оцененное задание.<proto::extends<>>определяет подходящий<operator=>для вас, но созданный компилятором<calculator<>::operator=>будет скрывать его, если вы не сделаете его доступным с помощью макроса.

Обратите внимание, что при реализации<calculator<>::operator()>мы оцениваем выражение с<calculator_context>, которое мы определили ранее. Как мы видели ранее, контекст — это то, что придает операторам их значение. В случае калькулятора контекст также определяет значение терминалов заполнителя.

Теперь, когда мы определили экспрессионную обертку<calculator<>>, нам нужно обернуть заполнители, чтобы наполнить их калькулятором:

calculator< proto::terminal< placeholder<0> >::type > const _1;
calculator< proto::terminal< placeholder<1> >::type > const _2;

Retaining POD-ness with BOOST_PROTO_EXTENDS()

Чтобы использовать<proto::extends<>>, ваш тип расширения должен исходить из<proto::extends<>>. К сожалению, это означает, что ваш тип расширения больше не является POD, и его экземпляры не могут бытьстатически инициализированы. (См. разделСтатическая инициализацияв приложенииОбоснование, почему это важно.) В частности, как определено выше, глобальные объекты-заполнители<_1>и<_2>должны быть инициализированы во время выполнения, что может привести к тонкому порядку ошибок инициализации.

Есть еще один способ сделать расширение выражения, которое не приносит в жертву POD-несущность: макрос<BOOST_PROTO_EXTENDS>. Вы можете использовать его так же, как вы используете<proto::extends<>>. Мы можем использовать<BOOST_PROTO_EXTENDS>(), чтобы сохранить<calculator<>>POD и наши заполнители статически инициализированы.

// The calculator<> expression wrapper makes expressions
// function objects.
template< typename Expr >
struct calculator
{
    // Use BOOST_PROTO_EXTENDS() instead of proto::extends<> to
    // make this type a Proto expression extension.
    BOOST_PROTO_EXTENDS(Expr, calculator<Expr>, calculator_domain)
    typedef double result_type;
    result_type operator()( double d1 = 0.0, double d2 = 0.0 ) const
    {
        /* ... as before ... */
    }
};

С новым типом<calculator<>>мы можем переопределить наши заполнители для статической инициализации:

calculator< proto::terminal< placeholder<0> >::type > const _1 = {{{}}};
calculator< proto::terminal< placeholder<1> >::type > const _2 = {{{}}};

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

Что делает<BOOST_PROTO_EXTENDS>? Он определяет элемент данных расширяемого типа выражения; некоторые вложенные типдефы, которые требуются Proto;<operator=>,<operator[]>и<operator()>перегрузки для построения шаблонов выражения; и вложенный<result<>>шаблон для расчета типа возврата<operator()>. Однако в этом случае перегрузки<operator()>и шаблон<result<>>не нужны, потому что мы определяем наш собственный<operator()>в<calculator<>>типе. Proto предоставляет дополнительные макросы для более точного контроля над функциями членов. Мы могли бы улучшить наш<calculator<>>тип следующим образом:

// The calculator<> expression wrapper makes expressions
// function objects.
template< typename Expr >
struct calculator
{
    // Use BOOST_PROTO_BASIC_EXTENDS() instead of proto::extends<> to
    // make this type a Proto expression extension:
    BOOST_PROTO_BASIC_EXTENDS(Expr, calculator<Expr>, calculator_domain)
    // Define operator[] to build expression templates:
    BOOST_PROTO_EXTENDS_SUBSCRIPT()
    // Define operator= to build expression templates:
    BOOST_PROTO_EXTENDS_ASSIGN()
    typedef double result_type;
    result_type operator()( double d1 = 0.0, double d2 = 0.0 ) const
    {
        /* ... as before ... */
    }
};

Обратите внимание, что теперь мы используем<BOOST_PROTO_BASIC_EXTENDS>()вместо<BOOST_PROTO_EXTENDS>(). Это просто добавляет элемент данных и вложенные типдефы, но не любой из перегруженных операторов. Они добавляются отдельно<BOOST_PROTO_EXTENDS_ASSIGN>()и<BOOST_PROTO_EXTENDS_SUBSCRIPT>(). Мы исключаем оператор вызова функций и вложенный шаблон<result<>>, который мог быть определен с макросом Proto<BOOST_PROTO_EXTENDS_FUNCTION>() [316).

Итак, вот макросы, которые вы можете использовать для определения расширений выражений, и краткое описание каждого из них.

Table 29.2. Expression Extension Macros

Макро	Цель
BOOST_PROTO_BASIC_EXTENDS( expression , extension , domain )	Определяет элемент данных типа<expression>и некоторые вложенные типдефы, которые требуются Proto.
<BOOST_PROTO_EXTENDS_ASSIGN>()	Определяет<operator=>. Только тогда, когда ему предшествует<BOOST_PROTO_BASIC_EXTENDS> .
<BOOST_PROTO_EXTENDS_SUBSCRIPT>[]	Определяет<operator[]>. Только тогда, когда ему предшествует<BOOST_PROTO_BASIC_EXTENDS> .
<BOOST_PROTO_EXTENDS_FUNCTION>	Определяет<operator()>и вложенный<result<>>шаблон для расчета типа возврата. Только тогда, когда ему предшествует<BOOST_PROTO_BASIC_EXTENDS> .
BOOST_PROTO_EXTENDS( expression , extension , domain )	Equivalent to: BOOST_PROTO_BASIC_EXTENDS(expression, extension, domain) BOOST_PROTO_EXTENDS_ASSIGN() BOOST_PROTO_EXTENDS_SUBSCRIPT() BOOST_PROTO_EXTENDS_FUNCTION()

Warning

Аргументно-зависимый поиск и<BOOST_PROTO_EXTENDS> Перегрузки оператора Proto определяются в пространстве имен<boost::proto>и обнаруживаются в зависимости от аргумента поиска (ADL). Обычно это работает только потому, что выражения состоят из типов, которые живут в пространстве имен<boost::proto>. Однако иногда, когда вы используете<BOOST_PROTO_EXTENDS>(), это не так. Подумайте: template<class T> struct my_complex { BOOST_PROTO_EXTENDS( typename proto::terminal<std::complex<T> >::type , my_complex<T> , proto::default_domain ) }; int main() { my_complex<int> c0, c1; c0 + c1; // ERROR: operator+ not found } Проблема связана с тем, как работает аргументированный поиск. Тип<my_complex<int>>никак не связан с пространством имен<boost::proto>, поэтому операторы, определенные там, не рассматриваются. (Если бы мы унаследовали от<proto::extends<>>вместо использования<BOOST_PROTO_EXTENDS>(), мы бы избежали проблемы, потому что наследования от типа в<boost::proto>пространстве имен достаточно, чтобы получить ADL, чтобы начать.) Так что мы можем сделать? Добавив дополнительный параметр шаблона, который по умолчанию соответствует типу в пространстве имен<boost::proto>, мы можем обмануть ADL, чтобы найти правильные перегрузки оператора. Решение выглядит так: template<class T, class Dummy = proto::is_proto_expr> struct my_complex { BOOST_PROTO_EXTENDS( typename proto::terminal<std::complex<T> >::type , my_complex<T> , proto::default_domain ) }; int main() { my_complex<int> c0, c1; c0 + c1; // OK, operator+ found now! } Тип<proto::is_proto_expr>не что иное, как пустая структура, но, сделав ее параметром шаблона, мы делаем<boost::proto>ассоциированным пространством имен<my_complex<int>>. Теперь ADL может успешно обнаруживать перегрузки оператора Proto.

// Define the calculator_domain we forward-declared above.
// Specify that all expression in this domain should be wrapped
// in the calculator<> expression wrapper.
struct calculator_domain
  : proto::domain< proto::generator< calculator > >
{};

// If calculator<> uses BOOST_PROTO_EXTENDS() instead of 
// use proto::extends<>, use proto::pod_generator<> instead
// of proto::generator<>.
struct calculator_domain
  : proto::domain< proto::pod_generator< calculator > >
{};

double data[] = {1., 2., 3., 4.};
// Use the calculator EDSL to square each element ... WORKS! :-)
std::transform( data, data + 4, data, _1 * _1 );

// Define the grammar of calculator expressions
struct calculator_grammar
  : proto::or_<
        proto::plus< calculator_grammar, calculator_grammar >
      , proto::minus< calculator_grammar, calculator_grammar >
      , proto::multiplies< calculator_grammar, calculator_grammar >
      , proto::divides< calculator_grammar, calculator_grammar >
      , proto::terminal< proto::_ >
    >
{};

// Define the calculator_domain. Expressions in the calculator
// domain are wrapped in the calculator<> wrapper, and they must
// conform to the calculator_grammar:
struct calculator_domain
  : proto::domain< proto::generator< calculator >, calculator_grammar  >
{};

// For expressions in my_domain, disable Proto's
// unary address-of operator.
struct my_domain
  : proto::domain<
        proto::generator< my_wrapper >
        // A simple grammar that matches any expression that
        // is not a unary address-of expression.
      , proto::not_< proto::address_of< _ > >
    >
{};

Controlling How Child Expressions Are Captured

	Note
	Это продвинутая тема. Не стесняйтесь пропустить это, если вы только начинаете с Proto.

Оператор Proto перегружает сборку выражений из подвыражений. Суб-выражения становятся детьми нового выражения. По умолчанию дети хранятся у родителя по ссылке. В этом разделе описывается, как изменить этот дефолт.

Primer: as_child vs. as_expr

Прото позволяет самостоятельно настраивать поведение<proto::as_child()>и<proto::as_expr()>. Оба принимают объект<x>и возвращают выражение Прото, превращая его<x>в терминал Прото, если это необходимо. Хотя эти две функции похожи, они используются в разных ситуациях и по умолчанию имеют разное поведение. Важно понимать разницу, чтобы вы знали, что настроить для достижения желаемого поведения.

<proto::as_expr()>обычно используетсявы, чтобы превратить объект в выражение Прото, которое должно содержаться в локальной переменной, так как:

auto l = proto::as_expr(x); // Turn x into a Proto expression, hold the result in a local

Вышеизложенное работает независимо от того, является ли<x>уже выражением Прото или нет. Объект<l>гарантированно является действительным выражением Прото. Если<x>является непротообъектом, он превращается в терминальное выражение, которое удерживает<x>по значению.<#include <boost/proto/core.hpp>>Если<x>уже является объектом Прото,<proto::as_expr()>возвращает егопо значениюнеизмененным.

Напротив,<proto::as_child()>используется внутри Proto для предварительной обработки объектов, прежде чем сделать их детьми другого выражения. Поскольку он является внутренним для Proto, вы не видите его явно, но он есть за кулисами в таких выражениях:

x + y; // Consider that y is a Proto expression, but x may or may not be.

В этом случае Proto строит узел плюс от двух детей. Оба предварительно обрабатываются, передавая их<proto::as_child()>, прежде чем сделать их детьми нового узла. Если<x>не является выражением Прото, оно становится таковым, будучи завернутым в терминал Прото, который удерживает егопосредством ссылки. Если<x>уже является выражением Прото,<proto::as_child()>возвращает егопосредством ссылкинеизмененным. Сравните это с приведенным выше описанием<proto::as_expr()>.

В приведенной ниже таблице кратко изложено вышеизложенное описание.

Table 29.3. proto::as_expr() vs. proto::as_child()

Функция	454Когда<t>не является прото-экспром...	Когда<t>является прото-экспром...
<proto::as_expr(t)>	Возврат (по стоимости) нового держателя терминала Proto<t>по стоимости.	Возврат<t>по стоимости без изменения.
<proto::as_child(t)>	Возврат (по стоимости) нового держателя терминала Proto<t>по ссылке.

	Note
	Есть одно важное место, где Прото использует<as_expr>и<as_child>:<proto::make_expr()>. Функция<proto::make_expr()>требует, чтобы вы указали для каждого ребенка, должна ли она храниться по стоимости или по ссылке. Proto использует<proto::as_expr()>для предварительной обработки детей, удерживаемых стоимостью, и<proto::as_child()>для тех, которые удерживаются ссылкой.

Теперь, когда вы знаете, что такое<proto::as_child()>и<proto::as_expr()>, где они используются и что они делают по умолчанию, вы можете решить, что одна или обе эти функции должны иметь различное поведение для вашего домена. Например, учитывая приведенное выше описание<proto::as_child()>, следующий код всегда неверен:

proto::literal<int> i(0);
auto l = i + 42; // This is WRONG! Don't do this.

Почему это неправильно? Потому что<proto::as_child()>превратит целое число 42 в терминал Прото, который содержит ссылку на временное целое число, инициализированное с 42. Время жизни этого временного числа заканчивается в полуколоне, гарантируя, что местный<l>останется с болтающейся ссылкой на целое число умерших. Что делать? Один из ответов — использовать<proto::deep_copy()>. Другой способ — настроить поведение<proto::as_child()>для вашего домена. Читайте дальше для деталей.

Per-Domain as_child

Чтобы контролировать, как Proto строит выражения из подвыражений в вашем домене, определите свой домен как обычно, а затем определите вложенный шаблон класса<as_child<>>в нем следующим образом:

class my_domain
  : proto::domain< my_generator, my_grammar >
{
    // Here is where you define how Proto should handle
    // sub-expressions that are about to be glommed into
    // a larger expression.
    template< typename T >
    struct as_child
    {
        typedef unspecified-Proto-expr-type result_type;
        result_type operator()( T & t ) const
        {
            return unspecified-Proto-expr-object;
        }
    };
};

Следует отметить одну важную вещь: в приведенном выше коде параметр шаблона<T>может быть или не быть типом выражения Proto, но результатдолженбыть типом выражения Proto или ссылкой на него. Это означает, что большинство шаблонов, определяемых пользователем<as_child<>>, должны проверить, является ли<T>выражением или нет (с использованием<proto::is_expr<>>), а затем превратить невыражения в терминалы Proto, обернув их как<proto::terminal</* ... */ >::type>или эквивалент.

Per-Domain as_expr

Хотя это менее распространено, Proto также позволяет настраивать поведение<proto::as_expr()>на основе каждого домена. Техника идентична таковой для<as_child>. См. ниже:

class my_domain
  : proto::domain< my_generator, my_grammar >
{
    // Here is where you define how Proto should handle
    // objects that are to be turned into expressions
    // fit for storage in local variables.
    template< typename T >
    struct as_expr
    {
        typedef unspecified-Proto-expr-type result_type;
        result_type operator()( T & t ) const
        {
            return unspecified-Proto-expr-object;
        }
    };
};

Making Proto Expressions auto-safe

Давайте еще раз рассмотрим проблему, описанную выше, связанную с ключевым словом C++11<auto>и поведением по умолчанию<proto::as_child()>.

proto::literal<int> i(0);
auto l = i + 42; // This is WRONG! Don't do this.

Напомним, что проблема заключается в сроке службы временного целого числа, созданного для удержания значения 42. Местный<l>останется с намеком на него после того, как его жизнь закончится. Что, если мы хотим, чтобы Proto делал выражения безопасными для хранения в локальных переменных? Мы можем сделать это очень легко, заставив<proto::as_child()>вести себя так же, как<proto::as_expr()>. Это достигается следующим кодом:

template< typename E >
struct my_expr;
struct my_generator
  : proto::pod_generator< my_expr >
{};
struct my_domain
  : proto::domain< my_generator >
{
     // Make as_child() behave like as_expr() in my_domain.
     // (proto_base_domain is a typedef for proto::domain< my_generator >
     // that is defined in proto::domain<>.)
     template< typename T >
     struct as_child
       : proto_base_domain::as_expr< T >
     {};
};
template< typename E >
struct my_expr
{
    BOOST_PROTO_EXTENDS( E, my_expr< E >, my_domain )
};
/* ... */
proto::literal< int, my_domain > i(0);
auto l = i + 42; // OK! Everything is stored by value here.

Обратите внимание, что<my_domain::as_child<>>просто откладывается от реализации по умолчанию<as_expr<>>, найденной в<proto::domain<>>. Путем простого перекрестного подключения нашего домена<as_child<>>к<as_expr<>>мы гарантируем, что все терминалы, которые могут удерживаться стоимостью, являются, и что все выражения ребенка также удерживаются стоимостью. Это увеличивает копирование и может повлечь за собой затраты на производительность во время выполнения, но это устраняет любые проблемы управления сроком службы.

В другом примере см. определение<lldomain>в<libs/proto/example/lambda.hpp>. Этот пример является полным повторением Библиотеки Boost Lambda (BLL) на вершине Boost. Объекты функции, генерируемые BLL, безопасны для хранения в локальных переменных. Чтобы эмулировать это с помощью Proto,<lldomain>кросс-провода<as_child<>>до<as_expr<>>, как указано выше, но с одним дополнительным поворотом: объекты с типом массива также хранятся по ссылке. Посмотри.

EDSL Interoperatability: Sub-Domains

	Note
	Это продвинутая тема. Не стесняйтесь пропустить это, если вы только начинаете с Proto.

Способностьсоставлятьразличные EDSL является одной из их самых захватывающих особенностей. Подумайте, как вы строите парсер с использованием yacc. Вы пишете свои правила грамматики на доменном языке yacc. Затем вы встраиваете семантические действия, написанные на C, в свою грамматику. Парсерный генератор Boost Spirit дает вам такую же возможность. Вы пишете грамматические правила, используя Дух. Ци и встраивание семантических действий с помощью библиотеки Феникса. Phoenix и Spirit являются прото-ориентированными доменными языками со своим собственным синтаксисом и семантикой. Но вы можете свободно встраивать выражения Феникса в выражения Духа. В этом разделе описана функция поддомена Proto, которая позволяет определять семейства взаимодействующих доменов.

Dueling Domains

Когда вы пытаетесь создать выражение из двух подвыражений в разных доменах, что такое домен полученного выражения? Это основная проблема, которая решается поддоменами. Рассмотрим следующий код:

#include <boost/proto/proto.hpp>
namespace proto = boost::proto;
// Forward-declare two expression wrappers
template<typename E> struct spirit_expr;
template<typename E> struct phoenix_expr;
// Define two domains
struct spirit_domain  : proto::domain<proto::generator<spirit_expr> > {};
struct phoenix_domain : proto::domain<proto::generator<phoenix_expr> > {};
// Implement the two expression wrappers
template<typename E>
struct spirit_expr
  : proto::extends<E, spirit_expr<E>, spirit_domain>
{
    spirit_expr(E const &e = E()) : spirit_expr::proto_extends(e) {}
};
template<typename E>
struct phoenix_expr
  : proto::extends<E, phoenix_expr<E>, phoenix_domain>
{
    phoenix_expr(E const &e = E()) : phoenix_expr::proto_extends(e) {}
};
int main()
{
    proto::literal<int, spirit_domain> sp(0);
    proto::literal<int, phoenix_domain> phx(0);
    // Whoops! What does it mean to add two expressions in different domains?
    sp + phx; // ERROR
}

Выше мы определяем два домена, называемые<spirit_domain>и<phoenix_domain>, и объявляем два буквальных обозначения в каждом. Затем мы пытаемся составить их в более крупное выражение с помощью оператора двоичного плюса Proto, и это не удается. Прото не может понять, должно ли полученное выражение быть в области Духа или в области Феникса, и, таким образом, должно ли оно быть примером<spirit_expr<>>или<phoenix_expr<>>. Мы должны рассказать Прото, как разрешить конфликт. Мы можем сделать это, объявив, что Феникс является поддоменом Духа, как в следующем определении<phoenix_domain>:

// Declare that phoenix_domain is a sub-domain of spirit_domain
struct phoenix_domain
  : proto::domain<proto::generator<phoenix_expr>, proto::_, spirit_domain>
{};

Третий параметр шаблона<proto::domain<>>— супердомен. Определяя<phoenix_domain>выше, мы говорим, что выражения Феникса могут быть объединены с выражениями Духа, и что, когда это происходит, результирующее выражение должно быть выражением Духа.

	Note
	Если вам интересно, какова цель<proto::_>в определении<phoenix_domain>выше, помните, что второй параметр шаблона к<proto::domain<>>является грамматикой домена.& #8220;<proto::_>& #8221;является по умолчанию и означает, что домен не накладывает никаких ограничений на выражения, которые действительны в нем.

Domain Resolution

Когда в заданном выражении задействовано несколько доменов, Proto использует некоторые правила, чтобы выяснить, какой домен «выигрывает». Правила слабо смоделированы на правилах наследования C++.<Phoenix_domain>является поддоменом<spirit_domain>. Вы можете сравнить это с производными / базовыми отношениями, которые придают выражениям Феникса неявное преобразование в выражения Духа. И поскольку выражения Феникса могут быть «превращены» в выражения Духа, они могут свободно сочетаться с выражениями Духа, и результатом является выражение Духа.

	Note
	Супер- и поддомены фактически не реализуются с использованием наследования. Это только полезная ментальная модель.

Аналогия с наследованием имеет место даже в случае трех доменов, когда два являются поддоменами третьего. Представьте себе другой домен под названием<foobar_domain>, который также был поддоменом<spirit_domain>. Выражения в<foobar_domain>могут быть объединены с выражениями в<phoenix_domain>, и результирующее выражение будет в<spirit_domain>. Это потому, что выражения в двух поддоменах имеют «конверсии» в супердомен, поэтому операция разрешена, и супердомен выигрывает.

The Default Domain

Когда вы не присваиваете выражение Proto определенному домену, Proto считает его членом так называемого домена по умолчанию<proto::default_domain>. Даже объекты, не являющиеся Proto, рассматриваются как терминалы в домене по умолчанию. Подумайте:

int main()
{
    proto::literal<int, spirit_domain> sp(0);
    // Add 1 to a spirit expression. Result is a spirit expression.
    sp + 1;
}

Выражения в домене по умолчанию (или невыражения, такие как<1>) имеют своего рода неявное преобразование в выражения любого другого типа домена. Более того, вы можете определить свой домен как поддомен домена по умолчанию. При этом вы даете выражения в ваших конверсиях домена в выражения в любом другом домене. Это как& #8220;свободная любовь& #8221;домен, потому что он будет свободно смешиваться со всеми другими доменами.

Давайте еще раз подумаем о Phoenix EDSL. Поскольку он обеспечивает в целом полезную лямбда-функциональность, разумно предположить, что многие другие EDSL, помимо Spirit, могут захотеть встроить выражения Phoenix. Иными словами,<phoenix_domain>должно быть поддоменом<proto::default_domain>, а не<spirit_domain>:

// Declare that phoenix_domain is a sub-domain of proto::default_domain
struct phoenix_domain
  : proto::domain<proto::generator<phoenix_expr>, proto::_, proto::default_domain>
{};

Это намного лучше. Выражения Феникса теперь можно ставить где угодно.

Sub-Domain Summary

Используйте поддомены Proto, чтобы смешивать выражения из нескольких доменов. И если вы хотите, чтобы выражения в вашем домене свободно комбинировались свсемивыражениями, сделайте его поддоменом<proto::default_domain>.

Предыдущие обсуждения определения передних концов Proto сделали большое предположение: у вас есть роскошь определять все с нуля. Что произойдет, если у вас есть существующие типы, например, тип матрицы и векторный тип, которые вы хотели бы рассматривать как прото-терминалы? Прото обычно торгуется только в своих собственных типах выражений, но с<BOOST_PROTO_DEFINE_OPERATORS>(), он также может размещать ваши пользовательские типы терминалов.

Допустим, например, что у вас есть следующие типы и что вы не можете изменить их, чтобы сделать их& #8220;родные& #8221;типы терминалов Proto.

namespace math
{
    // A matrix type ...
    struct matrix { /*...*/ };
    // A vector type ...
    struct vector { /*...*/ };
}

Вы можете ненавязчиво создавать объекты этих типов терминалов Proto, определяя соответствующие операторские перегрузки с помощью<BOOST_PROTO_DEFINE_OPERATORS>(). Основная процедура заключается в следующем:

Следующий код показывает, как это работает.

namespace math
{
    template<typename T>
    struct is_terminal
      : mpl::false_
    {};
    // OK, "matrix" is a custom terminal type
    template<>
    struct is_terminal<matrix>
      : mpl::true_
    {};
    // OK, "vector" is a custom terminal type
    template<>
    struct is_terminal<vector>
      : mpl::true_
    {};
    // Define all the operator overloads to construct Proto
    // expression templates, treating "matrix" and "vector"
    // objects as if they were Proto terminals.
    BOOST_PROTO_DEFINE_OPERATORS(is_terminal, proto::default_domain)
}

Вызыв макроса<BOOST_PROTO_DEFINE_OPERATORS>определяет полный набор операторских перегрузок, которые обрабатывают<matrix>и<vector>объекты, как если бы они были терминалами Proto. И поскольку операторы определены в том же пространстве имен, что и типы<matrix>и<vector>, операторы будут найдены путем поиска, зависящего от аргументов. С приведенным выше кодом мы теперь можем создавать шаблоны экспрессии с матрицами и векторами, как показано ниже.

math::matrix m1;
math::vector v1;
proto::literal<int> i(0);
m1 * 1;  // custom terminal and literals are OK
m1 * i;  // custom terminal and Proto expressions are OK
m1 * v1; // two custom terminals are OK, too.

Иногда, чтобы сделать жизнь ваших пользователей легкой, вы должны сделать свою собственную жизнь трудной. Предоставление пользователям естественного и гибкого синтаксиса часто включает в себя написание большого количества повторяющихся перегрузок функций. Этого может быть достаточно, чтобы получить повторяющиеся стрессовые травмы! Прежде чем навредить себе, ознакомьтесь с макросами, которые Proto предоставляет для автоматизации многих повторяющихся задач по генерации кода.

Представьте, что мы пишем лямбда EDSL, и мы хотели бы включить синтаксис для построения временных объектов любого типа с использованием следующего синтаксиса:

// A lambda expression that takes two arguments and
// uses them to construct a temporary std::complex<>
construct< std::complex<int> >( _1, _2 )

Для обсуждения представьте, что у нас уже есть шаблон объекта функции<construct_impl<>>, который принимает аргументы и конструирует из них новые объекты. Мы хотели бы, чтобы приведенное выше выражение лямбда было эквивалентно следующему:

// The above lambda expression should be roughly equivalent
// to the following:
proto::make_expr<proto::tag::function>(
    construct_impl<std::complex<int> >() // The function to invoke lazily
  , boost::ref(_1)                       // The first argument to the function
  , boost::ref(_2)                       // The second argument to the function
);

Мы можем определить наш шаблон функции<construct()>следующим образом:

template<typename T, typename A0, typename A1>
typename proto::result_of::make_expr<
    proto::tag::function
  , construct_impl<T>
  , A0 const &
  , A1 const &
>::type const
construct(A0 const &a0, A1 const &a1)
{
    return proto::make_expr<proto::tag::function>(
        construct_impl<T>()
      , boost::ref(a0)
      , boost::ref(a1)
    );
}

Это работает для двух аргументов, но мы хотели бы, чтобы это работало для любого количества аргументов, вплоть до<BOOST_PROTO_MAX_ARITY>.- 1. Почему "- 1"? Потому что один ребенок занят терминалом<construct_impl<T>()>, оставляя место только для<BOOST_PROTO_MAX_ARITY>- 1] других детей.

Для таких случаев Proto предоставляет макросы<BOOST_PROTO_REPEAT>()и<BOOST_PROTO_REPEAT_FROM_TO>(). Чтобы использовать его, мы превращаем определение функции выше в макрос следующим образом:

#define M0(N, typename_A, A_const_ref, A_const_ref_a, ref_a)  \
template<typename T, typename_A(N)>                           \
typename proto::result_of::make_expr<                         \
    proto::tag::function                                      \
  , construct_impl<T>                                         \
  , A_const_ref(N)                                            \
>::type const                                                 \
construct(A_const_ref_a(N))                                   \
{                                                             \
    return proto::make_expr<proto::tag::function>(            \
        construct_impl<T>()                                   \
      , ref_a(N)                                              \
    );                                                        \
}

Обратите внимание, что мы превратили функцию в макрос, который принимает 5 аргументов. Первый — это текущий номер итерации. Остальные — названия других макросов, генерирующих разные последовательности. Например, Прото передает в качестве второго параметра имя макроса, которое будет расширяться до<typenameA0,typenameA1,...>.

Теперь, когда мы превратили нашу функцию в макрос, мы можем передать макрос<BOOST_PROTO_REPEAT_FROM_TO>(). Прото будет вызывать его итеративно, генерируя все перегрузки функции для нас.

// Generate overloads of construct() that accept from
// 1 to BOOST_PROTO_MAX_ARITY-1 arguments:
BOOST_PROTO_REPEAT_FROM_TO(1, BOOST_PROTO_MAX_ARITY, M0)
#undef M0

Non-Default Sequences

Как упоминалось выше, Proto передает в качестве последних 4 аргументов вашему макросу имена других макросов, которые генерируют различные последовательности. Макросы<BOOST_PROTO_REPEAT>()и<BOOST_PROTO_REPEAT_FROM_TO>()выбирают по умолчанию эти параметры. Если по умолчанию не удовлетворяются ваши потребности, вы можете использовать<BOOST_PROTO_REPEAT_EX>()и<BOOST_PROTO_REPEAT_FROM_TO_EX>()и передавать разные макросы, которые генерируют разные последовательности. Прото определяет ряд таких макросов для использования в качестве параметров к<BOOST_PROTO_REPEAT_EX>()и<BOOST_PROTO_REPEAT_FROM_TO_EX>(). Для всех подробностей ознакомьтесь с разделом<boost/proto/repeat.hpp>.

Смотрите также<BOOST_PROTO_LOCAL_ITERATE>. Он работает аналогично<BOOST_PROTO_REPEAT>и друзьям, но его легче использовать, когда вы хотите изменить один макро аргумент и принять по умолчанию для других.

Собрав выражение в дерево, вы, естественно, захотите сделать обратное и получить доступ к детям узла. Вы даже можете захотеть повторить над детьми с помощью алгоритмов от Boost. Библиотека Fusion. В этом разделе показано как.

Getting Expression Tags and Arities

Каждый узел в дереве экспрессии имеет как тип тега, который описывает узел, так иarity, соответствующий количеству дочерних узлов, которые он имеет. Вы можете использовать<proto::tag_of<>>и<proto::arity_of<>>метафункции для их извлечения. Рассмотрим следующее:

template<typename Expr>
void check_plus_node(Expr const &)
{
    // Assert that the tag type is proto::tag::plus
    BOOST_STATIC_ASSERT((
        boost::is_same<
            typename proto::tag_of<Expr>::type
          , proto::tag::plus
        >::value
    ));
    // Assert that the arity is 2
    BOOST_STATIC_ASSERT( proto::arity_of<Expr>::value == 2 );
}
// Create a binary plus node and use check_plus_node()
// to verify its tag type and arity:
check_plus_node( proto::lit(1) + 2 );

Для данного типа<Expr>вы можете получить доступ к тегу<Expr::proto_tag>и<Expr::proto_arity>, где<Expr::proto_arity>является интегральной константой MPL.

Getting Terminal Values

Нет более простого выражения, чем терминал, и нет более простой операции, чем извлечение его значения. Как мы уже видели, это то, для чего<proto::value()>.

proto::terminal< std::ostream & >::type cout_ = {std::cout};
// Get the value of the cout_ terminal:
std::ostream & sout = proto::value( cout_ );
// Assert that we got back what we put in:
assert( &sout == &std::cout );

Для вычисления типа возврата функции<proto::value()>можно использовать<proto::result_of::value<>>. Когда параметр<proto::result_of::value<>>является нессылочным типом, результирующий тип метафункции представляет собой тип значения, подходящего для хранения по значению; то есть от него лишаются эталона верхнего уровня и квалификаторов. Но при инстанцированном с эталонным типом тип результата имеет ссылку, добавленную к нему, что дает тип, подходящий для хранения посредством ссылки. Если вы хотите узнать фактический тип значения терминала, в том числе, хранится ли он по значению или ссылке, вы можете использовать<fusion::result_of::value_at<Expr,0>::type>.

В нижеследующей таблице резюмируется вышеупомянутый пункт.

typename boost::remove_const<
    typename boost::remove_reference<T>::type
>::type [a]

typename boost::add_reference<T>::type

typename boost::add_reference<
    typename boost::add_const<T>::type
>::type

proto::terminal<int>::type i = {42};
// Get the 0-th operand of an addition operation:
proto::terminal<int>::type &ri = proto::child_c<0>( i + 2 );
// Assert that we got back what we put in:
assert( &i == &ri );

template<typename Expr>
void test_result_of_child_c(Expr const &expr)
{
    typedef typename proto::result_of::child_c<Expr, 0>::type type;
    // Since Expr is not a reference type,
    // result_of::child_c<Expr, 0>::type is a
    // non-cv qualified, non-reference type:
    BOOST_MPL_ASSERT((
        boost::is_same< type, proto::terminal<int>::type >
    ));
}
// ...
proto::terminal<int>::type i = {42};
test_result_of_child_c( i + 2 );

typename boost::remove_const<
    typename boost::remove_reference<T>::type
>::type

typename boost::add_reference<T>::type

typename boost::add_reference<
    typename boost::add_const<T>::type
>::type

Когда вы строите шаблон выражения с помощью Proto, все промежуточные узлы ребенка удерживаютсяпо ссылке. Избегает ненужных копий, что имеет решающее значение, если вы хотите, чтобы ваш EDSL хорошо работал во время выполнения. Естественно, существует опасность, если временные объекты выходят из-под контроля, прежде чем пытаться оценить шаблон выражения. Это особенно проблема в C++0x с новыми<decltype>и<auto>ключевыми словами. Подумайте:

// OOPS: "ex" is left holding dangling references
auto ex = proto::lit(1) + 2;

Проблема может возникнуть в современном C++, если вы используете<BOOST_TYPEOF()>или<BOOST_AUTO()>, или если вы пытаетесь передать шаблон выражения за пределы его составляющих.

В этих случаях вы хотите глубоко скопировать шаблон выражения так, чтобы все промежуточные узлы и терминалы удерживалисьпо значению. Таким образом, вы можете безопасно назначить шаблон выражения для локальной переменной или вернуть его из функции, не беспокоясь о том, что вы будете использовать ссылки. Вы можете сделать это с помощью<proto::deep_copy()>:

// OK, "ex" has no dangling references
auto ex = proto::deep_copy( proto::lit(1) + 2 );

Если вы используетеBoost.Typeof, это будет выглядеть так:

// OK, use BOOST_AUTO() and proto::deep_copy() to
// store an expression template in a local variable 
BOOST_AUTO( ex, proto::deep_copy( proto::lit(1) + 2 ) );

Для работы вышеупомянутого кода необходимо включить заголовок<boost/proto/proto_typeof.hpp>, который также определяет макрос<BOOST_PROTO_AUTO>, который автоматически копирует его аргумент. С<BOOST_PROTO_AUTO>()вышеупомянутый код может быть записан как:

// OK, BOOST_PROTO_AUTO() automatically deep-copies
// its argument: 
BOOST_PROTO_AUTO( ex, proto::lit(1) + 2 );

При глубокой копировании дерева выражений все промежуточные узлы и все терминалы хранятся по значению. Единственным исключением являются терминалы, которые являются ссылками на функции.

	Note
	<proto::deep_copy()>не делает исключения для массивов, которые он хранит по стоимости. Это может привести к копированию большого количества данных.

Proto предоставляет утилиту для красивой печати деревьев экспрессии, которая очень удобна, когда вы пытаетесь отладить свой EDSL. Он называется<proto::display_expr()>, и вы передаете ему выражение для печати и необязательно<std::ostream>для отправки вывода. Подумайте:

// Use display_expr() to pretty-print an expression tree
proto::display_expr(
    proto::lit("hello") + 42
);

Приведенный выше код пишет об этом<std::cout>:

plus(
    terminal(hello)
  , terminal(42)
)

Для вызова<proto::display_expr()>все терминалы в выражении должны быть потоковыми (то есть они могут быть записаны на<std::ostream>). Кроме того, все типы тегов также должны быть потоковыми. Вот пример, который включает пользовательский тип терминала и пользовательский тег:

// A custom tag type that is Streamable
struct MyTag
{
    friend std::ostream &operator<<(std::ostream &s, MyTag)
    {
        return s << "MyTag";
    }
};
// Some other Streamable type
struct MyTerminal
{
    friend std::ostream &operator<<(std::ostream &s, MyTerminal)
    {
        return s << "MyTerminal";
    }
};
int main()
{
    // Display an expression tree that contains a custom
    // tag and a user-defined type in a terminal
    proto::display_expr(
        proto::make_expr<MyTag>(MyTerminal()) + 42
    );
}

Приведенный выше код печатает следующее:

plus(
    MyTag(
        terminal(MyTerminal)
    )
  , terminal(42)
)

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

Повышаю. Fusion - это библиотека итераторов, алгоритмов, контейнеров и адаптеров для манипулирования гетерогенными последовательностями. По сути, выражение Прото является просто гетерогенной последовательностью его детских выражений, и поэтому выражения Прото являются действительными последовательностями случайного доступа Fusion. Это означает, что вы можете применять к ним алгоритмы Fusion, преобразовывать их, применять к ним фильтры Fusion и просмотры, а также получать доступ к их элементам с помощью<fusion::at()>. То, что Fusion может сделать с гетерогенными последовательностями, выходит за рамки руководства для пользователей, но ниже приведен простой пример. Он принимает вызов ленивой функции, как<fun(1,2,3,4)>и использует Fusion для печати аргументов функции в порядке.

struct display
{
    template<typename T>
    void operator()(T const &t) const
    {
        std::cout << t << std::endl;
    }
};
struct fun_t {};
proto::terminal<fun_t>::type const fun = {{}};
// ...
fusion::for_each(
    fusion::transform(
        // pop_front() removes the "fun" child
        fusion::pop_front(fun(1,2,3,4))
        // Extract the ints from the terminal nodes
      , proto::functional::value()
    )
  , display()
);

Вспомним из Введения, что типы в пространстве имен<proto::functional>определяют функциональные объекты, которые соответствуют свободным функциям Прото. Так<proto::functional::value()>создает объект функции, эквивалентный функции<proto::value()>. Приведенные выше ссылки<fusion::for_each()>показывают следующее:

1
2
3
4

Терминалы также являются действительными последовательностями Fusion. Они содержат один элемент: их ценность.

Flattening Proto Expression Tress

Представьте себе небольшую вариацию вышеприведенного примера, где вместо того, чтобы повторяться над аргументами ленивого вызова функции, мы хотели бы повторить над терминалами в дополнительном выражении:

proto::terminal<int>::type const _1 = {1};
// ERROR: this doesn't work! Why?
fusion::for_each(
    fusion::transform(
        _1 + 2 + 3 + 4
      , proto::functional::value()
    )
  , display()
);

Причина, по которой это не работает, заключается в том, что выражение<_1 +2+3+ 4>не описывает плоскую последовательность терминалов — оно описывает двоичное дерево. Однако мы можем рассматривать его как плоскую последовательность терминалов, используя функцию Прото<proto::flatten()>.<proto::flatten()>возвращает вид, который заставляет дерево выглядеть как плоская последовательность слияния. Если самый верхний узел имеет тип тега<T>, то элементами сплющенной последовательности являются дочерние узлы, которые имеют тип тега, а не<T>. Этот процесс оценивается рекурсивно. Таким образом, вышесказанное может быть правильно написано как:

proto::terminal<int>::type const _1 = {1};
// OK, iterate over a flattened view
fusion::for_each(
    fusion::transform(
        proto::flatten(_1 + 2 + 3 + 4)
      , proto::functional::value()
    )
  , display()
);

Приведенные выше ссылки<fusion::for_each()>показывают следующее:

1
2
3
4

Дерево экспрессии может иметь очень богатую и сложную структуру. Часто вам нужно знать некоторые вещи о структуре выражения, прежде чем вы сможете его обработать. В этом разделе описаны инструменты, которые Proto предоставляет для заглядывания внутрь дерева выражения и обнаружения его структуры. И, как вы увидите в последующих разделах, все действительно интересные вещи, которые вы можете сделать с Proto, начинаются здесь.

proto::terminal< std::istream & >::type cin_ = { std::cin };
proto::terminal< std::ostream & >::type cout_ = { std::cout };

struct Input
  : proto::shift_right< proto::terminal< std::istream & >, proto::_ >
{};
struct Output
  : proto::shift_left< proto::terminal< std::ostream & >, proto::_ >
{};

template< typename Expr >
void input_output( Expr const & expr )
{
    if( proto::matches< Expr, Input >::value )
    {
        std::cout << "Input!\n";
    }
    if( proto::matches< Expr, Output >::value )
    {
        std::cout << "Output!\n";
    }
}
int main()
{
    int i = 0;
    input_output( cout_ << 1 );
    input_output( cin_ >> i );
    return 0;
}

Output!
Input!

template< typename Expr >
typename boost::enable_if< proto::matches< Expr, Input > >::type
input_output( Expr const & expr )
{
    std::cout << "Input!\n";
}
template< typename Expr >
typename boost::enable_if< proto::matches< Expr, Output > >::type
input_output( Expr const & expr )
{
    std::cout << "Output!\n";
}

input_output( cout_ << 1 << 2 ); // oops!

struct Input
  : proto::or_<
        proto::shift_right< proto::terminal< std::istream & >, proto::_ >
      , proto::shift_right< Input, proto::_ >
    >
{};
struct Output
  : proto::or_<
        proto::shift_left< proto::terminal< std::ostream & >, proto::_ >
      , proto::shift_left< Output, proto::_ >
    >
{};

struct CharString
  : proto::terminal< char const * >
{};
typedef proto::terminal< char const[6] >::type char_array;
BOOST_MPL_ASSERT(( proto::matches< char_array, CharString > ));

struct CharString
  : proto::terminal< proto::exact< char const * > >
{};
typedef proto::terminal<char const[6]>::type char_array;
typedef proto::terminal<char const *>::type  char_string;
BOOST_MPL_ASSERT(( proto::matches< char_string, CharString > ));
BOOST_MPL_ASSERT_NOT(( proto::matches< char_array, CharString > ));