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

From: David Abrahams (dave_at_[hidden])
Date: 2002-08-12 12:14:52

From: "Fernando Cacciola" <fcacciola_at_[hidden]>

> From: "David Abrahams" <dave_at_[hidden]>
> >
> > 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.

Wasn't it me?

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com