boost::proto documentation for transforms
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 run-time. 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. and later: 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 with proto... I'm sure there's code that does this in xpression as well, but that code is probably a bit too complex for beginners. Regards, Maurizio
Maurizio Vitale wrote:
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.
Thanks for the feedback.
An example where the runtime part does more than just reifying the compiletime side, by generating more complex code might also be usful.
I agree. I need an example where the call() function actually does something. I also need to show the State parameter getting used. Maybe I'll show how the fold_to_list<> transform works. FYI, it converts expressions like: a >> b >> c or a | b | c to fusion cons lists like: cons< a, cons< b, cons< c > > >
I might have something that computes code for overflow handling and/or (more complex) quantization handling, if only I could make it work with proto...
You might look at the fold<> transform (I suggest you run the sources through the preprocessor first). And then try to wrap your head around the fold_to_list<> transform to see how the runtime component of the transform works. Once you understand that, you'll know proto's transforms inside and out. -- Eric Niebler Boost Consulting www.boost-consulting.com
On 04/27/2007 10:59 AM, Eric Niebler wrote: [snip]
You might look at the fold<> transform (I suggest you run the sources through the preprocessor first). And then try to wrap your head around the fold_to_list<> transform to see how the runtime component of the transform works. Once you understand that, you'll know proto's transforms inside and out.
Eric, I've tried to get boost build to create a preprocessor output file without success. I've had to use make to do that; consequently, I've had to have 2 methods of building. Have you been able to create some boost build v2 rules that produce the preprocessor output? If so, could you publish it. I did pose this question to the boost build list: http://article.gmane.org/gmane.comp.lib.boost.build/14930 but got no answer there :( TIA. -regards, Larry
Larry Evans <cppljevans@cox-internet.com> writes:
On 04/27/2007 10:59 AM, Eric Niebler wrote: [snip]
You might look at the fold<> transform (I suggest you run the sources through the preprocessor first). And then try to wrap your head around the fold_to_list<> transform to see how the runtime component of the transform works. Once you understand that, you'll know proto's transforms inside and out.
Eric,
I've tried to get boost build to create a preprocessor output file without success. I've had to use make to do that; consequently, I've had to have 2 methods of building. Have you been able to create some boost build v2 rules that produce the preprocessor output? If so, could you publish it. I did pose this question to the boost build list:
I simply do it by hand, going to the directory containing (for instance) fold.hpp and running: g++ -E -P -C -I<top of boost tree> -xc++ fold.hpp > fold.pp regards, Maurizio
Larry Evans wrote:
On 04/27/2007 10:59 AM, Eric Niebler wrote: [snip]
You might look at the fold<> transform (I suggest you run the sources through the preprocessor first). And then try to wrap your head around the fold_to_list<> transform to see how the runtime component of the transform works. Once you understand that, you'll know proto's transforms inside and out.
Eric,
I've tried to get boost build to create a preprocessor output file without success.
I don't know. I use (on windows) "cl /I %BOOST_ROOT% /P fold.hpp". That creates fold.i with the preprocessed output. Maybe a BBv2 expert knows? Maybe there is a <preprocess>yes feature, or someone could add one. -- Eric Niebler Boost Consulting www.boost-consulting.com
participants (3)
-
Eric Niebler -
Larry Evans -
Maurizio Vitale