Boost logo

Boost :

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
>> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at