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.<ref name="C++03 12.8/15">ISO/IEC (2003). "ISO/IEC 14882:2003(E): Programming Languages - C++ §12.8 Copying class objects [class.copy]" para. 15</ref> 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.
int n = 0;
struct C {
 C(const C&) { ++n; } // the copy constructor has a visible side effect
}; // it modifies an object with static storage duration
int main() {
 C c1(42); // direct-initialization, calls C::C(int)
 C c2 = C(42); // copy-initialization, calls C::C(const C&)
 std::cout « n « std::endl; // prints 0 if the copy was elided, 1 otherwise
According to the standard a similar optimization may be applied to objects being thrown and caught,<ref name="C++03 15.1/5">ISO/IEC (2003). "ISO/IEC 14882:2003(E): Programming Languages - C++ §15.1 Throwing an exception [except.throw]" para. 5</ref><ref name="C++03 15.3/17">ISO/IEC (2003). "ISO/IEC 14882:2003(E): Programming Languages - C++ §15.3 Handling an exception [except.handle]" para. 17</ref> 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:
struct C {
 C() = default;
void f() {
 C c;
 throw c; // copying the named object c into the exception object.
} // It is unclear whether this copy may be elided (omitted).
int main() {
 try {
 f();
 } catch (C c) { // copying the exception object into the temporary in the
 // exception declaration.
 } // It is also unclear whether this copy may be elided (omitted).
A conforming compiler should therefore produce a program which prints "Hello World!" twice. In the current revision of the C++ standard (C++11), 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 codice_1 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.
Return value optimization.
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. RVO is 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" (i.e. pretending) all the requirements of the standard have been fulfilled. This is commonly referred to as the "as-if rule".<ref name="C++03 1.9/1">ISO/IEC (2003). "ISO/IEC 14882:2003(E): Programming Languages - C++ §1.9 Program execution [intro.execution]" para. 1</ref> 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.<ref name="C++03 12.8/15">ISO/IEC (2003). "ISO/IEC 14882:2003(E): Programming Languages - C++ §12.8 Copying class objects [class.copy]" para. 15</ref>
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). The first copy that may be eliminated is the one where a nameless temporary codice_2 could be copied into the function codice_3's return value. The second copy that may be eliminated is the copy of the temporary object returned by codice_3 to codice_5.
struct C {
 C() = default;
C f() {
 return C();
int main() {
 std::cout « "Hello World!\n";
 C obj = f();
Depending upon the compiler, and that compiler's settings, the resulting program may display any of the following outputs:
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 { 
 char bytes[16]; 
Data F() {
 Data result = {};
 // generate result
 return result;
int main() {
 Data d = F();
may generate code equivalent to this:
struct Data {
 char bytes[16];
Data* F(Data* _hiddenAddress) {
 Data result = {};
 // copy result into hidden object
 *_hiddenAddress = result;
 return _hiddenAddress;
int main() {
 Data _hidden; // create hidden object
 Data d = *F(&_hidden); // copy the result into d
which causes the codice_6 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 {
 char bytes[16];
void F(Data* p) {
 // generate result directly in *p
int main() {
 Data d;
 F(&d);
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:
std::string F(bool cond = false) {
 std::string first("first");
 std::string second("second");
 // the function may return one of two named objects
 // depending on its argument. RVO might not be applied
 return cond ? first : second;
int main() {
 std::string result = F();