[boost] boost::variant 0.2 (was: Yet another variant class)

From: Itay (itay_maman_at_[hidden])
Date: 2002-07-09 19:31:05

I just uploaded the recent version of boost::variant to the file section
(http://groups.yahoo.com/group/boost/files/boost_variant_100702.zip) This
version has been successfully tested on GCC 3.0.4,  MSVC 6.

What's new?
The interface now meets all critical requirements, hence, I believe it has
reached its final form (unless public opinion would say otherwise...). Most
important modifications are: complete boost::any-like interface, and the
'easy instantiation' option:
    variant<BOOST_RDSL_3(int, char, double)> v1;
    variant<int, char, double > v2;   //  Easy!

As for implementation details, many modifications/tweaks were needed,
primarily to satisfy MSVC6. Here are the key points:

- Type-list manipulation is encapsulated within boost::rdsl (Reduced
Dot-Style List), defined in rdsl.hpp. This file wraps boost::mpl::list
functionality but also offers an alternative dot-style based implementation.
Thus, variant.hpp can use either boost::mpl ::list, or dot-style lists
depending on the compiler's compatibility with boost::mpl.

- Memory overhead has been reduced to 4 bytes (a single pointer).
stack_holder<> now uses the full vtable idiom (suggested by Andrei
Alexandrescu, http://oonumerics.org/tmpw01/alexandrescu.pdf).

- The overload resolution-like mechanism also had to be changed. Under MSVC,
it uses an iterative algorithm which applies the "choose_conversion" trick
(This trick was suggested by Eric Friedman,
http://aspn.activestate.com/ASPN/Mail/Message/1264796). The result of the
last iteration is the "best conversion" type. Naturally, the algorithm must
pay attention to a special type (neutral_tag): This type is the initial type
we start with. If we end up with this type, no conversion is possible. I
specialized choose_conversion_impl<>, such that neutral_tag is 'thrown out'
when it is compared to a convertible type, but 'wins' when compared to a
non-convertible type.

- Right now, boost::variant can be instantiated with up to 20 types. This
limit can be by-passed by using the dot-style interface:
    variant<BOOST_RDSL_25(t1, t2, t3, ... t25)> huge_variant;

    Note that programs with 'loaded' variants may trigger compiler errors
(e.g: out of heap memory). Here are the relevant compiler switches:
        MSVC: /Zm250 - "Increase heap by 250%".
                    Getting rid of the /Gm ("Enable minimal rebuild") switch
is also recommended.

       GCC: -ftemplate-depth-99

Feedback would be highly appreciated. Specifically, I would like to know if
the code is compatible with other compilers.

Another key point is the development of variant-based, higher-level
components: There are many software components which can benefit from
variants. The question is which of these components (if any) should be
included in the boost::variant library. My personal view is that we should
stick to the minimal+ interface principle: (In general) the library should
not include components which only depend on boost::variant's public
interface.

One last comment: Having failed to convince Eric Friedman that co-writing
this library would be more effective, from boost standpoint, than the solo
approach, I carried on with developing boost::variant. When I look at the
code I keep getting the feeling that we both struggled thru the same
problems, which is too bad.

-Itay