[boost] Re: Re: Empty boost::variant semantics(wasRe:Re:Mini-reviewrequest: aligned_storage.hpp)

From: Itay Maman (itay_maman_at_[hidden])
Date: 2002-08-10 03:45:28

"David Abrahams" <dave_at_[hidden]> wrote in message
news:057e01c24034$ca5f5e80$62f0fc0c_at_boostconsulting.com...
>
> From: "Douglas Gregor" <gregod_at_[hidden]>
>
>
>
> > > IMO, since variant<> is essentially a compound type, exception-free
> > > assignment should be guaranteed by the types it contains, not by
> itself. We
> > > shouldn't except it to do more than whatever the types themselves do.
> > >
> > > Besides, it will always be possible for a user to wrap offending
types.
> >
> > I don't agree with the need for exception-free assignment. Then we can't
> even
> > have an std::string in a variant without wrapping it.
>
> I agree with Fernando that we shouldn't expect variant to do more than
> whatever the types themselves do. I also agree with Doug that requiring
> exception-free assignment would be bad.
>
>
While writing the first draft of the variant class I tried to follow the
same guideline (i.e: a variant should provide the same level of exception
safety as its types). But a type U is not likely to support the following
kind of assignment, which is what a variant actually needs:

class U
{
    T& operator=(const T& rhs); // Semantics: this->~U() + new (this) T(rhs)
};

Consequently, the variant class has to deal with the details of this kind of
assignment itself. Since there two basic operations involved: (a)
destruction of U, and (b) copy construction of T,  this operation is
inherently a trouble maker, in terms of exception safety considerations.

If we reverse the order of (a) and (b) the code would be strongly exception
safe, but  - so far - it comes at the expense of doubling the memory
requirements. (I am speaking of Anthony Williams's idea from yesterday)

--
Itay Maman
    itay_maman@_yahoo_.com
    maman_at_il._ibm_.com
This message expresses my personal opinion.