Is it possible to ensure copy elision?

问题:

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 assume you have identified a critical code path where you rely on the fact that the copy elision is performed by your compiler for the code path for maximum performance.

But now you are relying on a compiler optimization.

Is there any (compiler specific, obviously) way to ensure that the copy elision is actually performed and have the compiler (or another tool) generate a warning/error if the copy elision cannot be performed?

(I'm thinking of something remotely similar to Visual C++'s __forceinline than will generate a warning if the function marked thus isn't inlined by the compiler.)

回答1:

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.

回答2:

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
}

回答3:

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

Neither GCC 7 nor Clang 3.8 ensures this yet. Later versions will hopefully get there quite soon.

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.