Re: [boost] [variant] Please vote for behavior

Subject: Re: [boost] [variant] Please vote for behavior
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2013-01-25 16:05:14

On Fri, Jan 25, 2013 at 3:16 PM, Krzysztof Czainski <1czajnik_at_[hidden]>wrote:

> 2013/1/25 Gottlob Frege <gottlobfrege_at_[hidden]>
>
> > On Fri, Jan 25, 2013 at 10:21 AM, Dave Abrahams <dave_at_[hidden]>
> wrote:
> >
> > > >>
> > > > Isn't leaving the class with it's invariants broken simply a defect?
> > >
> > > Yes.  IIUC the question here is whether the invariant of variant [;-)]
> > > shall be weakened to accommodate efficient move semantics, thereby
> > > breaking some code, or not, at some cost (the specific costs to be
> > > incurred by various strategies presently under discussion).
> > >
> > > But I have to admit, I haven't been reading the thread all that
> > > carefully, so I could be mis-understanding completely.
> > >
> > >
> > >
> >
> > Instead of weakened, which is one option discussed, I would also
> > characterize much of the discussion as "let's ignore that the invariant
> is
> > broken, because no one should rely on invariants after move".
> >
> > If you had opinions on that aspect, you might want to weigh in. It would
> be
> > appreciated.
> >
> > Tony
>
>
> I think variant after move is like int without initialization:
> int i;
> cout << i; // don't do this
> If the fact, that moved-from objects are only good for destruction or
> assignment-to is accepted, then invariants for moved-from objects are
> allowed to be violated.
>
>
int i = 17;
std::move(i);
cout << i;

don't do that because you don't know what value it will print, or because
it will crash, cause "undefined behaviour", overwrite your harddrive?

There's a difference between "don't know what value" and "UB".

Tony