Re: [boost] Re: unions

From: Daniel Wallin (dalwan01_at_[hidden])
Date: 2003-10-08 12:21:24

At 17:35 2003-10-08, David Abrahams wrote:
>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?

Right, or boost::empty.

>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.

I don't yet buy that this is a problem for generic programming;

If variant is part of the program interface, the type shouldn't be changed
anyway, so "wanting the benefit of the optimization" becomes the users
problem.

If the variant is part of the implementation, where the type sequence
is part of the interface, the invariant type is just an implementation
detail, or part of the program documentation.

---
Daniel Wallin