On 01/04/2005 11:52 AM, christopher diggins wrote: [snip]

The advantages (and my motivation for creating it) of the union-list is that it requires no other boost libraries and has a very tiny code base. Another difference ( but not neccessarily an advantage ) of the union-list is that it uses and provides an index to access the type of its contents. These same advantages (AFAICT) are provided by the code reference by:

http://thread.gmane.org/gmane.comp.lib.boost.devel/115072 More specifically, by the sum.hpp code. In addition, that code shares almost the same code with product.hpp and doesn't use any extra memory. I'm still developing the code and the successors are in the same indexed_types directory in files: composite_sum composite_product However, as you can see by the above thread, there's some question about the advantages vs. the existing boost tuple and variant types. So for, I can't see how there could be since the memory is minimal and access time (AFAICT) can't be much faster since accesses are simply done by directly naming the supertype (via the Index template argument) containing the required tuple or variant member. My understanding is that Joel will answer the question when he has the time.

christopher diggins wrote:

In general I am curious about how other boosters feel about boost library sizes and inter-library couplings. For me this is a big obstacle to using boost in many circumstances. It doesn't seem to be a concern at all for the boost community, but I wonder if other programmers have similar sentiments and find themselves often seeking out simpler alternatives.

It's good to reduce coupling. It's good to keep libraries small. That said... The point of code libraries is to do things once well, rather than a thousand times poorly. Library designers and application programmers alike should avail themselves of that resource. I wouldn't forego using a boost library in another library just for the sake of avoiding a dependency, especially if it meant I was duplicating functionality. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

On 01/04/2005 11:52 AM, christopher diggins wrote:

I have written a union-style type similar to boost::variant which allows [snip] 2. the data size is huge = summation of the size of the individual types plus sizeof(bool) * #types.

Could you use the method for our_storage_size in: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/indexed_types/composite_sum.hpp?rev=1.2&view=auto To calculate the maximum of the individual sizes and then just allocate storage for this max size? [snip]

union-list is that it uses and provides an index to access the type of its contents.

This, IMHO, is important. In the above indexed_types directory, there's typemap_unsigned.hpp which allows using unsigned indices instead of enumerations to access the elements. This was designed to allow the convenience of mpl's sequences; however, it also requires the possibly time consuming use of mpl's at_c and size. I don't know if it's really a significant time consumer, but it'd be nice if your method could somehow be adapted to avoid this. I've tried to think of a way to use mpl's inherit_linearly; however, I think it can't be done because, in order to use indexed accesss, all the type arguments of the inherited classes have to be identical except for the index. Maybe someone else can think of a workaround?