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. Beyond that, 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 (see below). 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.[1] [2] 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.[3] The optimization can not be applied to a temporary object that has been bound to a reference.
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,[4] [5] 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.[6] Given the following source code:
struct C ;
void f // It is unclear whether this copy may be elided (omitted).
int main
A conforming compiler should therefore produce a program which prints "Hello World!" twice. In the C++11 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.[6]
GCC provides the -fno-elide-constructors option to disable copy-elision. This option is useful to observe (or not observe) the effects of return value optimization or other optimizations where copies are elided. It is generally not recommended to disable this important optimization.
C++17 Provides for "guaranteed copy elision", a prvalue is not materialized until needed, and then it is constructed directly into the storage of its final destination.[7]
In the context of the C++ programming language, return value optimization (RVO) is a compiler optimization that involves eliminating the temporary object created to hold a function's return value.[8] RVO is allowed to change the observable behaviour of the resulting program by the C++ standard.[9]
In general, the C++ standard allows a compiler to perform any optimization, provided the resulting executable exhibits the same observable behaviour as if (i.e. pretending) all the requirements of the standard have been fulfilled. This is commonly referred to as the "as-if rule".[10] [2] 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.[11] [2]
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 (printing text).[1] [2] 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.
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!
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.[12] Thus, code such as this:
Data F
int main
may generate code equivalent to this:
Data* F(Data* _hiddenAddress)
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.[13] 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:[14]
void F(Data* p)
int main
Bright implemented this optimization in his Zortech C++ compiler.[13] This particular technique was later coined "Named return value optimization" (NRVO), referring to the fact that the copying of a named object is elided.[14]
Return value optimization is supported on most compilers.[8] [15] [16] 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:[12] [15] [17]
std::string F(bool cond = false)
int main