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