Copy elision


In C++ computer programming, copy elision refers to a compiler optimization technique that eliminates unnecessary copying of objects. The C++ language standard generally allows implementations to perform any optimization, provided the resulting program's observable behavior is the same as if, i.e. pretending, the program were executed exactly as mandated by the standard.
The standard also describes a few situations where copying can be eliminated even if this would alter the program's behavior, the most common being the return value optimization. Another widely implemented optimization, described in the C++ standard, is when a temporary object of class type is copied to an object of the same type.ISO/IEC. ISO/IEC 14882:2003: Programming Languages - C++ §12.8 Copying class objects para. 15 As a result, copy-initialization is usually equivalent to direct-initialization in terms of performance, but not in semantics; copy-initialization still requires an accessible copy constructor. The optimization can not be applied to a temporary object that has been bound to a reference.

Example


  1. include
int n = 0;
struct C ; // it modifies an object with static storage duration
int main

According to the standard a similar optimization may be applied to objects being thrown and caught,ISO/IEC. ISO/IEC 14882:2003: Programming Languages - C++ §15.1 Throwing an exception para. 5ISO/IEC. ISO/IEC 14882:2003: Programming Languages - C++ §15.3 Handling an exception para. 17 but it is unclear whether the optimization applies to both the copy from the thrown object to the exception object, and the copy from the exception object to the object declared in the exception-declaration of the catch clause. It is also unclear whether this optimization only applies to temporary objects, or named objects as well. Given the following source code:

  1. include
struct C ;
void f // It is unclear whether this copy may be elided.
int main

A conforming compiler should therefore produce a program which prints "Hello World!" twice. In the current revision of the C++ standard, the issues have been addressed, essentially allowing both the copy from the named object to the exception object, and the copy into the object declared in the exception handler to be elided.
GCC provides the ‑fno‑elide‑constructors option to disable copy-elision. This option is useful to observe the effects of return value optimization or other optimizations where copies are elided. It is generally not recommended to disable this important optimization.

Return value optimization

In the context of the C++ programming language, return value optimization is a compiler optimization that involves eliminating the temporary object created to hold a function's return value. RVO is particularly notable for being allowed to change the observable behaviour of the resulting program by the C++ standard.

Summary

In general, the C++ standard allows a compiler to perform any optimization, provided the resulting executable exhibits the same observable behaviour as if all the requirements of the standard have been fulfilled. This is commonly referred to as the "as-if rule".ISO/IEC. ISO/IEC 14882:2003: Programming Languages - C++ §1.9 Program execution para. 1 The term return value optimization refers to a special clause in the C++ standard that goes even further than the "as-if" rule: an implementation may omit a copy operation resulting from a return statement, even if the copy constructor has side effects.ISO/IEC. ISO/IEC 14882:2003: Programming Languages - C++ §12.8 Copying class objects para. 15
The following example demonstrates a scenario where the implementation may eliminate one or both of the copies being made, even if the copy constructor has a visible side effect. The first copy that may be eliminated is the one where a nameless temporary C could be copied into the function f's return value. The second copy that may be eliminated is the copy of the temporary object returned by f to obj.

  1. include
struct C ;
C f
int main

Depending upon the compiler, and that compiler's settings, the resulting program may display any of the following outputs:
Hello World!
A copy was made.
A copy was made.

Hello World!
A copy was made.

Hello World!

Background

Returning an object of built-in type from a function usually carries little to no overhead, since the object typically fits in a CPU register. Returning a larger object of class type may require more expensive copying from one memory location to another. To avoid this, an implementation may create a hidden object in the caller's stack frame, and pass the address of this object to the function. The function's return value is then copied into the hidden object. Thus, code such as this:

struct Data ;
Data F
int main

may generate code equivalent to this:

struct Data ;
Data* F
int main

which causes the Data object to be copied twice.
In the early stages of the evolution of C++, the language's inability to efficiently return an object of class type from a function was considered a weakness. Around 1991, Walter Bright implemented a technique to minimize copying, effectively replacing the hidden object and the named object inside the function with the object used for holding the result:

struct Data ;
void F
int main

Bright implemented this optimization in his Zortech C++ compiler. This particular technique was later coined "Named return value optimization", referring to the fact that the copying of a named object is elided.

Compiler support

Return value optimization is supported on most compilers.
There may be, however, circumstances where the compiler is unable to perform the optimization. One common case is when a function may return different named objects depending on the path of execution:

  1. include
std::string F
int main