doc/html/proto/appendices.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
   2 <html>
   3 <head>
   4 <meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
   5 <title>Appendices</title>
   6 <link rel="stylesheet" href="../../../doc/src/boostbook.css" type="text/css">
   7 <meta name="generator" content="DocBook XSL Stylesheets V1.79.1">
   8 <link rel="home" href="../index.html" title="The Boost C++ Libraries BoostBook Documentation Subset">
   9 <link rel="up" href="../proto.html" title="Chapter&#160;32.&#160;Boost.Proto">
  10 <link rel="prev" href="../Transform.html" title="Concept Transform">
  11 <link rel="next" href="../boost_random.html" title="Chapter&#160;33.&#160;Boost.Random">
  12 </head>
  13 <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
  14 <table cellpadding="2" width="100%"><tr>
  15 <td valign="top"><img alt="Boost C++ Libraries" width="277" height="86" src="../../../boost.png"></td>
  16 <td align="center"><a href="../../../index.html">Home</a></td>
  17 <td align="center"><a href="../../../libs/libraries.htm">Libraries</a></td>
  18 <td align="center"><a href="http://www.boost.org/users/people.html">People</a></td>
  19 <td align="center"><a href="http://www.boost.org/users/faq.html">FAQ</a></td>
  20 <td align="center"><a href="../../../more/index.htm">More</a></td>
  21 </tr></table>
  22 <hr>
  23 <div class="spirit-nav">
  24 <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>
  25 </div>
  26 <div class="section">
  27 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
  28 <a name="proto.appendices"></a><a class="link" href="appendices.html" title="Appendices">Appendices</a>
  29 </h2></div></div></div>
  30 <div class="toc"><dl class="toc">
  31 <dt><span class="section"><a href="appendices.html#boost_proto.appendices.release_notes">Appendix A: Release
  32       Notes</a></span></dt>
  33 <dt><span class="section"><a href="appendices.html#boost_proto.appendices.history">Appendix B: History</a></span></dt>
  34 <dt><span class="section"><a href="appendices.html#boost_proto.appendices.rationale">Appendix C: Rationale</a></span></dt>
  35 <dt><span class="section"><a href="appendices.html#boost_proto.appendices.implementation">Appendix D: Implementation
  36       Notes</a></span></dt>
  37 <dt><span class="section"><a href="appendices.html#boost_proto.appendices.acknowledgements">Appendix E:
  38       Acknowledgements</a></span></dt>
  39 </dl></div>
  40 <div class="section">
  41 <div class="titlepage"><div><div><h3 class="title">
  42 <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
  43       Notes</a>
  44 </h3></div></div></div>
  45 <h5>
  46 <a name="boost_proto.appendices.release_notes.h0"></a>
  47         <span class="phrase"><a name="boost_proto.appendices.release_notes.boost_1_51"></a></span><a class="link" href="appendices.html#boost_proto.appendices.release_notes.boost_1_51">Boost
  48         1.51</a>
  49       </h5>
  50 <p>
  51         <span class="bold"><strong>Unpacking Expressions</strong></span>
  52       </p>
  53 <p>
  54         In Boost 1.51, Proto got simple unpacking patterns. When working with Proto
  55         transforms, unpacking expressions are useful for unpacking the children of
  56         an expression into a function call or an object constructor, while optionally
  57         applying some transformations to each child in turn.
  58       </p>
  59 <p>
  60         See the <a class="link" href="users_guide.html#boost_proto.users_guide.back_end.expression_transformation.unpacking_expressions" title="Unpacking Expressions">Unpacking
  61         Expressions</a> section for more information.
  62       </p>
  63 <h5>
  64 <a name="boost_proto.appendices.release_notes.h1"></a>
  65         <span class="phrase"><a name="boost_proto.appendices.release_notes.boost_1_44"></a></span><a class="link" href="appendices.html#boost_proto.appendices.release_notes.boost_1_44">Boost
  66         1.44</a>
  67       </h5>
  68 <p>
  69         <span class="bold"><strong>Behavior Change: proto::and_&lt;&gt;</strong></span>
  70       </p>
  71 <p>
  72         In Boost 1.44, the behavior of <code class="computeroutput"><a class="link" href="../boost/proto/and_.html" title="Struct template and_">proto::and_&lt;&gt;</a></code>
  73         as a transform changed. Previously, it only applied the transform associated
  74         with the last grammar in the set. Now, it applies all the transforms but
  75         only returns the result of the last. That makes it behave like C++'s comma
  76         operator. For example, a grammar such as:
  77       </p>
  78 <pre class="programlisting"><span class="identifier">proto</span><span class="special">::</span><span class="identifier">and_</span><span class="special">&lt;</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">&gt;</span>
  79 </pre>
  80 <p>
  81         when evaluated with an expression <code class="computeroutput"><span class="identifier">e</span></code>
  82         now behaves like this:
  83       </p>
  84 <pre class="programlisting"><span class="special">((</span><span class="keyword">void</span><span class="special">)</span><span class="identifier">G0</span><span class="special">()(</span><span class="identifier">e</span><span class="special">),</span> <span class="special">(</span><span class="keyword">void</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>
  85 </pre>
  86 <div class="note"><table border="0" summary="Note">
  87 <tr>
  88 <td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="../../../doc/src/images/note.png"></td>
  89 <th align="left">Note</th>
  90 </tr>
  91 <tr><td align="left" valign="top"><p>
  92           Why the void casts? It's to avoid argument-dependent lookup, which might
  93           find an overloaded comma operator.
  94         </p></td></tr>
  95 </table></div>
  96 <p>
  97         <span class="bold"><strong>Behavior Change: proto::as_expr() and proto::as_child()</strong></span>
  98       </p>
  99 <p>
 100         The functions <code class="computeroutput"><a class="link" href="../boost/proto/as_expr_idp704425472.html" title="Function as_expr">proto::as_expr()</a></code> and <code class="computeroutput"><a class="link" href="../boost/proto/as_child_idp704447440.html" title="Function as_child">proto::as_child()</a></code>
 101         are used to guarantee that an object is a Proto expression by turning it
 102         into one if it is not already, using an optionally specified domain. In previous
 103         releases, when these functions were passed a Proto expression in a domain
 104         different to the one specified, they would apply the specified domain's generator,
 105         resulting in a twice-wrapped expression. This behavior was surprising to
 106         some users.
 107       </p>
 108 <p>
 109         The new behavior of these two functions is to always leave Proto expressions
 110         alone, regardless of the expressions' domains.
 111       </p>
 112 <p>
 113         <span class="bold"><strong>Behavior Change: proto::(pod_)generator&lt;&gt; and
 114         proto::basic_expr&lt;&gt;</strong></span>
 115       </p>
 116 <p>
 117         Users familiar with Proto's extension mechanism have probably used either
 118         <code class="computeroutput"><a class="link" href="../boost/proto/generator.html" title="Struct template generator">proto::generator&lt;&gt;</a></code> or <code class="computeroutput"><a class="link" href="../boost/proto/pod_generator.html" title="Struct template pod_generator">proto::pod_generator&lt;&gt;</a></code>
 119         with a wrapper template when defining their domain. In the past, Proto would
 120         instantiate your wrapper template with instances of <code class="computeroutput"><a class="link" href="../boost/proto/expr.html" title="Struct template expr">proto::expr&lt;&gt;</a></code>.
 121         In Boost 1.44, Proto now instantiates your wrapper template with instances
 122         of a new type: <code class="computeroutput"><a class="link" href="../boost/proto/basic_expr.html" title="Struct template basic_expr">proto::basic_expr&lt;&gt;</a></code>.
 123       </p>
 124 <p>
 125         For instance:
 126       </p>
 127 <pre class="programlisting"><span class="comment">// An expression wrapper</span>
 128 <span class="keyword">template</span><span class="special">&lt;</span><span class="keyword">class</span> <span class="identifier">Expr</span><span class="special">&gt;</span>
 129 <span class="keyword">struct</span> <span class="identifier">my_expr_wrapper</span><span class="special">;</span>
 130
 131 <span class="comment">// A domain</span>
 132 <span class="keyword">struct</span> <span class="identifier">my_domain</span>
 133   <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">domain</span><span class="special">&lt;</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">generator</span><span class="special">&lt;</span> <span class="identifier">my_expr_wrapper</span> <span class="special">&gt;</span> <span class="special">&gt;</span>
 134 <span class="special">{};</span>
 135
 136 <span class="keyword">template</span><span class="special">&lt;</span><span class="keyword">class</span> <span class="identifier">Expr</span><span class="special">&gt;</span>
 137 <span class="keyword">struct</span> <span class="identifier">my_expr_wrapper</span>
 138   <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">extends</span><span class="special">&lt;</span><span class="identifier">Expr</span><span class="special">,</span> <span class="identifier">my_expr_wrapper</span><span class="special">&lt;</span><span class="identifier">Expr</span><span class="special">&gt;,</span> <span class="identifier">my_domain</span><span class="special">&gt;</span>
 139 <span class="special">{</span>
 140   <span class="comment">// Before 1.44, Expr was an instance of proto::expr&lt;&gt;</span>
 141   <span class="comment">// In 1.44, Expr is an instance of proto::basic_expr&lt;&gt;</span>
 142 <span class="special">};</span>
 143 </pre>
 144 <p>
 145         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&lt;&gt;</a></code>
 146         is an expensive type to instantiate because it defines a host of member functions.
 147         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&lt;&gt;</a></code>
 148         sits as a hidden data member function in your wrapper and the members of
 149         <code class="computeroutput"><a class="link" href="../boost/proto/expr.html" title="Struct template expr">proto::expr&lt;&gt;</a></code> go unused. Therefore,
 150         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&lt;&gt;</a></code>
 151         is a very lightweight type with no member functions at all.
 152       </p>
 153 <p>
 154         The vast majority of programs should recompile without any source changes.
 155         However, if somewhere you are assuming that you will be given instances specifically
 156         of <code class="computeroutput"><a class="link" href="../boost/proto/expr.html" title="Struct template expr">proto::expr&lt;&gt;</a></code>, your code will break.
 157       </p>
 158 <p>
 159         <span class="bold"><strong>New Feature: Sub-domains</strong></span>
 160       </p>
 161 <p>
 162         In Boost 1.44, Proto introduces an important new feature called "sub-domains".
 163         This gives you a way to spcify that one domain is compatible with another
 164         such that expressions in one domain can be freely mixed with expressions
 165         in another. You can define one domain to be the sub-domain of another by
 166         using the third template parameter of <code class="computeroutput"><a class="link" href="../boost/proto/domain.html" title="Struct template domain">proto::domain&lt;&gt;</a></code>.
 167       </p>
 168 <p>
 169         For instance:
 170       </p>
 171 <pre class="programlisting"><span class="comment">// Not shown: define some expression</span>
 172 <span class="comment">// generators genA and genB</span>
 173
 174 <span class="keyword">struct</span> <span class="identifier">A</span>
 175   <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">domain</span><span class="special">&lt;</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">&gt;</span>
 176 <span class="special">{};</span>
 177
 178 <span class="comment">// Define a domain B that is the sub-domain</span>
 179 <span class="comment">// of domain A.</span>
 180 <span class="keyword">struct</span> <span class="identifier">B</span>
 181   <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">domain</span><span class="special">&lt;</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">&gt;</span>
 182 <span class="special">{};</span>
 183 </pre>
 184 <p>
 185         Expressions in domains <code class="computeroutput"><span class="identifier">A</span></code>
 186         and <code class="computeroutput"><span class="identifier">B</span></code> can have different
 187         wrappers (hence, different interfaces), but they can be combined into larger
 188         expressions. Without a sub-domain relationship, this would have been an error.
 189         The domain of the resulting expression in this case would be <code class="computeroutput"><span class="identifier">A</span></code>.
 190       </p>
 191 <p>
 192         The complete description of sub-domains can be found in the reference sections
 193         for <code class="computeroutput"><a class="link" href="../boost/proto/domain.html" title="Struct template domain">proto::domain&lt;&gt;</a></code> and <code class="computeroutput"><a class="link" href="../boost/proto/deduce_domain.html" title="Struct deduce_domain">proto::deduce_domain</a></code>.
 194       </p>
 195 <p>
 196         <span class="bold"><strong>New Feature: Domain-specific as_expr() and as_child()</strong></span>
 197       </p>
 198 <p>
 199         Proto has always allowed users to customize expressions post-hoc by specifying
 200         a Generator when defining their domain. But it has never allowed users to
 201         control how Proto assembles sub-expressions in the first place. As of Boost
 202         1.44, users now have this power.
 203       </p>
 204 <p>
 205         Users defining their own domain can now specify how <code class="computeroutput"><a class="link" href="../boost/proto/as_expr_idp704425472.html" title="Function as_expr">proto::as_expr()</a></code>
 206         and <code class="computeroutput"><a class="link" href="../boost/proto/as_child_idp704447440.html" title="Function as_child">proto::as_child()</a></code> work in their domain. They
 207         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>
 208         within their domain class.
 209       </p>
 210 <p>
 211         For example:
 212       </p>
 213 <pre class="programlisting"><span class="keyword">struct</span> <span class="identifier">my_domain</span>
 214   <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">domain</span><span class="special">&lt;</span> <span class="identifier">my_generator</span> <span class="special">&gt;</span>
 215 <span class="special">{</span>
 216   <span class="keyword">typedef</span>
 217       <span class="identifier">proto</span><span class="special">::</span><span class="identifier">domain</span><span class="special">&lt;</span> <span class="identifier">my_generator</span> <span class="special">&gt;</span>
 218   <span class="identifier">base_domain</span><span class="special">;</span>
 219
 220   <span class="comment">// For my_domain, as_child does the same as</span>
 221   <span class="comment">// what as_expr does by default.</span>
 222   <span class="keyword">template</span><span class="special">&lt;</span><span class="keyword">class</span> <span class="identifier">T</span><span class="special">&gt;</span>
 223   <span class="keyword">struct</span> <span class="identifier">as_child</span>
 224     <span class="special">:</span> <span class="identifier">base_domain</span><span class="special">::</span><span class="identifier">as_expr</span><span class="special">&lt;</span><span class="identifier">T</span><span class="special">&gt;</span>
 225   <span class="special">{};</span>
 226 <span class="special">};</span>
 227 </pre>
 228 <p>
 229         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">&lt;&gt;</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">&lt;&gt;</span></code>. This has the nice effect of causing
 230         all terminals to be captured by value instead of by reference, and to likewise
 231         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
 232         dangling references to intermediate temporary expressions. (Naturally, it
 233         also means that expression construction has extra runtime overhead of copying
 234         that the compiler may or may not be able to optimize away.)
 235       </p>
 236 <h5>
 237 <a name="boost_proto.appendices.release_notes.h2"></a>
 238         <span class="phrase"><a name="boost_proto.appendices.release_notes.boost_1_43"></a></span><a class="link" href="appendices.html#boost_proto.appendices.release_notes.boost_1_43">Boost
 239         1.43</a>
 240       </h5>
 241 <p>
 242         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&lt;&gt;</a></code>
 243         changed slightly. The new usage looks like this:
 244       </p>
 245 <pre class="programlisting"><span class="comment">// my_expr is an expression extension of the Expr parameter</span>
 246 <span class="keyword">template</span><span class="special">&lt;</span><span class="keyword">typename</span> <span class="identifier">Expr</span><span class="special">&gt;</span>
 247 <span class="keyword">struct</span> <span class="identifier">my_expr</span>
 248   <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">extends</span><span class="special">&lt;</span><span class="identifier">Expr</span><span class="special">,</span> <span class="identifier">my_expr</span><span class="special">&lt;</span><span class="identifier">Expr</span><span class="special">&gt;,</span> <span class="identifier">my_domain</span><span class="special">&gt;</span>
 249 <span class="special">{</span>
 250     <span class="identifier">my_expr</span><span class="special">(</span><span class="identifier">Expr</span> <span class="keyword">const</span> <span class="special">&amp;</span><span class="identifier">expr</span> <span class="special">=</span> <span class="identifier">Expr</span><span class="special">())</span>
 251       <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">extends</span><span class="special">&lt;</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">&gt;(</span><span class="identifier">expr</span><span class="special">)</span>
 252     <span class="special">{}</span>
 253
 254     <span class="comment">// NEW: use the following macro to bring</span>
 255     <span class="comment">// proto::extends::operator= into scope.</span>
 256     <span class="identifier">BOOST_PROTO_EXTENDS_USING_ASSIGN</span><span class="special">(</span><span class="identifier">my_expr</span><span class="special">)</span>
 257 <span class="special">};</span>
 258 </pre>
 259 <p>
 260         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>
 261         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&lt;&gt;</a></code> overloads the assignment
 262         operator. However, for the <code class="computeroutput"><span class="identifier">my_expr</span></code>
 263         template, the compiler generates a default copy assignment operator that
 264         hides the ones in <code class="computeroutput"><a class="link" href="../boost/proto/extends.html" title="Struct template extends">proto::extends&lt;&gt;</a></code>. This is often not desired
 265         (although it depends on the syntax you want to allow).
 266       </p>
 267 <p>
 268         Previously, the recommended usage was to do this:
 269       </p>
 270 <pre class="programlisting"><span class="comment">// my_expr is an expression extension of the Expr parameter</span>
 271 <span class="keyword">template</span><span class="special">&lt;</span><span class="keyword">typename</span> <span class="identifier">Expr</span><span class="special">&gt;</span>
 272 <span class="keyword">struct</span> <span class="identifier">my_expr</span>
 273   <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">extends</span><span class="special">&lt;</span><span class="identifier">Expr</span><span class="special">,</span> <span class="identifier">my_expr</span><span class="special">&lt;</span><span class="identifier">Expr</span><span class="special">&gt;,</span> <span class="identifier">my_domain</span><span class="special">&gt;</span>
 274 <span class="special">{</span>
 275     <span class="identifier">my_expr</span><span class="special">(</span><span class="identifier">Expr</span> <span class="keyword">const</span> <span class="special">&amp;</span><span class="identifier">expr</span> <span class="special">=</span> <span class="identifier">Expr</span><span class="special">())</span>
 276       <span class="special">:</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">extends</span><span class="special">&lt;</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">&gt;(</span><span class="identifier">expr</span><span class="special">)</span>
 277     <span class="special">{}</span>
 278
 279     <span class="comment">// OLD: don't do it like this anymore.</span>
 280     <span class="keyword">using</span> <span class="identifier">proto</span><span class="special">::</span><span class="identifier">extends</span><span class="special">&lt;</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">&gt;::</span><span class="keyword">operator</span><span class="special">=;</span>
 281 <span class="special">};</span>
 282 </pre>
 283 <p>
 284         While this works in the majority of cases, it still doesn't suppress the
 285         implicit generation of the default assignment operator. As a result, expressions
 286         of the form <code class="computeroutput"><span class="identifier">a</span> <span class="special">=</span>
 287         <span class="identifier">b</span></code> could either build an expression
 288         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>
 289         happen to be the same. That can lead to subtle bugs, so the behavior was
 290         changed.
 291       </p>
 292 <p>
 293         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>
 294         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&lt;&gt;</a></code>
 295         as well as suppresses the generation of the copy assignment operator.
 296       </p>
 297 <p>
 298         Also note that the <code class="computeroutput"><a class="link" href="../boost/proto/literal.html" title="Struct template literal">proto::literal&lt;&gt;</a></code> class template, which
 299         uses <code class="computeroutput"><a class="link" href="../boost/proto/extends.html" title="Struct template extends">proto::extends&lt;&gt;</a></code>, has been chaged to use
 300         <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>.
 301         The implications are highlighted in the sample code below:
 302       </p>
 303 <pre class="programlisting"><span class="identifier">proto</span><span class="special">::</span><span class="identifier">literal</span><span class="special">&lt;</span><span class="keyword">int</span><span class="special">&gt;</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>
 304 <span class="identifier">proto</span><span class="special">::</span><span class="identifier">literal</span><span class="special">&lt;</span><span class="keyword">int</span><span class="special">&gt;</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>
 305
 306 <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>
 307        <span class="comment">// Same behavior in 1.42 and 1.43.</span>
 308
 309 <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>
 310        <span class="comment">// a's value to change to 3. In 1.43, the behavior is now</span>
 311        <span class="comment">// the same as above: build and discard an expression tree.</span>
 312 </pre>
 313 </div>
 314 <div class="section">
 315 <div class="titlepage"><div><div><h3 class="title">
 316 <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>
 317 </h3></div></div></div>
 318 <div class="variablelist">
 319 <p class="title"><b></b></p>
 320 <dl class="variablelist">
 321 <dt><span class="term">August 13, 2010</span></dt>
 322 <dd><p>
 323               Boost 1.44: Proto gets sub-domains and per-domain control of <code class="computeroutput"><a class="link" href="../boost/proto/as_expr_idp704425472.html" title="Function as_expr">proto::as_expr()</a></code> and <code class="computeroutput"><a class="link" href="../boost/proto/as_child_idp704447440.html" title="Function as_child">proto::as_child()</a></code> to meet the needs
 324               of Phoenix3.
 325             </p></dd>
 326 <dt><span class="term">August 11, 2008</span></dt>
 327 <dd><p>
 328               Proto v4 is merged to Boost trunk with more powerful transform protocol.
 329             </p></dd>
 330 <dt><span class="term">April 7, 2008</span></dt>
 331 <dd><p>
 332               Proto is accepted into Boost.
 333             </p></dd>
 334 <dt><span class="term">March 1, 2008</span></dt>
 335 <dd><p>
 336               Proto's Boost review begins.
 337             </p></dd>
 338 <dt><span class="term">January 11, 2008</span></dt>
 339 <dd><p>
 340               Boost.Proto v3 brings separation of grammars and transforms and a "round"
 341               lambda syntax for defining transforms in-place.
 342             </p></dd>
 343 <dt><span class="term">April 15, 2007</span></dt>
 344 <dd><p>
 345               Boost.Xpressive is ported from Proto compilers to Proto transforms.
 346               Support for old Proto compilers is dropped.
 347             </p></dd>
 348 <dt><span class="term">April 4, 2007</span></dt>
 349 <dd><p>
 350               Preliminary submission of Proto to Boost.
 351             </p></dd>
 352 <dt><span class="term">December 11, 2006</span></dt>
 353 <dd><p>
 354               The idea for transforms that decorate grammar rules is born in a private
 355               email discussion with Joel de Guzman and Hartmut Kaiser. The first
 356               transforms are committed to CVS 5 days later on December 16.
 357             </p></dd>
 358 <dt><span class="term">November 1, 2006</span></dt>
 359 <dd><p>
 360               The idea for <code class="computeroutput"><span class="identifier">proto</span><span class="special">::</span><span class="identifier">matches</span><span class="special">&lt;&gt;</span></code> and the whole grammar facility
 361               is hatched during a discussion with Hartmut Kaiser on the spirit-devel
 362               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">&lt;&gt;</span></code> is checked into CVS 3 days
 363               later. Message is <a href="http://osdir.com/ml/parsers.spirit.devel/2006-11/msg00003.html" target="_top">here</a>.
 364             </p></dd>
 365 <dt><span class="term">October 28, 2006</span></dt>
 366 <dd><p>
 367               Proto is reborn, this time with a uniform expression types that are
 368               POD. Announcement is <a href="http://lists.boost.org/Archives/boost/2006/10/112453.php" target="_top">here</a>.
 369             </p></dd>
 370 <dt><span class="term">April 20, 2005</span></dt>
 371 <dd><p>
 372               Proto is born as a major refactorization of Boost.Xpressive's meta-programming.
 373               Proto offers expression types, operator overloads and "compilers",
 374               an early formulation of what later became transforms. Announcement
 375               is <a href="http://lists.boost.org/Archives/boost/2005/04/85256.php" target="_top">here</a>.
 376             </p></dd>
 377 </dl>
 378 </div>
 379 </div>
 380 <div class="section">
 381 <div class="titlepage"><div><div><h3 class="title">
 382 <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>
 383 </h3></div></div></div>
 384 <div class="toc"><dl class="toc">
 385 <dt><span class="section"><a href="appendices.html#boost_proto.appendices.rationale.static_initialization">Static
 386         Initialization</a></span></dt>
 387 <dt><span class="section"><a href="appendices.html#boost_proto.appendices.rationale.preprocessor">Why
 388         Not Reuse MPL, Fusion, et cetera?</a></span></dt>
 389 </dl></div>
 390 <div class="section">
 391 <div class="titlepage"><div><div><h4 class="title">
 392 <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
 393         Initialization</a>
 394 </h4></div></div></div>
 395 <p>
 396           Proto expression types are PODs (Plain Old Data), and do not have constructors.
 397           They are brace-initialized, as follows:
 398         </p>
 399 <pre class="programlisting"><span class="identifier">terminal</span><span class="special">&lt;</span><span class="keyword">int</span><span class="special">&gt;::</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>
 400 </pre>
 401 <p>
 402           The reason is so that expression objects like <code class="computeroutput"><span class="identifier">_i</span></code>
 403           above can be <span class="emphasis"><em>statically initialized</em></span>. Why is static
 404           initialization important? The terminals of many embedded domain-specific
 405           languages are likely to be global const objects, like <code class="computeroutput"><span class="identifier">_1</span></code>
 406           and <code class="computeroutput"><span class="identifier">_2</span></code> from the Boost Lambda
 407           Library. Were these object to require run-time initialization, it might
 408           be possible to use these objects before they are initialized. That would
 409           be bad. Statically initialized objects cannot be misused that way.
 410         </p>
 411 </div>
 412 <div class="section">
 413 <div class="titlepage"><div><div><h4 class="title">
 414 <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
 415         Not Reuse MPL, Fusion, et cetera?</a>
 416 </h4></div></div></div>
 417 <p>
 418           Anyone who has peeked at Proto's source code has probably wondered, "Why
 419           all the dirty preprocessor gunk? Couldn't this have been all implemented
 420           cleanly on top of libraries like MPL and Fusion?" The answer is that
 421           Proto could have been implemented this way, and in fact was at one point.
 422           The problem is that template metaprogramming (TMP) makes for longer compile
 423           times. As a foundation upon which other TMP-heavy libraries will be built,
 424           Proto itself should be as lightweight as possible. That is achieved by
 425           prefering preprocessor metaprogramming to template metaprogramming. Expanding
 426           a macro is far more efficient than instantiating a template. In some cases,
 427           the "clean" version takes 10x longer to compile than the "dirty"
 428           version.
 429         </p>
 430 <p>
 431           The "clean and slow" version of Proto can still be found at http://svn.boost.org/svn/boost/branches/proto/v3.
 432           Anyone who is interested can download it and verify that it is, in fact,
 433           unusably slow to compile. Note that this branch's development was abandoned,
 434           and it does not conform exactly with Proto's current interface.
 435         </p>
 436 </div>
 437 </div>
 438 <div class="section">
 439 <div class="titlepage"><div><div><h3 class="title">
 440 <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
 441       Notes</a>
 442 </h3></div></div></div>
 443 <div class="toc"><dl class="toc">
 444 <dt><span class="section"><a href="appendices.html#boost_proto.appendices.implementation.sfinae">Quick-n-Dirty
 445         Type Categorization</a></span></dt>
 446 <dt><span class="section"><a href="appendices.html#boost_proto.appendices.implementation.function_arity">Detecting
 447         the Arity of Function Objects</a></span></dt>
 448 </dl></div>
 449 <div class="section">
 450 <div class="titlepage"><div><div><h4 class="title">
 451 <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
 452         Type Categorization</a>
 453 </h4></div></div></div>
 454 <p>
 455           Much has already been written about dispatching on type traits using SFINAE
 456           (Substitution Failure Is Not An Error) techniques in C++. There is a Boost
 457           library, Boost.Enable_if, to make the technique idiomatic. Proto dispatches
 458           on type traits extensively, but it doesn't use <code class="computeroutput"><span class="identifier">enable_if</span><span class="special">&lt;&gt;</span></code> very often. Rather, it dispatches
 459           based on the presence or absence of nested types, often typedefs for void.
 460         </p>
 461 <p>
 462           Consider the implementation of <code class="computeroutput"><span class="identifier">is_expr</span><span class="special">&lt;&gt;</span></code>. It could have been written as
 463           something like this:
 464         </p>
 465 <pre class="programlisting"><span class="keyword">template</span><span class="special">&lt;</span><span class="keyword">typename</span> <span class="identifier">T</span><span class="special">&gt;</span>
 466 <span class="keyword">struct</span> <span class="identifier">is_expr</span>
 467   <span class="special">:</span> <span class="identifier">is_base_and_derived</span><span class="special">&lt;</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">&gt;</span>
 468 <span class="special">{};</span>
 469 </pre>
 470 <p>
 471           Rather, it is implemented as this:
 472         </p>
 473 <pre class="programlisting"><span class="keyword">template</span><span class="special">&lt;</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">&gt;</span>
 474 <span class="keyword">struct</span> <span class="identifier">is_expr</span>
 475   <span class="special">:</span> <span class="identifier">mpl</span><span class="special">::</span><span class="identifier">false_</span>
 476 <span class="special">{};</span>
 477
 478 <span class="keyword">template</span><span class="special">&lt;</span><span class="keyword">typename</span> <span class="identifier">T</span><span class="special">&gt;</span>
 479 <span class="keyword">struct</span> <span class="identifier">is_expr</span><span class="special">&lt;</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">&gt;</span>
 480   <span class="special">:</span> <span class="identifier">mpl</span><span class="special">::</span><span class="identifier">true_</span>
 481 <span class="special">{};</span>
 482 </pre>
 483 <p>
 484           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>
 485           that is a typedef for <code class="computeroutput"><span class="keyword">void</span></code>.
 486           All Proto expression types have such a nested typedef.
 487         </p>
 488 <p>
 489           Why does Proto do it this way? The reason is because, after running extensive
 490           benchmarks while trying to improve compile times, I have found that this
 491           approach compiles faster. It requires exactly one template instantiation.
 492           The other approach requires at least 2: <code class="computeroutput"><span class="identifier">is_expr</span><span class="special">&lt;&gt;</span></code> and <code class="computeroutput"><span class="identifier">is_base_and_derived</span><span class="special">&lt;&gt;</span></code>, plus whatever templates <code class="computeroutput"><span class="identifier">is_base_and_derived</span><span class="special">&lt;&gt;</span></code>
 493           may instantiate.
 494         </p>
 495 </div>
 496 <div class="section">
 497 <div class="titlepage"><div><div><h4 class="title">
 498 <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
 499         the Arity of Function Objects</a>
 500 </h4></div></div></div>
 501 <p>
 502           In several places, Proto needs to know whether or not a function object
 503           <code class="computeroutput"><span class="identifier">Fun</span></code> can be called with
 504           certain parameters and take a fallback action if not. This happens in
 505           <code class="computeroutput"><a class="link" href="../boost/proto/context/callable_context.html" title="Struct template callable_context">proto::callable_context&lt;&gt;</a></code>
 506           and in the <code class="computeroutput"><a class="link" href="../boost/proto/call.html" title="Struct template call">proto::call&lt;&gt;</a></code> transform. How does
 507           Proto know? It involves some tricky metaprogramming. Here's how.
 508         </p>
 509 <p>
 510           Another way of framing the question is by trying to implement the following
 511           <code class="computeroutput"><span class="identifier">can_be_called</span><span class="special">&lt;&gt;</span></code>
 512           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
 513           type <code class="computeroutput"><span class="identifier">A</span></code> and <code class="computeroutput"><span class="identifier">B</span></code>:
 514         </p>
 515 <pre class="programlisting"><span class="keyword">template</span><span class="special">&lt;</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">&gt;</span>
 516 <span class="keyword">struct</span> <span class="identifier">can_be_called</span><span class="special">;</span>
 517 </pre>
 518 <p>
 519           First, we define the following <code class="computeroutput"><span class="identifier">dont_care</span></code>
 520           struct, which has an implicit conversion from anything. And not just any
 521           implicit conversion; it has a ellipsis conversion, which is the worst possible
 522           conversion for the purposes of overload resolution:
 523         </p>
 524 <pre class="programlisting"><span class="keyword">struct</span> <span class="identifier">dont_care</span>
 525 <span class="special">{</span>
 526     <span class="identifier">dont_care</span><span class="special">(...);</span>
 527 <span class="special">};</span>
 528 </pre>
 529 <p>
 530           We also need some private type known only to us with an overloaded comma
 531           operator (!), and some functions that detect the presence of this type
 532           and return types with different sizes, as follows:
 533         </p>
 534 <pre class="programlisting"><span class="keyword">struct</span> <span class="identifier">private_type</span>
 535 <span class="special">{</span>
 536     <span class="identifier">private_type</span> <span class="keyword">const</span> <span class="special">&amp;</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>
 537 <span class="special">};</span>
 538
 539 <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>
 540 <span class="keyword">typedef</span> <span class="keyword">char</span> <span class="special">(&amp;</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>
 541
 542 <span class="keyword">template</span><span class="special">&lt;</span><span class="keyword">typename</span> <span class="identifier">T</span><span class="special">&gt;</span>
 543 <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">&amp;);</span>
 544
 545 <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">&amp;);</span>
 546 </pre>
 547 <p>
 548           Next, we implement a binary function object wrapper with a very strange
 549           conversion operator, whose meaning will become clear later.
 550         </p>
 551 <pre class="programlisting"><span class="keyword">template</span><span class="special">&lt;</span><span class="keyword">typename</span> <span class="identifier">Fun</span><span class="special">&gt;</span>
 552 <span class="keyword">struct</span> <span class="identifier">funwrap2</span> <span class="special">:</span> <span class="identifier">Fun</span>
 553 <span class="special">{</span>
 554     <span class="identifier">funwrap2</span><span class="special">();</span>
 555     <span class="keyword">typedef</span> <span class="identifier">private_type</span> <span class="keyword">const</span> <span class="special">&amp;(*</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>
 556     <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>
 557 <span class="special">};</span>
 558 </pre>
 559 <p>
 560           With all of these bits and pieces, we can implement <code class="computeroutput"><span class="identifier">can_be_called</span><span class="special">&lt;&gt;</span></code> as follows:
 561         </p>
 562 <pre class="programlisting"><span class="keyword">template</span><span class="special">&lt;</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">&gt;</span>
 563 <span class="keyword">struct</span> <span class="identifier">can_be_called</span>
 564 <span class="special">{</span>
 565     <span class="keyword">static</span> <span class="identifier">funwrap2</span><span class="special">&lt;</span><span class="identifier">Fun</span><span class="special">&gt;</span> <span class="special">&amp;</span><span class="identifier">fun</span><span class="special">;</span>
 566     <span class="keyword">static</span> <span class="identifier">A</span> <span class="special">&amp;</span><span class="identifier">a</span><span class="special">;</span>
 567     <span class="keyword">static</span> <span class="identifier">B</span> <span class="special">&amp;</span><span class="identifier">b</span><span class="special">;</span>
 568
 569     <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>
 570         <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>
 571     <span class="special">);</span>
 572
 573     <span class="keyword">typedef</span> <span class="identifier">mpl</span><span class="special">::</span><span class="identifier">bool_</span><span class="special">&lt;</span><span class="identifier">value</span><span class="special">&gt;</span> <span class="identifier">type</span><span class="special">;</span>
 574 <span class="special">};</span>
 575 </pre>
 576 <p>
 577           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
 578           always compile by adding our own binary function overload, but doing it
 579           in such a way that we can detect whether our overload was selected or not.
 580           And we rig it so that our overload is selected if there is really no better
 581           option. What follows is a description of how <code class="computeroutput"><span class="identifier">can_be_called</span><span class="special">&lt;&gt;</span></code> works.
 582         </p>
 583 <p>
 584           We wrap <code class="computeroutput"><span class="identifier">Fun</span></code> in a type that
 585           has an implicit conversion to a pointer to a binary function. An object
 586           <code class="computeroutput"><span class="identifier">fun</span></code> of class type can be
 587           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,
 588           but since it involves a user-defined conversion operator, it is less preferred
 589           than an overloaded <code class="computeroutput"><span class="keyword">operator</span><span class="special">()</span></code>, which requires no such conversion.
 590         </p>
 591 <p>
 592           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
 593           for each argument is guaranteed to be the worst possible conversion sequence:
 594           an implicit conversion through an ellipsis, and a user-defined conversion
 595           to <code class="computeroutput"><span class="identifier">dont_care</span></code>. In total,
 596           it means that <code class="computeroutput"><span class="identifier">funwrap2</span><span class="special">&lt;</span><span class="identifier">Fun</span><span class="special">&gt;()(</span><span class="identifier">a</span><span class="special">,</span> <span class="identifier">b</span><span class="special">)</span></code>
 597           will always compile, but it will select our overload only if there really
 598           is no better option.
 599         </p>
 600 <p>
 601           If there is a better option --- for example if <code class="computeroutput"><span class="identifier">Fun</span></code>
 602           has an overloaded function call operator such as <code class="computeroutput"><span class="keyword">void</span>
 603           <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> ---
 604           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
 605           question now is how to detect which function got picked by overload resolution.
 606         </p>
 607 <p>
 608           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">&lt;&gt;</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>.
 609           Why do we use the comma operator there? The reason is because we are using
 610           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>,
 611           it cannot legally be used as an argument to a function. The comma operator
 612           sidesteps the issue.
 613         </p>
 614 <p>
 615           This should also make plain the purpose of the overloaded comma operator
 616           in <code class="computeroutput"><span class="identifier">private_type</span></code>. The return
 617           type of the pointer to function is <code class="computeroutput"><span class="identifier">private_type</span></code>.
 618           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>
 619           <span class="identifier">b</span><span class="special">),</span>
 620           <span class="number">0</span><span class="special">)</span></code>
 621           is <code class="computeroutput"><span class="identifier">private_type</span></code>. Otherwise,
 622           it is <code class="computeroutput"><span class="keyword">int</span></code>. That fact is used
 623           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
 624           of its return type.
 625         </p>
 626 <p>
 627           That's how it works with binary functions. Now repeat the above process
 628           for functions up to some predefined function arity, and you're done.
 629         </p>
 630 </div>
 631 </div>
 632 <div class="section">
 633 <div class="titlepage"><div><div><h3 class="title">
 634 <a name="boost_proto.appendices.acknowledgements"></a><a class="link" href="appendices.html#boost_proto.appendices.acknowledgements" title="Appendix E: Acknowledgements">Appendix E:
 635       Acknowledgements</a>
 636 </h3></div></div></div>
 637 <p>
 638         I'd like to thank Joel de Guzman and Hartmut Kaiser for being willing to
 639         take a chance on using Proto for their work on Spirit-2 and Karma when Proto
 640         was little more than a vision. Their requirements and feedback have been
 641         indespensable.
 642       </p>
 643 <p>
 644         Thanks also to Thomas Heller and again to Hartmut for their feedback and
 645         suggestions during the redesign of Phoenix. That effort yielded several valuable
 646         advanced features such as sub-domains, external transforms, and per-domain
 647         <code class="computeroutput"><span class="identifier">as_child</span></code> customization.
 648       </p>
 649 <p>
 650         Thanks to Daniel James for providing a patch to remove the dependence on
 651         deprecated configuration macros for C++0x features.
 652       </p>
 653 <p>
 654         Thanks to Joel Falcou and Christophe Henry for their enthusiasm, support,
 655         feedback, and humor; and for volunteering to be Proto's co-maintainers.
 656       </p>
 657 <p>
 658         Thanks to Dave Abrahams for an especially detailed review, and for making
 659         a VM with msvc-7.1 available so I could track down portability issues on
 660         that compiler.
 661       </p>
 662 <p>
 663         Many thanks to Daniel Wallin who first implemented the code used to find
 664         the common domain among a set, accounting for super- and sub-domains. Thanks
 665         also to Jeremiah Willcock, John Bytheway and Krishna Achuthan who offered
 666         alternate solutions to this tricky programming problem.
 667       </p>
 668 <p>
 669         Thanks also to the developers of <a href="http://acts.nersc.gov/formertools/pete/index.html" target="_top">PETE</a>.
 670         I found many good ideas there.
 671       </p>
 672 </div>
 673 </div>
 674 <table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr>
 675 <td align="left"></td>
 676 <td align="right"><div class="copyright-footer">Copyright &#169; 2008 Eric Niebler<p>
 677         Distributed under the Boost Software License, Version 1.0. (See accompanying
 678         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>)
 679       </p>
 680 </div></td>
 681 </tr></table>
 682 <hr>
 683 <div class="spirit-nav">
 684 <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>
 685 </div>
 686 </body>
 687 </html>