Nevin Liber wrote:
In the C++11 move case, the moved-from object itself doesn't know if it is about to be destroyed or reused, so it has to be put in a state where either can happen.
Excuse me, but that doesn't seem logical. You are saying that since the object doesn't know what is going to happen, the programmer has to prepare it for both scenarios. But in this case the programmer knows what is going to happen (assuming that care is taken to ensure exception-safety). So it can just as well prepare the object only for the scenario that is really going to happen.
The compiler, of course, knows, and I want the optimizer to take advantage of this.
[As a parallel: I still write a correct copy constructor for a copyable object even if all my uses involve RVO and it never gets called; as I'd rather have correct but slower code than incorrect code if a non-RVO case happens to pop up.]
You are giving a valid reason for implementing a copy constructor, but the argument is orthogonal to the point I was trying to make. Suppose you have not only copy constructors at your disposal but also a tool that is guaranteed to do RVO (e.g. something along the line of rvalue references). Then surely every time you use a function that returns a local variable you are going to use the RVO-only tool and not the most-of-the-time-optimized-into-RVO copy constructor?
raw_move is a user optimization over C++11 moves in that it assumes the moved-from object is going to be reused; destruction would be very bad, which is why there is all this worry over exception safety.
So far I understood. What I didn't see was why an exception would be bad if the moved-from object is actually in a valid state because behind the scenes move_raw is implemented as a copy. Eric Niebler has enlightened me: it's not bad for the object itself, but it might be a disaster for another object which has undergone a real raw move before the exception happened. -Julian