Subject: Re: [boost] [variant] Please vote for behavior
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2013-01-25 16:53:03
On Fri, Jan 25, 2013 at 4:25 PM, Krzysztof Czainski <1czajnik_at_[hidden]>wrote:
> 2013/1/25 Gottlob Frege <gottlobfrege_at_[hidden]>
> > On Fri, Jan 25, 2013 at 3:16 PM, Krzysztof Czainski <1czajnik_at_[hidden]
> > >wrote:
> > > 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);
> I think you mean:
> int other = std::move(i);
yes, of course :-)
> Just calling move doesn't move yet ;-) But then for ints and other PODs
> nothing is moved in any case, so I think the answer is always 17 here.
probably always true, although I don't know if it is written in stone (ie
> 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".
> So, is the following "UB" or "don't know what value"?
> int i;
> cout << i;
> I think it is officially the former, but in practice the latter, am I
> So to me the question is: should move introduce an "uninitialized" state
> for types that don't have one in the first place. Int has an uninitialized
> state. Iterators in std algorithms are allowed to have such a state too.
> And now we have moved-from objects - should they be allowed an additional
> "uninitialized" state?
> I answer yes, because moved-from objects must not be used for anything
> other than destruction or assignment-to.
But I don't think this is the question - or it was, but no longer is -
because I think the standard already asked and answered the question (and
it was hotly debated, but answered) - the answer was that moved from
objects should be in valid but unknown states. ie not UB. not
We might wish it different, but it isn't.
P.S. Now, really, the standard says very little about how your types behave
- you can make them do whateve in response to move, but for std:: types and
containers and algorithms that take your types it was agreed the behaviour
should be valid but unknown.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk