Update of /cvsroot/boost/boost/libs/xpressive/proto/doc
In directory sc8-pr-cvs3.sourceforge.net:/tmp/cvs-serv25252
Modified Files:
acknowledgements.qbk calculator.qbk extensibility.qbk
grammars.qbk installation.qbk preface.qbk proto.qbk
quick_start.qbk transforms.qbk Jamfile.v2
Added Files:
history.qbk implementation.qbk rationale.qbk
Log Message:
begin doc restructure
--- NEW FILE: history.qbk ---
[/
/ Copyright (c) 2006 Eric Niebler
/
/ Distributed under the Boost Software License, Version 1.0. (See accompanying
/ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
/]
[section:history Appendix A: History]
[variablelist
[
[April 27, 2005]
[Proto is born, as a major refactorization and rewrite of Boost.Xpressive's
meta-programming. Proto offers expression types, operator overloads and
"compilers", an early formulation of what later became transforms.
Announcement [EMAIL
PROTECTED]://lists.boost.org/Archives/boost/2005/04/85256.php here].]
]
[endsect]
--- NEW FILE: implementation.qbk ---
[/
/ Copyright (c) 2006 Eric Niebler
/
/ Distributed under the Boost Software License, Version 1.0. (See accompanying
/ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
/]
[section:implementation Appendix C: Implementation Notes]
TODO
[endsect]
--- NEW FILE: rationale.qbk ---
[/
/ Copyright (c) 2006 Eric Niebler
/
/ Distributed under the Boost Software License, Version 1.0. (See accompanying
/ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
/]
[section:rationale Appendix B: Rationale]
[section:static_initialization Static Initialization]
Proto expression types are PODs (Plain Old Data), and do not have constructors.
They are brace-initialized, as follows:
terminal<int>::type const _i = {1};
The reason is so that expression objects like `_i` above can be ['statically
initialized]. Why is static initialization important? The terminals of many
domain-specific embedded languages are likely to be global const objects, like
`_1` and `_2` from the Boost.Lambda library. Were these object to require
run-time initialization, it might be possible to use these objects before they
are initialized. That would be bad. Statically initialized objects cannot be
misused that way.]
[endsect]
[endsect]
Index: acknowledgements.qbk
===================================================================
RCS file: /cvsroot/boost/boost/libs/xpressive/proto/doc/acknowledgements.qbk,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- acknowledgements.qbk 15 Apr 2007 06:46:57 -0000 1.2
+++ acknowledgements.qbk 18 Jun 2007 02:56:21 -0000 1.3
@@ -5,7 +5,7 @@
/ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
/]
-[section Acknowledgements]
+[section:acknowledgements Appendix D: Acknowledgements]
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
Index: calculator.qbk
===================================================================
RCS file: /cvsroot/boost/boost/libs/xpressive/proto/doc/calculator.qbk,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -d -r1.10 -r1.11
--- calculator.qbk 16 Jun 2007 05:46:14 -0000 1.10
+++ calculator.qbk 18 Jun 2007 02:56:21 -0000 1.11
@@ -18,7 +18,7 @@
`_1` and `_2` are placeholders for values to be passed in when the expression
is evaluated.
-[h3 Defining Terminals]
+[header Defining Terminals]
The first order of business is to define the placeholders `_1` and `_2`. For
that, we'll use the _terminal_ expression generator.
@@ -34,17 +34,10 @@
The initialization may look a little odd at first, but there is a good reason
for doing things this way. The objects `_1` and `_2` above do not require
run-time construction -- they are ['statically initialized], which means they
-are essentially initialized at compile time.
-
-[/ TODO Move this discussion into expr_trees.qbk]
-
-[blurb [*Static Initialization]\n
-\n
-Why is static initialization important? The terminals of many domain-specific
-embedded languages are likely to be global const objects, like `_1` and `_2`
-above. 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.]
+are essentially initialized at compile time. See the
+[link boost_proto.appendices.rationale.static_initialization Static
+Initialization] section in the [link boost_proto.appendices.rationale
Rationale]
+appendix for more information.
The actual type of `_1` looks like this:
@@ -54,7 +47,8 @@
parameter is the node type; in this case, `proto::tag::terminal`. That means
that `_1` is a leaf-node in the expression tree. The second template parameter
is a list of children types. Terminals will always have only one type in the
-type list. The last parameter is the arity of .
+type list. The last parameter is the arity of the expression. Terminals have
+arity 0, unary expressions have arity 1, etc.
The _expr_ struct is defined as follows:
@@ -76,7 +70,7 @@
is of type `placeholder1`. Note that we use braces to initialize `_1.arg0`
because `placeholder1` is also an aggregate.
-[h3 Constructing Expression Trees]
+[header Constructing Expression Trees]
Now that we have terminals, we can use Proto's operator overloads to combine
these terminals into larger expressions. So, for instance, we can immediately
@@ -88,7 +82,7 @@
behavior. In particular, it is not yet a calculator. Below we'll see how
to make it a calculator by defining an evaluation context.
-[h3 Defining an Evaluation Context]
+[header Defining an Evaluation Context]
No doubt you want your expression templates to actually /do/ something. One
approach is to define an ['evaluation context]. The context is like a function
@@ -172,7 +166,7 @@
// This prints "10"
std::cout << d << std::endl;
-[h3 Default Expression Evaluation]
+[header Default Expression Evaluation]
You might notice that the `calculator_context` has a lot of boilerplate. It
is fairly common for addition nodes to be handled by evaluating the left and
Index: extensibility.qbk
===================================================================
RCS file: /cvsroot/boost/boost/libs/xpressive/proto/doc/extensibility.qbk,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -d -r1.9 -r1.10
--- extensibility.qbk 16 Jun 2007 05:46:14 -0000 1.9
+++ extensibility.qbk 18 Jun 2007 02:56:21 -0000 1.10
@@ -5,13 +5,15 @@
/ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
/]
-[section Extending Proto]
+[section:expression_extension Expression Extension: Giving Expressions Extra
Smarts]
In this section, we'll see how to associate Proto expressions with a /domain/,
how to add members to expressions within a domain, how to control which
operators are overloaded in a domain, and how to define your own "operators".
-[h3 Domains]
+[/==============]
+[section Domains]
+[/==============]
In the examples we've seen so far, Proto has been used to construct an
expression tree that either is evaluated with the help of a /context/ or else
@@ -31,7 +33,11 @@
member function that takes a `double` and returns a `double`, like
`std::transform()` expects. What can we do?
-[h3 The [^extends<>] Expression Wrapper]
+[endsect]
+
+[/==================================================]
+[section:extends The [^extends<>] Expression Wrapper]
+[/==================================================]
The general idea is to add behaviors to the _expr_ type by wrapping it in a
class template that you define. This wrapper is associated with a domain. Proto
@@ -104,7 +110,11 @@
calculator< proto::terminal< placeholder1 >::type > const _1;
calculator< proto::terminal< placeholder2 >::type > const _2;
-[h3 Expression Generators]
+[endsect]
+
+[/============================]
+[section Expression Generators]
+[/============================]
The last thing that remains to be done is to tell Proto that it needs to wrap
all of our calculator expressions in our `calculator<>` wrapper. We have
@@ -135,7 +145,11 @@
// Use the calculator DSEL to square each element ... WORKS! :-)
std::transform( data, data + 4, data, _1 * _1 );
-[h3 Controlling Operator Overloads]
+[endsect]
+
+[/==========================================================]
+[section:inhibiting_overloads Controlling Operator Overloads]
+[/==========================================================]
By default, Proto defines every possible operator overload for Proto-ified
expressions. This makes it simple to bang together a DSEL, and Proto's grammar
@@ -311,3 +325,5 @@
expressions are automatically disabled.
[endsect]
+
+[endsect]
Index: grammars.qbk
===================================================================
RCS file: /cvsroot/boost/boost/libs/xpressive/proto/doc/grammars.qbk,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -d -r1.10 -r1.11
--- grammars.qbk 21 May 2007 03:21:34 -0000 1.10
+++ grammars.qbk 18 Jun 2007 02:56:21 -0000 1.11
@@ -5,17 +5,24 @@
/ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
/]
-[section Pattern Matching and Meta-Grammars]
+[/============================================================================================]
+[section:expression_introspection Expression Introspection: Pattern Matching
and Meta-Grammars]
+[/============================================================================================]
Expression trees can have a very rich and complicated structure. Often, you
need to know some things about an expression's structure before you can process
-it. Imagine your DSEL is a miniature I/O facility, with iostream operations
+it. This section describes the tools Proto provides for peering inside an
+expression tree and discovering its structure.
+
+[/==========================]
+[section Expression Patterns]
+[/==========================]
+
+Imagine your DSEL is a miniature I/O facility, with iostream operations
that execute lazily. You might want expressions representing input operations
to be processed by one function, and output operations to be processed by a
different function. How would you do that?
-[h3 Expression Patterns]
-
The answer is to write patterns that match the structure of input and output
expressions. Proto provides utilities for defining the patterns, and the
_matches_ template for checking whether a given expression type matches the
@@ -146,9 +153,13 @@
the first alternate of the _or_. We're done -- the pattern matches
successfully.
-[h3 Fuzzy and Exact Matches of Terminals]
+[endsect]
-They terminals in an expression tree could be const or non-const references, or
+[/===========================================]
+[section Fuzzy and Exact Matches of Terminals]
+[/===========================================]
+
+The terminals in an expression tree could be const or non-const references, or
they might not be references at all. When writing patterns, you usually don't
have to worry about it because _matches_ gives you a little wiggle room when
matching terminals. A pattern such as `proto::terminal<int>` will match a
@@ -242,7 +253,11 @@
terminal it is being matched against and see if it can match all the
constituents.
-[h3 Other Valid Patterns]
+[endsect]
+
+[/============================================================]
+[section Condition and Conjunction with [^if_<>] and [^and_<>]]
+[/============================================================]
We've already seen how to use expression generators like `terminal<>` and
`shift_right<>` as patterns. We've also seen _or_, which we can use to
@@ -269,10 +284,14 @@
[warning Do not confuse `mpl::_` with `proto::_`. The first is only useful in
MPL lambda expressions. The second is Proto's pattern wildcard. The only place
-`mpl::_` should appear in your patterns is in an _if_. Elsewhere in your
-patterns you should be using `proto::_`.]
+`mpl::_` should appear in your patterns is in an _if_, or in
tranform::applyN<>,
+as we'll see later. Elsewhere in your patterns you should be using `proto::_`.]
-[h3 Matching Vararg Functions]
+[endsect]
+
+[/================================]
+[section Matching Vararg Functions]
+[/================================]
Not all of C++'s overloadable operators are unary or binary. There is the
oddball `operator()` -- the function call operator -- which can have any number
@@ -319,7 +338,11 @@
answer is that this is a degenerate pattern that matches every possible
expression tree, from root to leaves.
-[h3 Meta-Grammars]
+[endsect]
+
+[/====================]
+[section Meta-Grammars]
+[/====================]
We've already seen how to use small patterns to answer simple questions about
expression trees. Here's a harder question: ["Does this expression conform to
the
@@ -332,17 +355,25 @@
["If Proto let me select which operators to overload, my users wouldn't be able
to create invalid expressions in the first place, and I wouldn't need a grammar
at all!] That may be true, but there are reasons for preferring to do things
-this way. First, it lets you develop your DSEL rapidly -- all the operators are
-there for you already! -- and worry about invalid syntax later. Second, it
+this way.
+
+First, it lets you develop your DSEL rapidly -- all the operators are
+there for you already! -- and worry about invalid syntax later.
+
+Second, it
might be the case that some operators are only allowed in certain contexts
within your DSEL. This is easy to express with a grammar, and hard to do with
-straight operator overloading. Third, using a DSEL grammar to flag invalid
+straight operator overloading.
+
+Third, using a DSEL grammar to flag invalid
expressions can often yield better errors than manually selecting the
-overloaded operators. Fourth, the grammar can be used for more than just
+overloaded operators.
+
+Fourth, the grammar can be used for more than just
validation. As we'll see later, you can use your grammar to define ['tree
transformations] that convert expression templates into other more useful
-objects.\n
-\n
+objects.
+
If none of the above convinces you, you actually /can/ use Proto to control
which operators are overloaded within your domain. And to do it, you need to
define a grammar! We'll see how later.
@@ -439,3 +470,5 @@
}
[endsect]
+
+[endsect]
Index: installation.qbk
===================================================================
RCS file: /cvsroot/boost/boost/libs/xpressive/proto/doc/installation.qbk,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- installation.qbk 5 May 2007 06:27:40 -0000 1.3
+++ installation.qbk 18 Jun 2007 02:56:21 -0000 1.4
@@ -7,25 +7,25 @@
[section Installing Proto]
-[h2 Getting Proto]
+[header Getting Proto]
Currently the only way to get Proto is through CVS via the boost project on
SourceForge.net. Just go to [EMAIL PROTECTED]://sf.net/projects/boost] and
follow the
instructions there for anonymous CVS access.
-[h2 Building with Proto]
+[header Building with Proto]
Proto is a header-only template library, which means you don't need to alter
your build scripts or link to any separate lib file to use it. All you need
to do is `#include <boost/xpressive/proto/proto.hpp>`. This will include the
core of Proto. If you want to use any transforms, you must include the
-appropriate header from the [^boost/xpressive/proto/transform/] directory.
+appropriate header from the [^boost\/xpressive\/proto\/transform\/] directory.
-[h2 Requirements]
+[header Requirements]
Proto depends on Boost. You must use the version in CVS HEAD.
-[h2 Supported Compilers]
+[header Supported Compilers]
Currently, Boost.Proto is known to work on the following compilers:
Index: preface.qbk
===================================================================
RCS file: /cvsroot/boost/boost/libs/xpressive/proto/doc/preface.qbk,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- preface.qbk 15 Apr 2007 06:46:57 -0000 1.4
+++ preface.qbk 18 Jun 2007 02:56:21 -0000 1.5
@@ -10,7 +10,7 @@
[:Something witty.]
[:[*['-- Someone Famous]]]
-[h2 Description]
+[header Description]
Proto is a framework for building Domain Specific Embedded Languages
in C++. It provides tools for constructing, type-checking, transforming and
@@ -23,8 +23,9 @@
* Utilities for defining the meta-grammar to which an expression must conform.
* An extensible mechanism for immediately executing an expression template.
* An extensible set of tree transformations to apply to expression trees.
+* A mechanism for giving expressions additional behaviors and members.
-[h2 Motivation]
+[header Motivation]
Expression Templates are an advanced technique that C++ library developers use
to define embedded mini-languages that target specific problem domains. The
@@ -44,7 +45,7 @@
In short, Proto is a DSEL for defining DSELs.
-[h2 Influences and Related Work]
+[header Influences and Related Work]
Proto was initially developed as part of _xpressive_ to simplify the job of
transforming an expression template into an executable finite state machine
Index: proto.qbk
===================================================================
RCS file: /cvsroot/boost/boost/libs/xpressive/proto/doc/proto.qbk,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -d -r1.19 -r1.20
--- proto.qbk 13 Jun 2007 07:13:43 -0000 1.19
+++ proto.qbk 18 Jun 2007 02:56:21 -0000 1.20
@@ -71,11 +71,31 @@
[include preface.qbk]
-[section User's Guide]
+[section:users_guide Users' Guide]
-This section describes how to use Boost.Proto to build an expression template
library.
-If you are looking for detailed information regarding specific components in
Boost.Proto,
-check the [link proto.reference Reference] section.
+This Users' Guide describes how to use Proto to build expression-template
+based Domain-Specific Embedded Langauges. It is broken up in to 5 sections,
+corresponding to the 5 major parts to Proto:
+
+[variablelist
+[[Expression Construction]
+ [Describes how to use Proto to build expression trees.]]
+[[Expression Evaluation]
+ [Describes the tools Proto provides for making your expression trees do
+ something useful.]]
+[[[link boost_proto.users_guide.expression_introspection Expression
Introspection]]
+ [Describes Proto's pattern matching and meta-grammar faciities, which make
+ it easy to discover the structure of an expression tree.]]
+[[[link boost_proto.users_guide.expression_transformation Expression
Transformation]]
+ [Describes how to write expression transforms that turn an expression tree
+ into some other object.]]
+[[[link boost_proto.users_guide.expression_extension Expression Extension]]
+ [Describes how to extend Proto expressions with additional behaviors and
+ members.]]
+]
+
+But before we get started, let's have a look at some very simple Proto examples
+and say a few words about Proto's philosophy.
[include installation.qbk]
@@ -95,5 +115,14 @@
[xinclude protodoc.xml]
+[section Appendices]
+
+[include history.qbk]
+
+[include rationale.qbk]
+
+[include implementation.qbk]
+
[include acknowledgements.qbk]
+[endsect]
Index: quick_start.qbk
===================================================================
RCS file: /cvsroot/boost/boost/libs/xpressive/proto/doc/quick_start.qbk,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -d -r1.11 -r1.12
--- quick_start.qbk 21 May 2007 03:21:34 -0000 1.11
+++ quick_start.qbk 18 Jun 2007 02:56:21 -0000 1.12
@@ -5,12 +5,7 @@
/ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
/]
-[section Quick Start]
-
-In this section, we'll see a simple ['hello world] for Proto and take a quick
-tour of the types and functions Proto provides.
-
-[h2 Hello, world!]
+[section Hello World]
Below is a very simple program that uses Proto to build an expression template
and then execute it.
@@ -83,72 +78,4 @@
particular domain. But that is not the default behavior. We'll see later why
the default is often a good thing.]
-[h2 Proto's Tool-Box]
-
-Let's begin with the nickel tour of the utilities Proto provides.
-
-[table Proto's Tool-Box
- [[Tool] [Description]]
- [[_expr_] [The structure from which Proto's expression
- trees are built.]]
- [[_arg_, _arg_c_] [For extracting the ['N]th child expression
- from a Proto expression tree.]]
- [[_left_, _right_] [For extracting the left or right child
- expression from a binary Proto expression
- tree.]]
- [[_eval_] [A Proto expression evaluator. Given an
- expression and a /context/, it evaluates
- the expression in that context.]]
- [[_default_context_] [An evaluation context for use with _eval_
- which assignes the standard meanings to the
- operators and uses Boost.Typeof to deduce
- return types.]]
- [[_callable_context_] [An alternate evaluation context that is easier
- to use in some situations.]]
- [[_deep_copy_] [A function for transforming an expression
- tree such that all nodes are held by value
- instead of by reference.]]
- [[_as_expr_, _as_arg_] [_as_expr_ is a function that Proto-ifies an
- object if it is not already a Proto
- expression. _as_arg_ is similar except
- the argument is stored by reference.]]
- [[_terminal_, _unary_expr_,
- _binary_expr_, /etc./] [Expression type generators. For example,
- `shift_right<A, B>::type` is the type
- of a right-shift expression with `A` and
- `B` as children. These are also used for
- specifying productions in meta-grammars.]]
- [[_matches_] [A compile-time predicate for determining
- whether an expression type matches a
- given meta-grammar.]]
- [[_or_] [For specifying alternate productions in a
- Proto meta-grammar.]]
- [[_and_] [For specifying a compound production in a
- Proto meta-grammar.]]
- [[_if_] [Allows an arbitrary compile-time predicate
- to be used as a production in a Proto
- meta-grammar.]]
- [[_exact_] [Used to specify that a terminal type must
- match exactly in a Proto meta-grammar.
- (By default, matches are ['fuzzy].)]]
- [[_extends_] [A domain-specific wrapper for giving an
- expression additional behaviors.]]
- [[_literal_, _lit_] [A wrapper for a Proto terminal, and a function
- for generating them, respectively.]]
- [[_is_expr_] [Tests a type to see if it is a Proto
- expression type.]]
- [[_tag_of_] [Meta-function which returns the node type
- of the specified expression.]]
-]
-
-[/
- [[_make_expr_] [A function for building a Proto expression
- given a node type and children
expressions.]]
- [[_unpack_expr_] [Like _make_expr_, except the children
- expressions are in a Fusion sequence.]]
-]
-
-Now that you know a bit about the tools Proto provides, let's look at how to
-use them to implement some domain-specific embedded languages.
-
[endsect]
Index: transforms.qbk
===================================================================
RCS file: /cvsroot/boost/boost/libs/xpressive/proto/doc/transforms.qbk,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -d -r1.14 -r1.15
--- transforms.qbk 16 Jun 2007 18:32:36 -0000 1.14
+++ transforms.qbk 18 Jun 2007 02:56:21 -0000 1.15
@@ -7,9 +7,9 @@
[import ../test/examples.cpp]
-[/===========================]
-[section Tree Transformations]
-[/===========================]
+[/==========================================================]
+[section:expression_transformation Expression Transformation]
+[/==========================================================]
Sometimes, rather than immediately executing an expression template, you'd
like to transform it into some other object. Maybe the transformation is
simple,
@@ -18,9 +18,9 @@
regular expression. Proto provides a framework for applying tree
transformations and several canned transformations that are generally useful.
-[/=========================]
-[h3 Transformation Overview]
-[/=========================]
+[/===============]
+[heading Overview]
+[/===============]
Defining tree transformations involves defining the meta-grammar for your DSEL
and decorating it with transformations. Each rule in your meta-grammar will
@@ -53,9 +53,9 @@
That's it, in a nutshell. Now let's crack this nut and peek inside.
-[/====================]
-[h3 Defining a Grammar]
-[/====================]
+[/==========================================]
+[section Example: Calculator Arity Transform]
+[/==========================================]
Let's have another look at our trusty calculator example. If you recall, the
calculator allows the lazy evaluation of arithmetic expressions, with
@@ -72,6 +72,10 @@
will be to write a transform that calculates the arity of any calculator
expression.
+[/=========================]
+[heading Defining a Grammar]
+[/=========================]
+
First, we must write the grammar for the calculator. It's really very simple.
Calculator expression can be made up of any combination of 5 constituents:
@@ -93,9 +97,9 @@
for which the operand matches CalculatorGrammar (the `_` matches any operator
tag).
-[/=======================]
-[h3 Writing the Transform]
-[/=======================]
+[/============================]
+[heading Writing the Transform]
+[/============================]
It's straightforward to describe in words how the arity of an expression should
be calculated. First, we describe the arity of each of the 5 constituents in
@@ -142,7 +146,7 @@
That begs the question, what does `unary_expr<>`'s transform do? Well,
`unary_expr< _, CalculatorGrammar >` has a default transform
associated with it. It is a /pass-through/ transform. When an expression
-of the form `expr< T, arg1< X > >` is passed to the transform, it's `apply<>`
+of the form `expr< T, arg1< X > >` is passed to the transform, its `apply<>`
member template will invoke the `CalculatorGrammar` transform (which we haven't
completely defined yet -- patience) on `X` resulting in `Y`, and then
reassemble the expression as `expr< T, arg1< Y > >`.
@@ -247,9 +251,11 @@
(Aside: this uses the fact that `mpl::int_<1>` has a conversion to `int(1)`.)
-[/===================]
-[h3 Canned Transforms]
-[/===================]
+[endsect]
+
+[/========================]
+[section Canned Transforms]
+[/========================]
Some transforms are generally useful, so Proto provides them. They are
described below. Each is of the form:
@@ -263,7 +269,7 @@
the return type of `call()`. The tables below show what `call()` and `apply<>`
do for each of the transforms that Proto provides.
-[h4 [^arg<>], [^arc_c<>], [^left<>] and [^right<>]]
+[section:arg_c_and_friends [^arg<>], [^arc_c<>], [^left<>] and [^right<>]]
namespace boost { namespace proto { namespace transform
{
@@ -322,7 +328,9 @@
: transform::arg< terminal<int> >
{};
-[h4 [^identity<>], [^state<>] and [^visitor<>]]
+[endsect]
+
+[section:identity_and_friends [^identity<>], [^state<>] and [^visitor<>]]
namespace boost { namespace proto { namespace transform
{
@@ -373,7 +381,9 @@
: transform::identity< subscript<MyGrammar, MyGrammar> >
{};
-[h4 [^always<>]]
+[endsect]
+
+[section:always [^always<>]]
namespace boost { namespace proto { namespace transform
{
@@ -405,7 +415,9 @@
: transform::always< terminal<placeholder1>, mpl::int_<1> >
{};
-[h4 [^apply1<>], [^apply2<>] and [^apply3<>]]
+[endsect]
+
+[section:applyn [^apply1<>], [^apply2<>] and [^apply3<>]]
namespace boost { namespace proto { namespace transform
{
@@ -469,7 +481,9 @@
>
{};
-[h4 [^branch<>]]
+[endsect]
+
+[section:branch [^branch<>]]
namespace boost { namespace proto { namespace transform
{
@@ -498,33 +512,9 @@
See the [link reverse_fold_example [^reverse_fold<>] example].
-[/
- // This transform matches function invocations such as foo(1,'a',"b")
- // and transforms them into fusion cons lists of their arguments. In this
- // case, the result would be cons(1, cons('a', cons("b", nil()))).
- struct ArgsAsList
- : transform::branch<
- transform::reverse_fold<
- function<
- // This effectively skips the first argument, which is
- // the function being invoked; in this case, "foo".
- transform::state<terminal<_> >
- , vararg<
- // Put the rest of the args in a fusion cons list:
- transform::list<
- // Extract the arguments from the terminals:
- transform::arg<terminal<_> >
- >
- >
- >
- >
- // The whole thing uses fusion::nil as the initial state
- , fusion::nil
- >
- {};
-]
+[endsect]
-[h4 [^compose<>]]
+[section:compose [^compose<>]]
namespace boost { namespace proto { namespace transform
{
@@ -578,7 +568,9 @@
>
{};
-[h4 [^conditional<>]]
+[endsect]
+
+[section:conditional [^conditional<>]]
namespace boost { namespace proto { namespace transform
{
@@ -615,7 +607,9 @@
>
{};
-[h4 [^list<>]]
+[endsect]
+
+[section:list [^list<>]]
namespace boost { namespace proto { namespace transform
{
@@ -648,7 +642,9 @@
See the [link reverse_fold_example [^reverse_fold<>] example].
-[h4 [^fold<>] and [^reverse_fold<>]]
+[endsect]
+
+[section:fold [^fold<>] and [^reverse_fold<>]]
namespace boost { namespace proto { namespace transform
{
@@ -739,7 +735,9 @@
[AsArgList]
-[h4 [^fold_tree<>] and [^reverse_fold_tree<>]]
+[endsect]
+
+[section:fold_tree [^fold_tree<>] and [^reverse_fold_tree<>]]
namespace boost { namespace proto { namespace transform
{
@@ -811,7 +809,9 @@
[FoldTreeToList]
-[h4 [^construct<>]]
+[endsect]
+
+[section:construct [^construct<>]]
namespace boost { namespace proto { namespace transform
{
@@ -900,7 +900,9 @@
short-cut syntax for nested constructors does not work on MSVC due to compiler
bugs.]
-[h4 [^pass_through<>]]
+[endsect]
+
+[section:pass_through [^pass_through<>]]
namespace boost { namespace proto { namespace transform
{
@@ -950,3 +952,7 @@
[Promote]
[endsect]
+
+[endsect]
+
+[endsect]
Index: Jamfile.v2
===================================================================
RCS file: /cvsroot/boost/boost/libs/xpressive/proto/doc/Jamfile.v2,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- Jamfile.v2 29 Mar 2007 22:19:39 -0000 1.7
+++ Jamfile.v2 18 Jun 2007 02:56:21 -0000 1.8
@@ -55,8 +55,42 @@
:
proto
:
- <xsl:param>toc.max.depth=3
- <xsl:param>toc.section.depth=3
- <xsl:param>chunk.section.depth=3
+ # HTML options first:
+ # Use graphics not text for navigation:
+ <xsl:param>navig.graphics=1
+ # How far down we chunk nested sections, basically all of them:
+ <xsl:param>chunk.section.depth=10
+ # Don't put the first section on the same page as the TOC:
+ <xsl:param>chunk.first.sections=1
+ # How far down sections get TOC's
+ <xsl:param>toc.section.depth=10
+ # Max depth in each TOC:
+ <xsl:param>toc.max.depth=4
+ # How far down we go with TOC's
+ <xsl:param>generate.section.toc.level=10
+ # Set the path to the boost-root so we find our graphics:
+ #<xsl:param>boost.root=../../../../..
+ # location of the main index file so our links work:
+ #<xsl:param>boost.libraries=../../../../../libs/libraries.htm
+
+ # PDF Options:
+ # TOC Generation: this is needed for FOP-0.9 and later:
+ # <xsl:param>fop1.extensions=1
+ <xsl:param>xep.extensions=1
+ # TOC generation: this is needed for FOP 0.2, but must not be set to
zero for FOP-0.9!
+ <xsl:param>fop.extensions=0
+ # No indent on body text:
+ <xsl:param>body.start.indent=0pt
+ # Margin size:
+ <xsl:param>page.margin.inner=0.5in
+ # Margin size:
+ <xsl:param>page.margin.outer=0.5in
+ # Yes, we want graphics for admonishments:
+ <xsl:param>admon.graphics=1
+ # Set this one for PDF generation *only*:
+ # default pnd graphics are awful in PDF form,
+ # better use SVG's instead:
+ # <xsl:param>admon.graphics.extension=".svg"
+
# <dependency>protodoc
;
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-cvs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/boost-cvs
