Difference between revisions of "cpp/language/copy elision"

Mandatory elision of copy/move operations

Under the following circumstances, the compilers are required to omit the copy and move construction of class objects, even if the copy/move constructor and the destructor have observable side-effects. The objects are constructed directly into the storage where they would otherwise be copied/moved to. The copy/move constructors need not be present or accessible:

• In a return statement, when the operand is a prvalue of the same class type (ignoring cv-qualification) as the function return type:

T f() {
    return T();
}
 
f(); // only one call to default constructor of T

The destructor of the type returned must be accessible at the point of the return statement and non-deleted, even though no T object is destroyed.

• In the initialization of an object, when the initializer expression is a prvalue of the same class type (ignoring cv-qualification) as the variable type:

T x = T(T(f())); // only one call to default constructor of T, to initialize x

This can only apply when the object being initialized is known not to be a potentially-overlapping subobject:

struct C { /* ... */ };
C f();
struct D;
D g();
struct D : C {
    D() : C(f()) { }    // no elision when initializing a base-class subobject
    D(int) : D(g()) { } // no elision because the D object being initialized might
                        // be a base-class subobject of some other class
};

Note: the rule above does not specify an optimization: C++17 core language specification of prvalues and temporaries is fundamentally different from that of the earlier C++ revisions: there is no longer a temporary to copy/move from. Another way to describe C++17 mechanics is "unmaterialized value passing": prvalues are returned and used without ever materializing a temporary.

Return value optimization is mandatory and no longer considered as copy elision; see above.

• In a throw-expression, when the operand is the name of a non-volatile object with automatic storage duration, which isn't a function parameter or a catch clause parameter, and whose scope does not extend past the innermost try-block (if there is a try-block).
• In a catch clause, when the argument is of the same type (ignoring cv-qualification) as the exception object thrown, the copy of the exception object is omitted and the body of the catch clause accesses the exception object directly, as if caught by reference (there cannot be a move from the exception object because it is always an lvalue). This is disabled if such copy elision would change the observable behavior of the program for any reason other than skipping the copy constructor and the destructor of the catch clause argument (for example, if the catch clause argument is modified, and the exception object is rethrown with throw).

• In coroutines, copy/move of the parameter into coroutine state may be elided where this does not change the behavior of the program other than by omitting the calls to the parameter's constructor and destructor. This can take place if the parameter is never referenced after a suspension point or when the entire coroutine state was never heap-allocated in the first place.

• In constant expression and constant initialization, return value optimization (RVO) is guaranteed, however, named return value optimization (NRVO) is forbidden:

struct A {
    void *p;
    constexpr A(): p(this) {}
};
 
constexpr A g()
{
    A a;
    return a;
}
 
constexpr A a;          // a.p points to a
// constexpr A b = g(); // error: b.p would be dangling and would point to a temporary
                        // with automatic storage duration
 
void g()
{
    A c = g();          // c.p may point to c or to an ephemeral temporary
}
 
extern const A d; 
constexpr A f()
{
    A e;
    if (&e == &d)
        return A();
    else
        return e;
    // mandating NRVO in constant evaluation contexts would result in contradiction
    // that NRVO is performed if and only if it's not performed
} 
// constexpr A d = f(); // error: d.p would be dangling

In a return statement or a throw-expression, if the compiler cannot perform copy elision but the conditions for copy elision are met or would be met, except that the source is a function parameter, the compiler will attempt to use the move constructor even if the object is designated by an lvalue; see return statement for details.