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
> > be
> > > > left undefined. Not empty, just plain inconsistent.
> > > > This sounds terrifying, but it isn't, because a user defined type
> > > > copy-constructor throws will most likely define an assignment
> > > > 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
> > > 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
> > 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
> explained to me...
> I initially figured that using T's operator =() in variant could be just
> safe as using it in T itself; but it isn't.
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk