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

Subject: Re: [boost] [variant] Please vote for behavior
From: Krzysztof Czainski (1czajnik_at_[hidden])
Date: 2013-01-25 16:25:47

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

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

Right.
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 wrong?

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.

Kris