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

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
paper?

Thanks,
David Brownstein

----- Original Message -----
From: "Itay" <itay_maman_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
To: <boost_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...).
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
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost