|
|
Boost-Commit : |
Subject: [Boost-commit] svn:boost r51586 - in branches/release: . libs/proto/doc libs/proto/doc/reference/transform
From: eric_at_[hidden]
Date: 2009-03-03 19:10:40
Author: eric_niebler
Date: 2009-03-03 19:10:39 EST (Tue, 03 Mar 2009)
New Revision: 51586
URL: http://svn.boost.org/trac/boost/changeset/51586
Log:
Merged revisions 51585 via svnmerge from
https://svn.boost.org/svn/boost/trunk
........
r51585 | eric_niebler | 2009-03-03 16:01:09 -0800 (Tue, 03 Mar 2009) | 1 line
minor doc tweaks
........
Properties modified:
branches/release/ (props changed)
Text files modified:
branches/release/libs/proto/doc/back_end.qbk | 2 +-
branches/release/libs/proto/doc/front_end.qbk | 2 +-
branches/release/libs/proto/doc/reference/transform/make.xml | 36 +++++++++++++++++-------------------
3 files changed, 19 insertions(+), 21 deletions(-)
Modified: branches/release/libs/proto/doc/back_end.qbk
==============================================================================
--- branches/release/libs/proto/doc/back_end.qbk (original)
+++ branches/release/libs/proto/doc/back_end.qbk 2009-03-03 19:10:39 EST (Tue, 03 Mar 2009)
@@ -19,7 +19,7 @@
expression, but with rules in a Proto grammar. In this way, they are like
semantic actions in other compiler-construction toolkits.
-Two ways to evaluate expressions! How to choose? Contexts are a bit simpler to understand and to debug, since they are largely procedural, so contexts are a good place to start. But although transforms are more advanced, they are also more powerful; since they are associated with rules in your grammar, you can select the proper transform based on the entire /structure/ of a sub-expression rather than simply on the type of its top-most node.
+Two ways to evaluate expressions! How to choose? Since contexts are largely procedural, they are a bit simpler to understand and debug so they are a good place to start. But although transforms are more advanced, they are also more powerful; since they are associated with rules in your grammar, you can select the proper transform based on the entire /structure/ of a sub-expression rather than simply on the type of its top-most node.
Also, transforms have a concise and declarative syntax that can be confusing at first, but highly expressive and fungible once you become accustomed to it. And -- this is admittedly very subjective -- the author finds programming with Proto transforms to be an inordinate amount of /fun!/ Your mileage may vary.
Modified: branches/release/libs/proto/doc/front_end.qbk
==============================================================================
--- branches/release/libs/proto/doc/front_end.qbk (original)
+++ branches/release/libs/proto/doc/front_end.qbk 2009-03-03 19:10:39 EST (Tue, 03 Mar 2009)
@@ -389,7 +389,7 @@
We need to make one additional small change to accommodate the POD-ness of our expression extension, which we'll describe below in the section on expression generators.
-What does _EXTENDS_ do? It defines a data member of expression type being extended; some nested typedefs that Proto requires; `operator=`, `operator[]` and `operator()` overloads for building expression templates; and a nested `result<>` template for calculating the return type of `operator()`. In this case, however, the `operator()` overloads and the `result<>` template are not needed because we are defining our own `operator()` in the `calculator<>` type. Proto provides additional macros for finer control over which member functions are defined. We could improve our `calculator<>` type as follows:
+What does _EXTENDS_ do? It defines a data member of the expression type being extended; some nested typedefs that Proto requires; `operator=`, `operator[]` and `operator()` overloads for building expression templates; and a nested `result<>` template for calculating the return type of `operator()`. In this case, however, the `operator()` overloads and the `result<>` template are not needed because we are defining our own `operator()` in the `calculator<>` type. Proto provides additional macros for finer control over which member functions are defined. We could improve our `calculator<>` type as follows:
// The calculator<> expression wrapper makes expressions
// function objects.
Modified: branches/release/libs/proto/doc/reference/transform/make.xml
==============================================================================
--- branches/release/libs/proto/doc/reference/transform/make.xml (original)
+++ branches/release/libs/proto/doc/reference/transform/make.xml 2009-03-03 19:10:39 EST (Tue, 03 Mar 2009)
@@ -85,7 +85,7 @@
<inherit><classname>proto::transform</classname>< make<T> ></inherit>
- <purpose>A <conceptname>PrimitiveTransform</conceptname> which computes a type by evaluating
+ <purpose>A <conceptname>PrimitiveTransform</conceptname> that computes a type by evaluating
any nested transforms and then constructs an object of that type. </purpose>
<description>
@@ -124,20 +124,28 @@
<para>
If <computeroutput>T</computeroutput> is an <conceptname>ObjectTransform</conceptname> of the form
- <computeroutput>
- Object(A<subscript>0</subscript>,...A<subscript>n</subscript>)
- </computeroutput>, then let <computeroutput>O</computeroutput> be
- the return type <computeroutput>Object</computeroutput>. Otherwise, let <computeroutput>O</computeroutput>
+ <computeroutput>Object(A<subscript>0</subscript>,...A<subscript>n</subscript>)</computeroutput>,
+ then let <computeroutput>O</computeroutput> be the return type
+ <computeroutput>Object</computeroutput>. Otherwise, let <computeroutput>O</computeroutput>
be <computeroutput>T</computeroutput>. The <computeroutput>result_type</computeroutput> typedef is
then computed as follows:
</para>
<para>
<itemizedlist>
<listitem>
- If <computeroutput>O</computeroutput> is a template like
- <computeroutput>
- S<X<subscript>0</subscript>,...X<subscript>n</subscript>>
- </computeroutput>, then the result type is calculated as follows:
+ <para>
+ If <computeroutput>O</computeroutput> is a <conceptname>Transform</conceptname>, then let
+ the result type be
+ <computeroutput>
+ boost::result_of<<classname>proto::when</classname><<classname>_</classname>, O>(Expr, State, Data)>::type
+ </computeroutput>.
+ Note that a substitution took place.
+ </para>
+ </listitem>
+ <listitem>
+ Otherwise, if <computeroutput>O</computeroutput> is a template like
+ <computeroutput>S<X<subscript>0</subscript>,...X<subscript>n</subscript>></computeroutput>,
+ then the result type is calculated as follows:
<itemizedlist>
<listitem>
<para>
@@ -175,16 +183,6 @@
</itemizedlist>
</listitem>
<listitem>
- <para>
- Otherwise, if <computeroutput>O</computeroutput> is a <conceptname>Transform</conceptname>, then let
- the result type be
- <computeroutput>
- boost::result_of<<classname>proto::when</classname><<classname>_</classname>, O>(Expr, State, Data)>::type
- </computeroutput>.
- Note that a substitution took place.
- </para>
- </listitem>
- <listitem>
Otherwise, the result type is <computeroutput>O</computeroutput>, and note that no
substitution took place.
</listitem>
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk