From: Maurizio Vitale (mav_at_[hidden])
Date: 2007-04-27 01:49:26
I think the documentation for transforms could be improved by giving
apply and call equal importance and emphasizing the fact that apply
computes compile time information (and not necessarily, I think, only
the type of call) while call is a method that can be called at
The documentation right now says:
A meta-grammar decorated with transforms has a static member function named
`call()` which takes three parameters:
* `expr` -- the expression to transform
* `state` -- the state of the transformation so far
* `visitor` -- any optional auxiliary mutable state information
It also has a nested `apply<>` template which is used to calculate the return
type of the `call()` member function.
The static `call()` member function is needed to complete the transform
interface. It simply returns a default-constructed object, which will be an
instantiation of `mpl::int_<>`.
This leads one to believe that both are necessary (otherwise the
interface would be 'incomplete' as hinted by the second sentence) and
that all apply is supposed to do is to compute the return type for
call. Further, the first fragment make one think that call() is the
important thing and apply is just an ancillary metafunction.
The example calc3 was the one that cleared things up for me: there
only apply is defined, but more importantly comments around the
commented out call() method talks about the unneeded 'run-time
counterpart for the transform'. I think this dichotomy should be made
more clear in the documentation.
An example where the runtime part does more than just reifying the
compiletime side, by generating more complex code might also be usful.
I might have something that computes code for overflow handling and/or
(more complex) quantization handling, if only I could make it work
I'm sure there's code that does this in xpression as well, but that
code is probably a bit too complex for beginners.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk