El 22/08/2011 20:06, Vicente J. Botet Escriba escribió:
move-raw as std::move are optimizations. In addition to the optimizations introduced by std::move, move_raw don't need to left the moved object in a stable state, so it could be in some cases, as Eric told in another post, twice faster. This is the single reason to be for move_raw: optimization.
We can define a RawMovable concept and traits that states if a type is raw movable from another type (is_raw_movable). For these types we can specialize some algorithms that benefit from this optimization. Note that Movable will imply RawMovable if the default implementation uses std::move.
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 Best, Ion