[boost] Re: mpl::inherit_linearly reuse to produce loki's tuple?

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-12 22:16:21

Larry Evans wrote:
> On 12/12/2004 08:44 AM, David Abrahams wrote:
>> 
>> I don't think so.  What would we gain by it?
> Code reuse and hence easier understanding, especially
> if very similar code can be used for variant.
>> 
>> The successor to Boost.Tuple is described in
>> http://www.boost.org/libs/spirit/fusion/readme.txt.  Since fusion tuples
>> are "flat" structures, there's no win in building them by repeated
>> folding of an input sequence.
> I've just looked today briefly at:
> 
>    boost/spirit/fusion/sequence/tuple.hpp
> 
> and the code in:
> 
>    boost-sandbox/boost/indexed_types/product.hpp
> 
> I believe is much simpler to understand and doesn't use
> any preprocessor macros.  

Yes, but it is much less efficient for some applications.  The fusion
design was carefully refined for both runtime and compile-time speed.
It is a complete hybrid compile-time/runtime framework just like the MPL
is a complete compile-time framework, and it integrates well with MPL
(every fusion sequence is also an MPL sequence).  This wasn't just done
lightly; it's the result of a careful and comprehensive design process.

> I'm guessing that the "flatness" of fusion tuples is done by
> simply creating different field names with corresponding types
> by means of preprocessing macros.  If so, then deciding
> on either indexed_types/product.hpp or fusion/tuple.hpp
> amounts to deciding between proprocessing marcros (-)
> and flatness(?) vs n-level inheritance heirarchy (-)
> and easier understanding (+).  

Understanding the implementation of fusion isn't important, except to
its maintainer.

> However, in addition, if variant (i.e. sum) 
> is thrown onto the scales, then I believe
> easier undestanding wins.  

Maybe you're not the best judge of easy understanding.
What does variant have to do with sum?  It's completely non-obvious to me.

> In addition, I think sum can
> be modified by adding:
> 
>    term<...Index>::accept(visitor&a_viz)
>    {
>       if(index() == Index)
>       { a_viz(mpl::int_c<Index>(), project<Index>());}
>       else
>       { term<...,Index-1>::accept(a_viz);}
>    }
> 
> which is essentially the visitor pattern.

You've lost me completely.

> What I'm also searching for is something that satisfies:
> 
>    list<T> == sum<null_type, product<T,list<T>*>
> 
> which, I think, could be used as a replacement for the
> recursive variants; yet, use sum and product just
> like or similar to the way the disjoint sum and cartesion
> product are used in textbooks to define a linked list.
> Any ideas on how this could be done?

still lost.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com