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