On Mon, May 3, 2010 at 9:47 PM, Peter Dimov <pdimov@pdimov.com> wrote:
Chad Nelson:
If that's the case, and GCC is doing that as it should, why would adding move semantics to the library provide any speed increase at all?
Consider something like
X f(); g( X );
int main() { f( g() ); // #1 f( -g() ); // #2 }
In #1, the compiler can eliminate all copies, if f is written in a RVO-friendly way. (It won't be able to in general if there's more than one return statement, or the return value is a ternary ?: expression.)
But in #2, there's going to be one allocation for the result of the unary op-. Even if operator- takes its parameter by value and directly flips its sign and returns it, I don't think that the compiler is allowed to allocate the return value and the parameter at the same address.
No, but swap is your friend: X operator- (X x) { modify-in-place x; X ret; // this should be cheap ret.swap(x); return ret; // NRVO should kick in } HTH, -- gpd