From: David Abrahams (dave_at_[hidden])
Date: 2005-11-03 16:55:59
Joel de Guzman <joel_at_[hidden]> writes:
> Comments, feedback very welcome!
> The Actor is the main concept behind the library. Actors are
> function objects (functors). An actor can accept 0 to N arguments
> (where N is a predefined maximum).
What does that mean? If I define a function object that accepts fewer
than N arguments it can't be an Actor? What is N really? Why not
give the actual symbolic name here?
> You can set PHOENIX_LIMIT, the predefined maximum arity an actor can
> take. By default, PHOENIX_LIMIT is set to 10.
Ah, there it is. Still, the use of N seems superfluous.
> While the Actor is a concept representing a function, there is also
> the actor template class which models the concept. The template
> class has a sole template parameter, Eval, from which it derives
> from. The actor class doesn't have the smarts to actually evaluate
> the function, Eval does. Eval is a concept, representing the
> function body (i.e. the implementation of the function).
Rewrite that paragraph:
Phoenix supplies an actor class template whose specializations
model the Actor concept. actor has one template parameter, Eval,
that supplies the smarts to actually evaluate the resulting
It's too early to say that Eval must conform to the Eval concept.
> template <typename Eval>
> struct actor : Eval
> operator()() const;
> template <typename T0>
> operator()(T0& _0) const;
> template <typename T0, typename T1>
> operator()(T0& _0, T1& _1) const;
> The actor class accepts the arguments through a set of function call
> operators for 0 to N arities (Don't worry about the details, for
> now. For example, note that we skimp over the details regarding
> return_type, above). The arguments are then forwarded to the actor's
> Eval for evaluation.
As long as you're doing this you could solve the forwarding problem
for the first N arguments with 2^N overloads for some reasonable N,
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk