| <html> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=US-ASCII"> |
| <title>Appendices</title> |
| <link rel="stylesheet" href="../../../doc/src/boostbook.css" type="text/css"> |
| <meta name="generator" content="DocBook XSL Stylesheets V1.75.2"> |
| <link rel="home" href="../index.html" title="The Boost C++ Libraries BoostBook Documentation Subset"> |
| <link rel="up" href="../proto.html" title="Chapter 15. Boost.Proto"> |
| <link rel="prev" href="../Transform.html" title="Concept Transform"> |
| <link rel="next" href="../boost_random.html" title="Chapter 16. Boost.Random"> |
| </head> |
| <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> |
| <table cellpadding="2" width="100%"><tr> |
| <td valign="top"><img alt="Boost C++ Libraries" width="277" height="86" src="../../../boost.png"></td> |
| <td align="center"><a href="../../../index.html">Home</a></td> |
| <td align="center"><a href="../../../libs/libraries.htm">Libraries</a></td> |
| <td align="center"><a href="http://www.boost.org/users/people.html">People</a></td> |
| <td align="center"><a href="http://www.boost.org/users/faq.html">FAQ</a></td> |
| <td align="center"><a href="../../../more/index.htm">More</a></td> |
| </tr></table> |
| <hr> |
| <div class="spirit-nav"> |
| <a accesskey="p" href="../Transform.html"><img src="../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../proto.html"><img src="../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="../boost_random.html"><img src="../../../doc/src/images/next.png" alt="Next"></a> |
| </div> |
| <div class="section"> |
| <div class="titlepage"><div><div><h2 class="title" style="clear: both"> |
| <a name="proto.appendices"></a><a class="link" href="appendices.html" title="Appendices">Appendices</a> |
| </h2></div></div></div> |
| <div class="toc"><dl> |
| <dt><span class="section"><a href="appendices.html#boost_proto.appendices.release_notes">Appendix A: Release |
| Notes</a></span></dt> |
| <dt><span class="section"><a href="appendices.html#boost_proto.appendices.history">Appendix B: History</a></span></dt> |
| <dt><span class="section"><a href="appendices.html#boost_proto.appendices.rationale">Appendix C: Rationale</a></span></dt> |
| <dt><span class="section"><a href="appendices.html#boost_proto.appendices.implementation">Appendix D: Implementation |
| Notes</a></span></dt> |
| <dt><span class="section"><a href="appendices.html#boost_proto.appendices.acknowledgements">Appendix E: |
| Acknowledgements</a></span></dt> |
| </dl></div> |
| <div class="section"> |
| <div class="titlepage"><div><div><h3 class="title"> |
| <a name="boost_proto.appendices.release_notes"></a><a class="link" href="appendices.html#boost_proto.appendices.release_notes" title="Appendix A: Release Notes">Appendix A: Release |
| Notes</a> |
| </h3></div></div></div> |
| <a name="boost_proto.appendices.release_notes.boost_1_44"></a><h5> |
| <a name="id2457953"></a> |
| <a class="link" href="appendices.html#boost_proto.appendices.release_notes.boost_1_44">Boost 1.44</a> |
| </h5> |
| <p> |
| <span class="bold"><strong>Behavior Change: proto::and_<></strong></span> |
| </p> |
| <p> |
| In Boost 1.44, the behavior of <code class="computeroutput"><a class="link" href="../boost/proto/and_.html" title="Struct template and_">proto::and_<></a></code> |
| as a transform changed. Previously, it only applied the transform associated |
| with the last grammar in the set. Now, it applies all the transforms but |
| only returns the result of the last. That makes it behave like C++'s comma |
| operator. For example, a grammar such as: |
| </p> |
| <pre class="programlisting"><span class="identifier">proto</span><span class="special">::</span><span class="identifier">and_</span><span class="special"><</span> <span class="identifier">G0</span><span class="special">,</span> <span class="identifier">G1</span><span class="special">,</span> <span class="identifier">G2</span> <span class="special">></span> |
| </pre> |
| <p> |
| when evaluated with an expression <code class="computeroutput"><span class="identifier">e</span></code> |
| now behaves like this: |
| </p> |
| <pre class="programlisting"><span class="special">(</span><span class="identifier">G0</span><span class="special">()(</span><span class="identifier">e</span><span class="special">),</span> <span class="identifier">G1</span><span class="special">()(</span><span class="identifier">e</span><span class="special">),</span> <span class="identifier">G2</span><span class="special">()(</span><span class="identifier">e</span><span class="special">))</span> |
| </pre> |
| <p> |
| <span class="bold"><strong>Behavior Change: proto::as_expr() and proto::as_child()</strong></span> |
| </p> |
| <p> |
| The functions <code class="computeroutput"><a class="link" href="../boost/proto/as_expr_id1288965.html" title="Function as_expr">proto::as_expr()</a></code> and <code class="computeroutput"><a class="link" href="../boost/proto/as_child_id1289156.html" title="Function as_child">proto::as_child()</a></code> |
| are used to guarantee that an object is a Proto expression by turning it |
| into one if it is not already, using an optionally specified domain. In previous |
| releases, when these functions were passed a Proto expression in a domain |
| different to the one specified, they would apply the specified domain's generator, |
| resulting in a twice-wrapped expression. This behavior was surprising to |
| some users. |
| </p> |
| <p> |
| The new behavior of these two functions is to always leave Proto expressions |
| alone, regardless of the expressions' domains. |
| </p> |
| <p> |
| <span class="bold"><strong>Behavior Change: proto::(pod_)generator<> and |
| proto::basic_expr<></strong></span> |
| </p> |
| <p> |
| Users familiar with Proto's extension mechanism have probably used either |
| <code class="computeroutput"><a class="link" href="../boost/proto/generator.html" title="Struct template generator">proto::generator<></a></code> or <code class="computeroutput"><a class="link" href="../boost/proto/pod_generator.html" title="Struct template pod_generator">proto::pod_generator<></a></code> |
| with a wrapper template when defining their domain. In the past, Proto would |
| instantiate your wrapper template with instances of <code class="computeroutput"><a class="link" href="../boost/proto/expr.html" title="Struct template expr">proto::expr<></a></code>. |
| In Boost 1.44, Proto now instantiates your wrapper template with instances |
| of a new type: <code class="computeroutput"><a class="link" href="../boost/proto/basic_expr.html" title="Struct template basic_expr">proto::basic_expr<></a></code>. |
| </p> |
| <p> |
| For instance: |
| </p> |
| <pre class="programlisting"><span class="comment">// An expression wrapper |
| </span><span class="keyword">template</span><span class="special"><</span><span class="keyword">class</span> <span class="identifier">Expr</span><span class="special">></span> |
| <span class="keyword">struct</span> <span class="identifier">my_expr_wrapper</span><span class="special">;</span> |
| |
| <span class="comment">// A domain |
| </span><span class="keyword">struct</span> <span class="identifier">my_domain</span> |
| <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">domain</span><span class="special"><</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">generator</span><span class="special"><</span> <span class="identifier">my_expr_wrapper</span> <span class="special">></span> <span class="special">></span> |
| <span class="special">{};</span> |
| |
| <span class="keyword">template</span><span class="special"><</span><span class="keyword">class</span> <span class="identifier">Expr</span><span class="special">></span> |
| <span class="keyword">struct</span> <span class="identifier">my_expr_wrapper</span> |
| <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">extends</span><span class="special"><</span><span class="identifier">Expr</span><span class="special">,</span> <span class="identifier">my_expr_wrapper</span><span class="special"><</span><span class="identifier">Expr</span><span class="special">>,</span> <span class="identifier">my_domain</span><span class="special">></span> |
| <span class="special">{</span> |
| <span class="comment">// Before 1.44, Expr was an instance of proto::expr<> |
| </span> <span class="comment">// In 1.44, Expr is an instance of proto::basic_expr<> |
| </span><span class="special">};</span> |
| </pre> |
| <p> |
| The motivation for this change was to improve compile times. <code class="computeroutput"><a class="link" href="../boost/proto/expr.html" title="Struct template expr">proto::expr<></a></code> |
| is an expensive type to instantiate because it defines a host of member functions. |
| When defining your own expression wrapper, the instance of <code class="computeroutput"><a class="link" href="../boost/proto/expr.html" title="Struct template expr">proto::expr<></a></code> |
| sits as a hidden data member function in your wrapper and the members of |
| <code class="computeroutput"><a class="link" href="../boost/proto/expr.html" title="Struct template expr">proto::expr<></a></code> go unused. Therefore, |
| the cost of those member functions is wasted. In contrast, <code class="computeroutput"><a class="link" href="../boost/proto/basic_expr.html" title="Struct template basic_expr">proto::basic_expr<></a></code> |
| is a very lightweight type with no member functions at all. |
| </p> |
| <p> |
| The vast majority of programs should recompile without any source changes. |
| However, if somewhere you are assuming that you will be given instances specifically |
| of <code class="computeroutput"><a class="link" href="../boost/proto/expr.html" title="Struct template expr">proto::expr<></a></code>, your code will break. |
| </p> |
| <p> |
| <span class="bold"><strong>New Feature: Sub-domains</strong></span> |
| </p> |
| <p> |
| In Boost 1.44, Proto introduces an important new feature called "sub-domains". |
| This gives you a way to spcify that one domain is compatible with another |
| such that expressions in one domain can be freely mixed with expressions |
| in another. You can define one domain to be the sub-domain of another by |
| using the third template parameter of <code class="computeroutput"><a class="link" href="../boost/proto/domain.html" title="Struct template domain">proto::domain<></a></code>. |
| </p> |
| <p> |
| For instance: |
| </p> |
| <pre class="programlisting"><span class="comment">// Not shown: define some expression |
| </span><span class="comment">// generators genA and genB |
| </span> |
| <span class="keyword">struct</span> <span class="identifier">A</span> |
| <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">domain</span><span class="special"><</span> <span class="identifier">genA</span><span class="special">,</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">_</span> <span class="special">></span> |
| <span class="special">{};</span> |
| |
| <span class="comment">// Define a domain B that is the sub-domain |
| </span><span class="comment">// of domain A. |
| </span><span class="keyword">struct</span> <span class="identifier">B</span> |
| <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">domain</span><span class="special"><</span> <span class="identifier">genB</span><span class="special">,</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">_</span><span class="special">,</span> <span class="identifier">A</span> <span class="special">></span> |
| <span class="special">{};</span> |
| </pre> |
| <p> |
| Expressions in domains <code class="computeroutput"><span class="identifier">A</span></code> |
| and <code class="computeroutput"><span class="identifier">B</span></code> can have different |
| wrappers (hence, different interfaces), but they can be combined into larger |
| expressions. Without a sub-domain relationship, this would have been an error. |
| The domain of the resulting expression in this case would be <code class="computeroutput"><span class="identifier">A</span></code>. |
| </p> |
| <p> |
| The complete description of sub-domains can be found in the reference sections |
| for <code class="computeroutput"><a class="link" href="../boost/proto/domain.html" title="Struct template domain">proto::domain<></a></code> and <code class="computeroutput"><a class="link" href="../boost/proto/deduce_domain.html" title="Struct deduce_domain">proto::deduce_domain</a></code>. |
| </p> |
| <p> |
| <span class="bold"><strong>New Feature: Domain-specific as_expr() and as_child()</strong></span> |
| </p> |
| <p> |
| Proto has always allowed users to customize expressions post-hoc by specifying |
| a Generator when defining their domain. But it has never allowed users to |
| control how Proto assembles sub-expressions in the first place. As of Boost |
| 1.44, users now have this power. |
| </p> |
| <p> |
| Users defining their own domain can now specify how <code class="computeroutput"><a class="link" href="../boost/proto/as_expr_id1288965.html" title="Function as_expr">proto::as_expr()</a></code> |
| and <code class="computeroutput"><a class="link" href="../boost/proto/as_child_id1289156.html" title="Function as_child">proto::as_child()</a></code> work in their domain. They |
| can do this easily by defining nested class templates named <code class="computeroutput"><span class="identifier">as_expr</span></code> and/or <code class="computeroutput"><span class="identifier">as_child</span></code> |
| within their domain class. |
| </p> |
| <p> |
| For example: |
| </p> |
| <pre class="programlisting"><span class="keyword">struct</span> <span class="identifier">my_domain</span> |
| <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">domain</span><span class="special"><</span> <span class="identifier">my_generator</span> <span class="special">></span> |
| <span class="special">{</span> |
| <span class="keyword">typedef</span> |
| <span class="identifier">proto</span><span class="special">::</span><span class="identifier">domain</span><span class="special"><</span> <span class="identifier">my_generator</span> <span class="special">></span> |
| <span class="identifier">base_domain</span><span class="special">;</span> |
| |
| <span class="comment">// For my_domain, as_child does the same as |
| </span> <span class="comment">// what as_expr does by default. |
| </span> <span class="keyword">template</span><span class="special"><</span><span class="keyword">class</span> <span class="identifier">T</span><span class="special">></span> |
| <span class="keyword">struct</span> <span class="identifier">as_child</span> |
| <span class="special">:</span> <span class="identifier">base_domain</span><span class="special">::</span><span class="identifier">as_expr</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span> |
| <span class="special">{};</span> |
| <span class="special">};</span> |
| </pre> |
| <p> |
| In the above example, <code class="computeroutput"><span class="identifier">my_domain</span><span class="special">::</span><span class="identifier">as_child</span><span class="special"><></span></code> simply defers to <code class="computeroutput"><span class="identifier">proto</span><span class="special">::</span><span class="identifier">domain</span><span class="special">::</span><span class="identifier">as_expr</span><span class="special"><></span></code>. This has the nice effect of causing |
| all terminals to be captured by value instead of by reference, and to likewise |
| store child expressions by value. The result is that expressions in <code class="computeroutput"><span class="identifier">my_domain</span></code> are safe to store in <code class="computeroutput"><span class="keyword">auto</span></code> variables because they will not have |
| dangling references to intermediate temporary expressions. (Naturally, it |
| also means that expression construction has extra runtime overhead of copying |
| that the compiler may or may not be able to optimize away.) |
| </p> |
| <a name="boost_proto.appendices.release_notes.boost_1_43"></a><h5> |
| <a name="id2459189"></a> |
| <a class="link" href="appendices.html#boost_proto.appendices.release_notes.boost_1_43">Boost 1.43</a> |
| </h5> |
| <p> |
| In Boost 1.43, the recommended usage of <code class="computeroutput"><a class="link" href="../boost/proto/extends.html" title="Struct template extends">proto::extends<></a></code> |
| changed slightly. The new usage looks like this: |
| </p> |
| <pre class="programlisting"><span class="comment">// my_expr is an expression extension of the Expr parameter |
| </span><span class="keyword">template</span><span class="special"><</span><span class="keyword">typename</span> <span class="identifier">Expr</span><span class="special">></span> |
| <span class="keyword">struct</span> <span class="identifier">my_expr</span> |
| <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">extends</span><span class="special"><</span><span class="identifier">Expr</span><span class="special">,</span> <span class="identifier">my_expr</span><span class="special"><</span><span class="identifier">Expr</span><span class="special">>,</span> <span class="identifier">my_domain</span><span class="special">></span> |
| <span class="special">{</span> |
| <span class="identifier">my_expr</span><span class="special">(</span><span class="identifier">Expr</span> <span class="keyword">const</span> <span class="special">&</span><span class="identifier">expr</span> <span class="special">=</span> <span class="identifier">Expr</span><span class="special">())</span> |
| <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">extends</span><span class="special"><</span><span class="identifier">Expr</span><span class="special">,</span> <span class="identifier">my_expr</span><span class="special">,</span> <span class="identifier">my_domain</span><span class="special">>(</span><span class="identifier">expr</span><span class="special">)</span> |
| <span class="special">{}</span> |
| |
| <span class="comment">// NEW: use the following macro to bring |
| </span> <span class="comment">// proto::extends::operator= into scope. |
| </span> <span class="identifier">BOOST_PROTO_EXTENDS_USING_ASSIGN</span><span class="special">(</span><span class="identifier">my_expr</span><span class="special">)</span> |
| <span class="special">};</span> |
| </pre> |
| <p> |
| The new thing is the use of the <code class="literal"><code class="computeroutput"><a class="link" href="../BOOST_PROTO_EXTENDS_USING_ASSIGN.html" title="Macro BOOST_PROTO_EXTENDS_USING_ASSIGN">BOOST_PROTO_EXTENDS_USING_ASSIGN</a></code>()</code> |
| macro. To allow assignment operators to build expression trees, <code class="computeroutput"><a class="link" href="../boost/proto/extends.html" title="Struct template extends">proto::extends<></a></code> overloads the assignment |
| operator. However, for the <code class="computeroutput"><span class="identifier">my_expr</span></code> |
| template, the compiler generates a default copy assignment operator that |
| hides the ones in <code class="computeroutput"><a class="link" href="../boost/proto/extends.html" title="Struct template extends">proto::extends<></a></code>. This is often not desired |
| (although it depends on the syntax you want to allow). |
| </p> |
| <p> |
| Previously, the recommended usage was to do this: |
| </p> |
| <pre class="programlisting"><span class="comment">// my_expr is an expression extension of the Expr parameter |
| </span><span class="keyword">template</span><span class="special"><</span><span class="keyword">typename</span> <span class="identifier">Expr</span><span class="special">></span> |
| <span class="keyword">struct</span> <span class="identifier">my_expr</span> |
| <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">extends</span><span class="special"><</span><span class="identifier">Expr</span><span class="special">,</span> <span class="identifier">my_expr</span><span class="special"><</span><span class="identifier">Expr</span><span class="special">>,</span> <span class="identifier">my_domain</span><span class="special">></span> |
| <span class="special">{</span> |
| <span class="identifier">my_expr</span><span class="special">(</span><span class="identifier">Expr</span> <span class="keyword">const</span> <span class="special">&</span><span class="identifier">expr</span> <span class="special">=</span> <span class="identifier">Expr</span><span class="special">())</span> |
| <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">extends</span><span class="special"><</span><span class="identifier">Expr</span><span class="special">,</span> <span class="identifier">my_expr</span><span class="special">,</span> <span class="identifier">my_domain</span><span class="special">>(</span><span class="identifier">expr</span><span class="special">)</span> |
| <span class="special">{}</span> |
| |
| <span class="comment">// OLD: don't do it like this anymore. |
| </span> <span class="keyword">using</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">extends</span><span class="special"><</span><span class="identifier">Expr</span><span class="special">,</span> <span class="identifier">my_expr</span><span class="special">,</span> <span class="identifier">my_domain</span><span class="special">>::</span><span class="keyword">operator</span><span class="special">=;</span> |
| <span class="special">};</span> |
| </pre> |
| <p> |
| While this works in the majority of cases, it still doesn't suppress the |
| implicit generation of the default assignment operator. As a result, expressions |
| of the form <code class="computeroutput"><span class="identifier">a</span> <span class="special">=</span> |
| <span class="identifier">b</span></code> could either build an expression |
| template or do a copy assignment depending on whether the types of <code class="computeroutput"><span class="identifier">a</span></code> and <code class="computeroutput"><span class="identifier">b</span></code> |
| happen to be the same. That can lead to subtle bugs, so the behavior was |
| changed. |
| </p> |
| <p> |
| The <code class="literal"><code class="computeroutput"><a class="link" href="../BOOST_PROTO_EXTENDS_USING_ASSIGN.html" title="Macro BOOST_PROTO_EXTENDS_USING_ASSIGN">BOOST_PROTO_EXTENDS_USING_ASSIGN</a></code>()</code> |
| brings into scope the assignment operators defined in <code class="computeroutput"><a class="link" href="../boost/proto/extends.html" title="Struct template extends">proto::extends<></a></code> |
| as well as suppresses the generation of the copy assignment operator. |
| </p> |
| <p> |
| Also note that the <code class="computeroutput"><a class="link" href="../boost/proto/literal.html" title="Struct template literal">proto::literal<></a></code> class template, which |
| uses <code class="computeroutput"><a class="link" href="../boost/proto/extends.html" title="Struct template extends">proto::extends<></a></code>, has been chaged to use |
| <code class="literal"><code class="computeroutput"><a class="link" href="../BOOST_PROTO_EXTENDS_USING_ASSIGN.html" title="Macro BOOST_PROTO_EXTENDS_USING_ASSIGN">BOOST_PROTO_EXTENDS_USING_ASSIGN</a></code>()</code>. |
| The implications are highlighted in the sample code below: |
| </p> |
| <pre class="programlisting"><span class="identifier">proto</span><span class="special">::</span><span class="identifier">literal</span><span class="special"><</span><span class="keyword">int</span><span class="special">></span> <span class="identifier">a</span><span class="special">(</span><span class="number">1</span><span class="special">),</span> <span class="identifier">b</span><span class="special">(</span><span class="number">2</span><span class="special">);</span> <span class="comment">// two non-const proto literals |
| </span><span class="identifier">proto</span><span class="special">::</span><span class="identifier">literal</span><span class="special"><</span><span class="keyword">int</span><span class="special">></span> <span class="keyword">const</span> <span class="identifier">c</span><span class="special">(</span><span class="number">3</span><span class="special">);</span> <span class="comment">// a const proto literal |
| </span> |
| <span class="identifier">a</span> <span class="special">=</span> <span class="identifier">b</span><span class="special">;</span> <span class="comment">// No-op. Builds an expression tree and discards it. |
| </span> <span class="comment">// Same behavior in 1.42 and 1.43. |
| </span> |
| <span class="identifier">a</span> <span class="special">=</span> <span class="identifier">c</span><span class="special">;</span> <span class="comment">// CHANGE! In 1.42, this performed copy assignment, causing |
| </span> <span class="comment">// a's value to change to 3. In 1.43, the behavior is now |
| </span> <span class="comment">// the same as above: build and discard an expression tree. |
| </span></pre> |
| </div> |
| <div class="section"> |
| <div class="titlepage"><div><div><h3 class="title"> |
| <a name="boost_proto.appendices.history"></a><a class="link" href="appendices.html#boost_proto.appendices.history" title="Appendix B: History">Appendix B: History</a> |
| </h3></div></div></div> |
| <div class="variablelist"> |
| <p class="title"><b></b></p> |
| <dl> |
| <dt><span class="term">August ??, 2010</span></dt> |
| <dd><p> |
| Boost 1.44: Proto gets sub-domains and per-domain control of <code class="computeroutput"><a class="link" href="../boost/proto/as_expr_id1288965.html" title="Function as_expr">proto::as_expr()</a></code> and <code class="computeroutput"><a class="link" href="../boost/proto/as_child_id1289156.html" title="Function as_child">proto::as_child()</a></code> to meet the needs |
| of Phoenix3. |
| </p></dd> |
| <dt><span class="term">August 11, 2008</span></dt> |
| <dd><p> |
| Proto v4 is merged to Boost trunk with more powerful transform protocol. |
| </p></dd> |
| <dt><span class="term">April 7, 2008</span></dt> |
| <dd><p> |
| Proto is accepted into Boost. |
| </p></dd> |
| <dt><span class="term">March 1, 2008</span></dt> |
| <dd><p> |
| Proto's Boost review begins. |
| </p></dd> |
| <dt><span class="term">January 11, 2008</span></dt> |
| <dd><p> |
| Boost.Proto v3 brings separation of grammars and transforms and a "round" |
| lambda syntax for defining transforms in-place. |
| </p></dd> |
| <dt><span class="term">April 15, 2007</span></dt> |
| <dd><p> |
| Boost.Xpressive is ported from Proto compilers to Proto transforms. |
| Support for old Proto compilers is dropped. |
| </p></dd> |
| <dt><span class="term">April 4, 2007</span></dt> |
| <dd><p> |
| Preliminary submission of Proto to Boost. |
| </p></dd> |
| <dt><span class="term">December 11, 2006</span></dt> |
| <dd><p> |
| The idea for transforms that decorate grammar rules is born in a private |
| email discussion with Joel de Guzman and Hartmut Kaiser. The first |
| transforms are committed to CVS 5 days later on December 16. |
| </p></dd> |
| <dt><span class="term">November 1, 2006</span></dt> |
| <dd><p> |
| The idea for <code class="computeroutput"><span class="identifier">proto</span><span class="special">::</span><span class="identifier">matches</span><span class="special"><></span></code> and the whole grammar facility |
| is hatched during a discussion with Hartmut Kaiser on the spirit-devel |
| list. The first version of <code class="computeroutput"><span class="identifier">proto</span><span class="special">::</span><span class="identifier">matches</span><span class="special"><></span></code> is checked into CVS 3 days |
| later. Message is <a href="http://osdir.com/ml/parsers.spirit.devel/2006-11/msg00003.html" target="_top">here</a>. |
| </p></dd> |
| <dt><span class="term">October 28, 2006</span></dt> |
| <dd><p> |
| Proto is reborn, this time with a uniform expression types that are |
| POD. Announcement is <a href="http://lists.boost.org/Archives/boost/2006/10/112453.php" target="_top">here</a>. |
| </p></dd> |
| <dt><span class="term">April 20, 2005</span></dt> |
| <dd><p> |
| Proto is born as a major refactorization of Boost.Xpressive's meta-programming. |
| Proto offers expression types, operator overloads and "compilers", |
| an early formulation of what later became transforms. Announcement |
| is <a href="http://lists.boost.org/Archives/boost/2005/04/85256.php" target="_top">here</a>. |
| </p></dd> |
| </dl> |
| </div> |
| </div> |
| <div class="section"> |
| <div class="titlepage"><div><div><h3 class="title"> |
| <a name="boost_proto.appendices.rationale"></a><a class="link" href="appendices.html#boost_proto.appendices.rationale" title="Appendix C: Rationale">Appendix C: Rationale</a> |
| </h3></div></div></div> |
| <div class="toc"><dl> |
| <dt><span class="section"><a href="appendices.html#boost_proto.appendices.rationale.static_initialization">Static |
| Initialization</a></span></dt> |
| <dt><span class="section"><a href="appendices.html#boost_proto.appendices.rationale.preprocessor">Why |
| Not Reuse MPL, Fusion, et cetera?</a></span></dt> |
| </dl></div> |
| <div class="section"> |
| <div class="titlepage"><div><div><h4 class="title"> |
| <a name="boost_proto.appendices.rationale.static_initialization"></a><a class="link" href="appendices.html#boost_proto.appendices.rationale.static_initialization" title="Static Initialization">Static |
| Initialization</a> |
| </h4></div></div></div> |
| <p> |
| Proto expression types are PODs (Plain Old Data), and do not have constructors. |
| They are brace-initialized, as follows: |
| </p> |
| <pre class="programlisting"><span class="identifier">terminal</span><span class="special"><</span><span class="keyword">int</span><span class="special">>::</span><span class="identifier">type</span> <span class="keyword">const</span> <span class="identifier">_i</span> <span class="special">=</span> <span class="special">{</span><span class="number">1</span><span class="special">};</span> |
| </pre> |
| <p> |
| The reason is so that expression objects like <code class="computeroutput"><span class="identifier">_i</span></code> |
| above can be <span class="emphasis"><em>statically initialized</em></span>. Why is static |
| initialization important? The terminals of many domain- specific embedded |
| languages are likely to be global const objects, like <code class="computeroutput"><span class="identifier">_1</span></code> |
| and <code class="computeroutput"><span class="identifier">_2</span></code> 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. |
| </p> |
| </div> |
| <div class="section"> |
| <div class="titlepage"><div><div><h4 class="title"> |
| <a name="boost_proto.appendices.rationale.preprocessor"></a><a class="link" href="appendices.html#boost_proto.appendices.rationale.preprocessor" title="Why Not Reuse MPL, Fusion, et cetera?">Why |
| Not Reuse MPL, Fusion, et cetera?</a> |
| </h4></div></div></div> |
| <p> |
| 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 longer 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| </div> |
| </div> |
| <div class="section"> |
| <div class="titlepage"><div><div><h3 class="title"> |
| <a name="boost_proto.appendices.implementation"></a><a class="link" href="appendices.html#boost_proto.appendices.implementation" title="Appendix D: Implementation Notes">Appendix D: Implementation |
| Notes</a> |
| </h3></div></div></div> |
| <div class="toc"><dl> |
| <dt><span class="section"><a href="appendices.html#boost_proto.appendices.implementation.sfinae">Quick-n-Dirty |
| Type Categorization</a></span></dt> |
| <dt><span class="section"><a href="appendices.html#boost_proto.appendices.implementation.function_arity">Detecting |
| the Arity of Function Objects</a></span></dt> |
| </dl></div> |
| <div class="section"> |
| <div class="titlepage"><div><div><h4 class="title"> |
| <a name="boost_proto.appendices.implementation.sfinae"></a><a class="link" href="appendices.html#boost_proto.appendices.implementation.sfinae" title="Quick-n-Dirty Type Categorization">Quick-n-Dirty |
| Type Categorization</a> |
| </h4></div></div></div> |
| <p> |
| Much has already been written about dispatching on type traits using SFINAE |
| (Substitution Failure Is Not An Error) techniques in C++. There is a Boost |
| library, Boost.Enable_if, to make the technique idiomatic. Proto dispatches |
| on type traits extensively, but it doesn't use <code class="computeroutput"><span class="identifier">enable_if</span><span class="special"><></span></code> very often. Rather, it dispatches |
| based on the presence or absence of nested types, often typedefs for void. |
| </p> |
| <p> |
| Consider the implementation of <code class="computeroutput"><span class="identifier">is_expr</span><span class="special"><></span></code>. It could have been written as |
| something like this: |
| </p> |
| <pre class="programlisting"><span class="keyword">template</span><span class="special"><</span><span class="keyword">typename</span> <span class="identifier">T</span><span class="special">></span> |
| <span class="keyword">struct</span> <span class="identifier">is_expr</span> |
| <span class="special">:</span> <span class="identifier">is_base_and_derived</span><span class="special"><</span><span class="identifier">proto</span><span class="special">::</span><span class="identifier">some_expr_base</span><span class="special">,</span> <span class="identifier">T</span><span class="special">></span> |
| <span class="special">{};</span> |
| </pre> |
| <p> |
| Rather, it is implemented as this: |
| </p> |
| <pre class="programlisting"><span class="keyword">template</span><span class="special"><</span><span class="keyword">typename</span> <span class="identifier">T</span><span class="special">,</span> <span class="keyword">typename</span> <span class="identifier">Void</span> <span class="special">=</span> <span class="keyword">void</span><span class="special">></span> |
| <span class="keyword">struct</span> <span class="identifier">is_expr</span> |
| <span class="special">:</span> <span class="identifier">mpl</span><span class="special">::</span><span class="identifier">false_</span> |
| <span class="special">{};</span> |
| |
| <span class="keyword">template</span><span class="special"><</span><span class="keyword">typename</span> <span class="identifier">T</span><span class="special">></span> |
| <span class="keyword">struct</span> <span class="identifier">is_expr</span><span class="special"><</span><span class="identifier">T</span><span class="special">,</span> <span class="keyword">typename</span> <span class="identifier">T</span><span class="special">::</span><span class="identifier">proto_is_expr_</span><span class="special">></span> |
| <span class="special">:</span> <span class="identifier">mpl</span><span class="special">::</span><span class="identifier">true_</span> |
| <span class="special">{};</span> |
| </pre> |
| <p> |
| This relies on the fact that the specialization will be preferred if <code class="computeroutput"><span class="identifier">T</span></code> has a nested <code class="computeroutput"><span class="identifier">proto_is_expr_</span></code> |
| that is a typedef for <code class="computeroutput"><span class="keyword">void</span></code>. |
| All Proto expression types have such a nested typedef. |
| </p> |
| <p> |
| Why does Proto do it this way? The reason is because, after running extensive |
| benchmarks while trying to improve compile times, I have found that this |
| approach compiles faster. It requires exactly one template instantiation. |
| The other approach requires at least 2: <code class="computeroutput"><span class="identifier">is_expr</span><span class="special"><></span></code> and <code class="computeroutput"><span class="identifier">is_base_and_derived</span><span class="special"><></span></code>, plus whatever templates <code class="computeroutput"><span class="identifier">is_base_and_derived</span><span class="special"><></span></code> |
| may instantiate. |
| </p> |
| </div> |
| <div class="section"> |
| <div class="titlepage"><div><div><h4 class="title"> |
| <a name="boost_proto.appendices.implementation.function_arity"></a><a class="link" href="appendices.html#boost_proto.appendices.implementation.function_arity" title="Detecting the Arity of Function Objects">Detecting |
| the Arity of Function Objects</a> |
| </h4></div></div></div> |
| <p> |
| In several places, Proto needs to know whether or not a function object |
| <code class="computeroutput"><span class="identifier">Fun</span></code> can be called with |
| certain parameters and take a fallback action if not. This happens in |
| <code class="computeroutput"><a class="link" href="../boost/proto/context/callable_context.html" title="Struct template callable_context">proto::callable_context<></a></code> |
| and in the <code class="computeroutput"><a class="link" href="../boost/proto/call.html" title="Struct template call">proto::call<></a></code> transform. How does |
| Proto know? It involves some tricky metaprogramming. Here's how. |
| </p> |
| <p> |
| Another way of framing the question is by trying to implement the following |
| <code class="computeroutput"><span class="identifier">can_be_called</span><span class="special"><></span></code> |
| Boolean metafunction, which checks to see if a function object <code class="computeroutput"><span class="identifier">Fun</span></code> can be called with parameters of |
| type <code class="computeroutput"><span class="identifier">A</span></code> and <code class="computeroutput"><span class="identifier">B</span></code>: |
| </p> |
| <pre class="programlisting"><span class="keyword">template</span><span class="special"><</span><span class="keyword">typename</span> <span class="identifier">Fun</span><span class="special">,</span> <span class="keyword">typename</span> <span class="identifier">A</span><span class="special">,</span> <span class="keyword">typename</span> <span class="identifier">B</span><span class="special">></span> |
| <span class="keyword">struct</span> <span class="identifier">can_be_called</span><span class="special">;</span> |
| </pre> |
| <p> |
| First, we define the following <code class="computeroutput"><span class="identifier">dont_care</span></code> |
| struct, which has an implicit conversion from anything. And not just any |
| implicit conversion; it has a ellipsis conversion, which is the worst possible |
| conversion for the purposes of overload resolution: |
| </p> |
| <pre class="programlisting"><span class="keyword">struct</span> <span class="identifier">dont_care</span> |
| <span class="special">{</span> |
| <span class="identifier">dont_care</span><span class="special">(...);</span> |
| <span class="special">};</span> |
| </pre> |
| <p> |
| We also need some private type known only to us with an overloaded comma |
| operator (!), and some functions that detect the presence of this type |
| and return types with different sizes, as follows: |
| </p> |
| <pre class="programlisting"><span class="keyword">struct</span> <span class="identifier">private_type</span> |
| <span class="special">{</span> |
| <span class="identifier">private_type</span> <span class="keyword">const</span> <span class="special">&</span><span class="keyword">operator</span><span class="special">,(</span><span class="keyword">int</span><span class="special">)</span> <span class="keyword">const</span><span class="special">;</span> |
| <span class="special">};</span> |
| |
| <span class="keyword">typedef</span> <span class="keyword">char</span> <span class="identifier">yes_type</span><span class="special">;</span> <span class="comment">// sizeof(yes_type) == 1 |
| </span><span class="keyword">typedef</span> <span class="keyword">char</span> <span class="special">(&</span><span class="identifier">no_type</span><span class="special">)[</span><span class="number">2</span><span class="special">];</span> <span class="comment">// sizeof(no_type) == 2 |
| </span> |
| <span class="keyword">template</span><span class="special"><</span><span class="keyword">typename</span> <span class="identifier">T</span><span class="special">></span> |
| <span class="identifier">no_type</span> <span class="identifier">is_private_type</span><span class="special">(</span><span class="identifier">T</span> <span class="keyword">const</span> <span class="special">&);</span> |
| |
| <span class="identifier">yes_type</span> <span class="identifier">is_private_type</span><span class="special">(</span><span class="identifier">private_type</span> <span class="keyword">const</span> <span class="special">&);</span> |
| </pre> |
| <p> |
| Next, we implement a binary function object wrapper with a very strange |
| conversion operator, whose meaning will become clear later. |
| </p> |
| <pre class="programlisting"><span class="keyword">template</span><span class="special"><</span><span class="keyword">typename</span> <span class="identifier">Fun</span><span class="special">></span> |
| <span class="keyword">struct</span> <span class="identifier">funwrap2</span> <span class="special">:</span> <span class="identifier">Fun</span> |
| <span class="special">{</span> |
| <span class="identifier">funwrap2</span><span class="special">();</span> |
| <span class="keyword">typedef</span> <span class="identifier">private_type</span> <span class="keyword">const</span> <span class="special">&(*</span><span class="identifier">pointer_to_function</span><span class="special">)(</span><span class="identifier">dont_care</span><span class="special">,</span> <span class="identifier">dont_care</span><span class="special">);</span> |
| <span class="keyword">operator</span> <span class="identifier">pointer_to_function</span><span class="special">()</span> <span class="keyword">const</span><span class="special">;</span> |
| <span class="special">};</span> |
| </pre> |
| <p> |
| With all of these bits and pieces, we can implement <code class="computeroutput"><span class="identifier">can_be_called</span><span class="special"><></span></code> as follows: |
| </p> |
| <pre class="programlisting"><span class="keyword">template</span><span class="special"><</span><span class="keyword">typename</span> <span class="identifier">Fun</span><span class="special">,</span> <span class="keyword">typename</span> <span class="identifier">A</span><span class="special">,</span> <span class="keyword">typename</span> <span class="identifier">B</span><span class="special">></span> |
| <span class="keyword">struct</span> <span class="identifier">can_be_called</span> |
| <span class="special">{</span> |
| <span class="keyword">static</span> <span class="identifier">funwrap2</span><span class="special"><</span><span class="identifier">Fun</span><span class="special">></span> <span class="special">&</span><span class="identifier">fun</span><span class="special">;</span> |
| <span class="keyword">static</span> <span class="identifier">A</span> <span class="special">&</span><span class="identifier">a</span><span class="special">;</span> |
| <span class="keyword">static</span> <span class="identifier">B</span> <span class="special">&</span><span class="identifier">b</span><span class="special">;</span> |
| |
| <span class="keyword">static</span> <span class="keyword">bool</span> <span class="keyword">const</span> <span class="identifier">value</span> <span class="special">=</span> <span class="special">(</span> |
| <span class="keyword">sizeof</span><span class="special">(</span><span class="identifier">no_type</span><span class="special">)</span> <span class="special">==</span> <span class="keyword">sizeof</span><span class="special">(</span><span class="identifier">is_private_type</span><span class="special">(</span> <span class="special">(</span><span class="identifier">fun</span><span class="special">(</span><span class="identifier">a</span><span class="special">,</span><span class="identifier">b</span><span class="special">),</span> <span class="number">0</span><span class="special">)</span> <span class="special">))</span> |
| <span class="special">);</span> |
| |
| <span class="keyword">typedef</span> <span class="identifier">mpl</span><span class="special">::</span><span class="identifier">bool_</span><span class="special"><</span><span class="identifier">value</span><span class="special">></span> <span class="identifier">type</span><span class="special">;</span> |
| <span class="special">};</span> |
| </pre> |
| <p> |
| The idea is to make it so that <code class="computeroutput"><span class="identifier">fun</span><span class="special">(</span><span class="identifier">a</span><span class="special">,</span><span class="identifier">b</span><span class="special">)</span></code> will |
| always compile by adding our own binary function overload, but doing it |
| in such a way that we can detect whether our overload was selected or not. |
| And we rig it so that our overload is selected if there is really no better |
| option. What follows is a description of how <code class="computeroutput"><span class="identifier">can_be_called</span><span class="special"><></span></code> works. |
| </p> |
| <p> |
| We wrap <code class="computeroutput"><span class="identifier">Fun</span></code> in a type that |
| has an implicit conversion to a pointer to a binary function. An object |
| <code class="computeroutput"><span class="identifier">fun</span></code> of class type can be |
| invoked as <code class="computeroutput"><span class="identifier">fun</span><span class="special">(</span><span class="identifier">a</span><span class="special">,</span> <span class="identifier">b</span><span class="special">)</span></code> if it has such a conversion operator, |
| but since it involves a user-defined conversion operator, it is less preferred |
| than an overloaded <code class="computeroutput"><span class="keyword">operator</span><span class="special">()</span></code>, which requires no such conversion. |
| </p> |
| <p> |
| The function pointer can accept any two arguments by virtue of the <code class="computeroutput"><span class="identifier">dont_care</span></code> type. The conversion sequence |
| for each argument is guaranteed to be the worst possible conversion sequence: |
| an implicit conversion through an ellipsis, and a user-defined conversion |
| to <code class="computeroutput"><span class="identifier">dont_care</span></code>. In total, |
| it means that <code class="computeroutput"><span class="identifier">funwrap2</span><span class="special"><</span><span class="identifier">Fun</span><span class="special">>()(</span><span class="identifier">a</span><span class="special">,</span> <span class="identifier">b</span><span class="special">)</span></code> |
| will always compile, but it will select our overload only if there really |
| is no better option. |
| </p> |
| <p> |
| If there is a better option --- for example if <code class="computeroutput"><span class="identifier">Fun</span></code> |
| has an overloaded function call operator such as <code class="computeroutput"><span class="keyword">void</span> |
| <span class="keyword">operator</span><span class="special">()(</span><span class="identifier">A</span> <span class="identifier">a</span><span class="special">,</span> <span class="identifier">B</span> <span class="identifier">b</span><span class="special">)</span></code> --- |
| then <code class="computeroutput"><span class="identifier">fun</span><span class="special">(</span><span class="identifier">a</span><span class="special">,</span> <span class="identifier">b</span><span class="special">)</span></code> will resolve to that one instead. The |
| question now is how to detect which function got picked by overload resolution. |
| </p> |
| <p> |
| Notice how <code class="computeroutput"><span class="identifier">fun</span><span class="special">(</span><span class="identifier">a</span><span class="special">,</span> <span class="identifier">b</span><span class="special">)</span></code> appears in <code class="computeroutput"><span class="identifier">can_be_called</span><span class="special"><></span></code>: <code class="computeroutput"><span class="special">(</span><span class="identifier">fun</span><span class="special">(</span><span class="identifier">a</span><span class="special">,</span> <span class="identifier">b</span><span class="special">),</span> <span class="number">0</span><span class="special">)</span></code>. |
| Why do we use the comma operator there? The reason is because we are using |
| this expression as the argument to a function. If the return type of <code class="computeroutput"><span class="identifier">fun</span><span class="special">(</span><span class="identifier">a</span><span class="special">,</span> <span class="identifier">b</span><span class="special">)</span></code> is <code class="computeroutput"><span class="keyword">void</span></code>, |
| it cannot legally be used as an argument to a function. The comma operator |
| sidesteps the issue. |
| </p> |
| <p> |
| This should also make plain the purpose of the overloaded comma operator |
| in <code class="computeroutput"><span class="identifier">private_type</span></code>. The return |
| type of the pointer to function is <code class="computeroutput"><span class="identifier">private_type</span></code>. |
| If overload resolution selects our overload, then the type of <code class="computeroutput"><span class="special">(</span><span class="identifier">fun</span><span class="special">(</span><span class="identifier">a</span><span class="special">,</span> |
| <span class="identifier">b</span><span class="special">),</span> |
| <span class="number">0</span><span class="special">)</span></code> |
| is <code class="computeroutput"><span class="identifier">private_type</span></code>. Otherwise, |
| it is <code class="computeroutput"><span class="keyword">int</span></code>. That fact is used |
| to dispatch to either overload of <code class="computeroutput"><span class="identifier">is_private_type</span><span class="special">()</span></code>, which encodes its answer in the size |
| of its return type. |
| </p> |
| <p> |
| That's how it works with binary functions. Now repeat the above process |
| for functions up to some predefined function arity, and you're done. |
| </p> |
| </div> |
| </div> |
| <div class="section"> |
| <div class="titlepage"><div><div><h3 class="title"> |
| <a name="boost_proto.appendices.acknowledgements"></a><a class="link" href="appendices.html#boost_proto.appendices.acknowledgements" title="Appendix E: Acknowledgements">Appendix E: |
| Acknowledgements</a> |
| </h3></div></div></div> |
| <p> |
| I'd like to thank Joel de Guzman and Hartmut Kaiser for being willing to |
| take a chance on using Proto for their work on Spirit-2 and Karma when Proto |
| was little more than a vision. Their requirements and feedback have been |
| indespensable. |
| </p> |
| <p> |
| Thanks to Daniel James for providing a patch to remove the dependence on |
| deprecated configuration macros for C++0x features. |
| </p> |
| <p> |
| Thanks to Dave Abrahams for an especially detailed review, and for making |
| a VM with msvc-7.1 available so I could track down portability issues on |
| that compiler. |
| </p> |
| <p> |
| Many thanks to Daniel Wallin who first implemented the code used to find |
| the common domain among a set, accounting for super- and sub-domains. Thanks |
| also to Jeremiah Willcock, John Bytheway and Krishna Achuthan who offered |
| alternate solutions to this tricky programming problem. |
| </p> |
| <p> |
| Thanks also to the developers of <a href="http://www.codesourcery.com/pooma/download.html" target="_top">PETE</a>. |
| I found many good ideas there. |
| </p> |
| </div> |
| </div> |
| <table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr> |
| <td align="left"></td> |
| <td align="right"><div class="copyright-footer">Copyright © 2008 Eric Niebler<p> |
| Distributed under the Boost Software License, Version 1.0. (See accompanying |
| file LICENSE_1_0.txt or copy at <a href="http://www.boost.org/LICENSE_1_0.txt" target="_top">http://www.boost.org/LICENSE_1_0.txt</a>) |
| </p> |
| </div></td> |
| </tr></table> |
| <hr> |
| <div class="spirit-nav"> |
| <a accesskey="p" href="../Transform.html"><img src="../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../proto.html"><img src="../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="../boost_random.html"><img src="../../../doc/src/images/next.png" alt="Next"></a> |
| </div> |
| </body> |
| </html> |
