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. 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). Of course, the lame duck problem might also be relevant to move_raw, so that needs further investigation.