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
version has been successfully tested on GCC 3.0.4, MSVC 6.
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
- 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
- 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.
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk