Re: [boost] Alternative solution to intermediate results problem of expression templates.

From: Korcan Hussein (korcan_h_at_[hidden])
Date: 2005-10-21 16:37:18

"Larry Evans" <cppljevans_at_[hidden]> wrote in message 
news:djbj4j$g62$1_at_sea.gmane.org...
> On 10/21/2005 03:05 PM, Korcan Hussein wrote:
>> I think I may have come up with an alternative solution to the type
>> deduction of intermediate results from expression templates.
>
> I'm afraid I don't know what:
>
>    type deduction of intermediate results from expression templates
>
> means.  Could you explain more with examples?

I'll make a quote from the boost MPL book :-)

[quote]
One drawback of expression templates is that they tend to encourage writing 
large, complicated expressions, because evaluation is only delayed until the 
assignment operator is invoked. If a programmer wants to reuse some 
intermediate result without evaluating it early, she may be forced to 
declare a complicated type like:

Expression<
    Expression<Array,plus,Array>
  , plus
  , Expression<Array,minus,Array>
> intermediate = a + b + (c - d);

(or worse). Notice how this type not only exactly and redundantly reflects 
the structure of the computationand so would need to be maintained as the 
formula changesbut also overwhelms it? This is a long-standing problem for 
C++ DSELs. The usual workaround is to capture the expression using type 
erasure, but in that case one pays for dynamic dispatching.

There has been much discussion recently, spearheaded by Bjarne Stroustrup 
himself, about reusing the vestigial auto keyword to get type deduction in 
variable declarations, so that the above could be rewritten as:

auto intermediate = a + b + (c - d);

This feature would be a huge advantage to C++ DSEL authors and users alike.
[/qoute]

Since the change of auto keyword isn't with  us yet probably not at least 
till C++0x and compiler vendors start implementing it i think i may have a 
better alternative to type erasor (unless it's already in use or have been 
discussed about). I think it would be very useful to libraries such as uBlas 
and Spirit.

>>
>> Instead of using automatic type erasing technique, take the compile-time
>
> What is this "type erasing technique"?
>

Boost.Any is one example where type erasing is used, basically you keep 
richful type info to the very last possible moment and then lose most of it 
in a polymophic type and use dynamic dispatching etc. So it's like your 
erasing the type, would you like a code example? ;)

>> parse tree of an intermediate expression and create an exact runtime 
>> replica
>> of the expression tree using recursive variant types (using Boost.Variant 
>> in
>> C++). The creation of the expression tree can be completely automated.
>
> Why would you want a runtime replica?  I suppose to solve the "type
> deduction of intermediate results" problem mentioned above, but, as
> I've said, I don't know what this is :(
>

I think that should make a little more sense now, if not i can explain some 
more if need be ;)