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. 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: 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. 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?