[boost] Re: unions

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-08 10:35:45

Daniel Wallin <dalwan01_at_[hidden]> writes:

> At 14:39 2003-10-08, David Abrahams wrote:
>>Eric Friedman <ebf_at_[hidden]> writes:
>>
>> > David Abrahams wrote:
>> >
>> >> "E. Gladyshev" <egladysh_at_[hidden]> writes:
>> >>>[...]
>> >>>So you decided that it is worth to make the first type special.
>> >>>Well, seems like a strange justification to me but anyway...
>> >> Me too, FWIW.  In generic code it may not be so easy to control the
>> >> properties of the type which comes first.
>> >
>> > My point, though, is why does it matter?
>> >
>> > It seems unlikely to me that the specification on some generic code
>> > would be:
>> >
>> >    "One of these types must be nothrow default-constructible."
>> >
>> > In my opinion, the ability to turn off heap backup for variant should
>> > be seen as an optimization (i.e., as it prevents costly heap
>> > allocation) and not any sort of interface feature. Please disagree
>> > with me though.
>>
>>If it really didn't matter to be able to get it, there would be no
>>point in providing the capability at all.  If you don't provide the
>>checking in the library, a generic program which _wants_ the benefit
>>of the optimization would have to implement not only the *search* for
>>a nothrow default-constructible type, but also the code to rearrange
>>the types so that it comes first.  Seems like a bad tradeoff to me.
>
> What's wrong with simply adding a nothrow default-constructible type to
> the variant, like Eric demonstrated?

You mean like prepending char?  I missed that, but anyway, it changes
the invariant of the type you get back.  At that point, it might not
contain any of the types you wanted.  It almost becomes equivalent to
a design Eric rejected, where the variant can be empty.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com