On Fri, Jan 25, 2013 at 4:25 PM, Krzysztof Czainski <1czajnik@gmail.com>wrote:
2013/1/25 Gottlob Frege <gottlobfrege@gmail.com>
On Fri, Jan 25, 2013 at 3:16 PM, Krzysztof Czainski <1czajnik@gmail.com
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 the standard).
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
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 uninitialized. 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.