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

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-08-12 12:22:04

----- Original Message -----
From: "David Abrahams" <dave_at_[hidden]>
To: "boost" <boost_at_[hidden]>
Sent: Saturday, August 10, 2002 3:11 AM
Subject: Re: [boost] Re: Empty boost::variant
semantics(wasRe:Re:Mini-reviewrequest: aligned_storage.hpp)

>
> From: "Douglas Gregor" <gregod_at_[hidden]>
>
>
> > On Friday 09 August 2002 04:26 pm, Fernando Cacciola wrote:
> > > If the user-defined copy-ctor throws, AND variant does NOTHING, not
> even
> > > resetting 'v' to empty before the assignment, the variant lvalue will
> be
> > > left undefined. Not empty, just plain inconsistent.
> > > This sounds terrifying, but it isn't, because a user defined type
whose
> > > copy-constructor throws will most likely define an assignment operator
> > > which also throws, so the situation won't be any worse than working
> with
> > > this broken-type (as David called it) directly.
> >
> > I wouldn't call that a broken type. Most classes allocate memory in
their
> > constructor. I think I broken type is one that, for instance, doesn't
> meet
> > even the basic guarantee for an assignment operator.
>
> That's precisely what I meant when I said "broken type". BTW, I don't know
> what Fernando's talking about above ;-)
>
I was talking nonsense :-) Don't worry about it.
A couple of hours after I post it I realize the problem that Itay and Eric
explained to me...
I initially figured that using T's operator =() in variant could be just as
safe as using it in T itself; but it isn't.

Then,

I like the move-semantics approach suggested by Doug. Specially since we
know that something like that is needed in many other areas.
I'm inclined to agree with him that having two variant classes might end up
being an ambiguity nightmare. I also like Anthony's double-storage technique
for non-movable types, so I guess that the final solution would be for
variant to use some heuristics to choosee between single-storage for movable
types or double storage for the others.

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

Right. Forget about exception free... way too strict.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com