Re: [boost] [proto] design of expr<>

From: Eric Niebler (eric_at_[hidden])
Date: 2008-03-22 23:26:07

Steven Watanabe wrote:
> AMDG
> 
> Larry Evans wrote:
>> To make x2 compile, add an extra {}, IOW
>>
>>    x2 = { { {1}, {1} } }
>>
>> where the extran {} is for expr2::args.
>>
>> So, the cost of this extra indirection is
>> 1 more curly braces in
>> every expr initializer list?
>>   
> 
> Exactly.  If you recall I said that it changes the interface.  Not
> that it doesn't work.  In short, the existence of the "private"
> partially specialized version of expr would not entirely be an
> implementation detail.
> 
> This may also add overhead because of the extra template.
> On the other hand, it may compile faster because the operator()
> overloads don't need to be duplicated.
> 
> Oh.  I just realized that this would also force expr::make to change.
> expr::make() takes a number of arguments equal to the arity so it
> needs to be in the private struct as well.  I'm afraid that this would
> ripple across the library, and turn out to be a not so minor change, after
> all.

Yes, I've played with a similar design, and I've found it to cause 
initialization to be rather tricky. Consider the following 
initializations today:

   terminal<int>::type t = {1};
   plus<
       terminal<int>::type
     , terminal<int>::type
   >::type u = {{1}, {1}};

That's fairly straightforward. With an extra set of braces with each 
expr, it becomes the rather unwieldy:

   terminal<int>::type t = {{1}};
   plus<
       terminal<int>::type
     , terminal<int>::type
   >::type u = {{{{1}}, {{1}}}};

That hurts my eyes.

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