Copy elision is a neat optimization technique and in some cases relying on copy elision can actually be faster than passing around references \"by hand\".
So, let\'s
Not really, except putting an assert(false);
in the copy constructor.
Otherwise use your favorite profiler to measure that the interesting parts of your app is fast enough.
No.
But you can write an equivalent, although completely unreadable, code:
BigObj f()
{
BigObj x(g());
x.someMethod();
return x;
}
//...
BigObj z = f();
//...
is translated (with copy elision) to:
void f(BigObj* obj)
{
new(obj) BigObj(g());
obj->someMethod();
}
//...
char z[sizeof(BigObj)];
f((BigObj*)&z[0]);
//...
((BigObj*)&z[0])->~BigObj();
But seriously, just write your code in such a way that the compiler can elide the copy. I.e. return only one object without branching:
BigObj f()
{
BigObj x, y;
// use x and y
if(condition)
return x;
else
return y;
// cannot be elided
}
BigObj f()
{
if(condition)
{
BigObj x;
return x;
}
else
{
BigObj y;
return y;
}
// can be elided
}
In C++1z (expected 2017), some cases will be required to guarantee copy elision:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0135r0.html
Per the communal cppreference.com compiler feature support wiki GCC 7+ and Clang 4+ ensure this.
The optimization side of this fortunately should not require enabling newer language support, since it's a pure optimization (following older language standard allowances).
Also allowing the copy constructor to be unavailable when the optimization applies probably will require the newer language standard to be enabled during compilation, or use of a loose or extended mode that doesn't demand strict conformance (e.g. potentially GCC's -fpermissive
).