Boost logo

Boost :

From: Larry Evans (cppljevans_at_[hidden])
Date: 2004-12-12 14:15:06

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:


and the code in:


I believe is much simpler to understand and doesn't use
any preprocessor macros. It uses enumerations instead
of unsigned constants to access the tuple elements; however,
the 1st version did use constants. There might as well
be two versions, which could easily be done. In addition,
the same can be said for sum.hpp which uses essentially the
same code.

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 (+). However, in addition,
if variant (i.e. sum) is thrown onto the scales, then I believe
easier undestanding wins. In addition, I think sum can
be modified by adding:

      if(index() == Index)
      { a_viz(mpl::int_c<Index>(), project<Index>());}
      { term<...,Index-1>::accept(a_viz);}

which is essentially the visitor pattern.

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?

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