rationale.qbk

来自「Boost provides free peer-reviewed portab」· QBK 代码 · 共 100 行

[/
 / Copyright (c) 2008 Eric Niebler
 /
 / Distributed under the Boost Software License, Version 1.0. (See accompanying
 / file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
 /]

[section:rationale Appendix B: Rationale]

[/==================================================]
[section:static_initialization Static Initialization]
[/==================================================]

Proto expression types are PODs (Plain Old Data), and do not have constructors.
They are brace-initialized, as follows:

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

The reason is so that expression objects like `_i` above can be ['statically
initialized]. Why is static initialization important? The terminals of many
domain-specific embedded languages are likely to be global const objects, like
`_1` and `_2` from the Boost Lambda Library. Were these object to require
run-time initialization, it might be possible to use these objects before they
are initialized. That would be bad. Statically initialized objects cannot be
misused that way.

[endsect]

[/======================================================================]
[section:result_of Proto Transforms and the Restricted ResultOf Protocol]
[/======================================================================]

All Proto primitive transforms make use of a variant of the TR1 ResultOf
protocol for computing the type of the transform's return value. Such
transforms must have a nested `result<>` template (not a nested `result_type`
typedef) which takes exactly three parameter types. That is, it must be
defined as:

    template<typename Sig> struct result {};
    
    template<typename This, typename Expr, typename State, typename Visitor>
    struct result<This(Expr, State, Visitor)>
    {
        typedef ... type;
    };

In the above, `Expr`, `State`, and `Visitor` are assumed by Proto to be
non-cv-qualified non-reference types. The implication is that for some
Proto transform `Tr`, some `result_of<>` instantiations work while others
don't. See below.

    // ERROR, doesn't work:
    boost::result_of<Tr(Expr const &, State const &, Visitor &)>::type
    
    // OK, works:
    boost::result_of<Tr(Expr, State, Visitor)>::type

It is done this way largely for compile-time performance. Full
compliance with the TR1 ResultOf protocol incurs a not insignificant penalty
at compile time. Metaprogramming tricks are needed to first detect a nested
`result_type` typedef if it exists. And each nested `result<>` template
would need to be coded specially to handle references and cv-qualifiers, which
incurs many instantiations of `remove_reference<>` and `remove_cv<>`. In 
private testing, this was found to have a measurable impact on compile-time 
performance in the order of 10-15%, which was deemed unacceptable.

The restricted protocol improves compile times while remaining largely
compatible with TR1's `result_of<>`. As a side benefit, it makes
Proto's primitive transforms easier to implement, since the user need not
worry about stripping references and cv-qualification in their nested
`result<>` templates.

[endsect]

[/=========================================================]
[section:preprocessor Why Not Reuse MPL, Fusion, et cetera?]
[/=========================================================]

Anyone who has peeked at Proto's source code has probably wondered,
"Why all the dirty preprocessor gunk? Couldn't this have been all
implemented cleanly on top of libraries like MPL and Fusion?" The 
answer is that Proto could have been implemented this way, and in fact
was at one point. The problem is that template metaprogramming (TMP)
makes for very long compile times. As a foundation upon which other 
TMP-heavy libraries will be built, Proto itself should be as lightweight
as possible. That is achieved by prefering preprocessor metaprogramming
to template metaprogramming. Expanding a macro is far more efficient
than instantiating a template. In some cases, the "clean" version takes
10x longer to compile than the "dirty" version.

The "clean and slow" version of Proto can still be found at
http://svn.boost.org/svn/boost/branches/proto/v3. Anyone who is interested
can download it and verify that it is, in fact, unusably slow to compile.
Note that this branch's development was abandoned, and it does not
conform exactly with Proto's current interface.

[endsect]

[endsect]