on Tue Aug 23 2011, Julian Gonggrijp <j.gonggrijp-AT-gmail.com> wrote:
Ion Gaztañaga wrote:
We still have to explore "destructive move" semantics. We have move semantics. We can even declare a traits like "has_trivial_destructor_after_move" to optimize a bit more vector reallocations once we've moved some value_types (we avoid calling destructors that do nothing useful once moved). Destructive move semantics could be a step further, we need to explore destructive move semantics in containers and algorithms. Some problems with destructive move semantics here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm
That's interesting, but after reading that page I think raw_move is not the same as destructive move. The difference: destructive move acts as a destructor and hence makes the source object unavailable for further use.
Well, technically, it makes the source object's storage usable as raw memory.
In move_raw on the other hand, the source object is left in an invalid but non-destructed state which it can only be rescued from by raw moving another value into it (if it is non-POD).
How is an "invalid but non-destructed state" practically different from raw memory? Are you saying I can't default-construct another value of the same type in that memory? -- Dave Abrahams BoostPro Computing http://www.boostpro.com