Re: [boost] Proto<markus>::review()(proto::accept);

From: Eric Niebler (eric_at_[hidden])
Date: 2008-04-04 18:15:19

Eric Niebler wrote:
> Markus Werle wrote:
>>
>> Proto is well-designed in many aspects, though I got the
>> impression that some beauty and purity was sacrificed
>> on the altar of compile-time efficiency, but that's OK.
> 
<snip>
> 
> One deficiency I'd like to address someday is the fact that transforms 
> do not support the full TR1 ResultOf protocol. I'm still looking for an 
> efficient solution to that one.

FYI, I think I finally have a solution to this problem, and a bunch of 
others to boot. I got the idea from looking over the Egg library 
(thanks, Shunsuke!). Rather than writing primitive transforms as TR1 
function objects directly, you'll use a helper that generates the 
ResultOf stuff for you. Transforms will now look like this:

   struct MyPrimitiveTransform
     : proto::transform< MyPrimitiveTransform >
   {
       // nested ternary impl<> function object:
       template<class Expr, class State, class Data>
       struct impl
         : proto::transform_impl<Expr, State, Data>
       {
           typedef ... result_type;

           result_type operator()(
               typename impl::expr_param expr
             , typename impl::state_param state
             , typename impl::data_param data
           ) const
           {
               return ...;
           }
       };
   };

Doing it this way has the following advantages:

* MyPrimitiveTransform is a proper TR1 function object.
* When invoked as a function object, the state and data
   parameters are optional. (David Jenkins requested this
   feature.) All of Proto's primitive transforms can be
   defined this way, so that you'll never have to pass
   dummy state and data arguments.
* Transforms are now lvalue/rvalue aware. That is, the Expr,
   State, and Data template parameters can be references.
* The data object can now be const (it had to be non-const
   before)
* The expr object can now be non-const (it had to be const
   before)
* Because of the proper rvalue/lvalue handling, the
   functionality of proto::default_context can now be
   provided as a transform.

It has a modest impact on compile times, but considering the above 
advantages, I think it's worth it.

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com