From: David (David_at_[hidden])
Date: 2002-07-09 19:06:32
The cited reference http://oonumerics.org/tmpw01/alexandrescu.pdf is
unfortunately no longer valid- does anyone know where I might now find this
----- Original Message -----
From: "Itay" <itay_maman_at_[hidden]>
Sent: Tuesday, July 09, 2002 5:31 PM
Subject: [boost] boost::variant 0.2 (was: Yet another variant class)
> 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...).
> 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
> 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
> 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
> pay attention to a special type (neutral_tag): This type is the initial
> 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
> 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")
> is also recommended.
> GCC: -ftemplate-depth-99
> Feedback would be highly appreciated. Specifically, I would like to know
> 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.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk