Dave Abrahams wrote:
on Wed Aug 24 2011, Julian Gonggrijp <j.gonggrijp-AT-gmail.com> wrote:
But no, they are still not really the same. After a destructive move the source object is in a destructed state (raw memory, as you say), so in principle you should not need to worry about it anymore; i.e. it won't be destructed again at the end of scope.
Do you know how to implement that? (hint: see below)
No, I was wondering (and sceptical) about that already.
You're not really expected to store a new value of the moved-from type in the object; if you do want to do so you'll first have to run a constructor again.
The source of a raw move on the other hand is a bomb waiting to explode, because technically speaking it is still storing a value of the moved-from type and it *will* be destructed at the end of scope.
No, it is *not* storing a value. I believe you're saying that the difference is not in the state of the memory, but in what the compiler will try to do with that memory later.
Yes, that's what I meant to say.
That requires you to believe that in general, the compiler can know about the state of a destructively-moved automatic object and avoid destroying it again. But, for all practical purposes, it can't.
So what you are saying is: in practice there is no difference between a raw move and a destructive move. Point taken. But in that case the name 'raw move' seems to cover the semantics much better than 'destructive move'.
A raw move on the other hand can only be used if you are reordering values within the same scope.
? I presume that I can do swap(x,y) no matter what x and y's scope are.
Correct. 'Within the same scope' was meant to refer to the reordering, not to the values. That is, once you start a chain of raw moves, you have to close that chain within the same scope in order to provide a validity guarantee to calling clients. With hindsight, I should have realised much earlier in this thread that this is also the reason why every operation between the start and the end of a chain of raw moves must be exception-free. -Julian