Copy constructor elision? [duplicate]

Question

Possible Duplicate:
Why has the destructor been called only once?

Given the code below, I fail to understand the output in gcc. I expect two objects to be created and destroyed but instead see only one call to the constructor and the destructor. What's happening here?

#include <string>
#include <iostream>

struct Huge{
        Huge() { std::cout << "Constructor" << std::endl; }
        Huge(Huge const &r) { std::cout << "Copy Constructor" << std::endl; }
        ~Huge() { std::cout << "Destructor" << std::endl; }
};

Huge g() {
        std::cout << "Entering g" << std::endl;
        Huge temp;
        std::cout << "Exiting g" << std::endl;
        return temp;
}

int main(){
        Huge h2(g());
        std::cout << "Before leaving main" << std::endl;
}

The output of this code in g++ (4.4) is

Entering g

Constructor

Exiting g

Before leaving main

Destructor

Eolic

Sadly, none of the answers on the marked duplicate quotes the standard which explains the copy elision semantics in simple(for a change) and lucid words. – Microphotograph

Answer 1

Yes this is copy elision through Named Return Value Optimization.

The C++ standard allows an implementation to omit a copy operation resulting from a return statement, even if the copy constructor has side effects.

Reference:

C++03 Standard:
12.8 Copying class objects:

# 15

When certain criteria are met, an implementation is allowed to omit the copy construction of a class object, even if the copy constructor and/or destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization.111) This elision of copy operations is permitted in the following circumstances (which may be combined to eliminate multiple copies):

— in a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object with the same cv-unqualified type as the function return type, the copy operation can be omitted by constructing the automatic object directly into the function’s return value

— when a temporary class object that has not been bound to a reference (12.2) would be copied to a class object with the same cv-unqualified type, the copy operation can be omitted by constructing the temporary object directly into the target of the omitted copy

Microphotograph

any thoughts on why I don't see calls to two constructors and destructors (one for 'temp' and one for 'h2'). – Eolic

@Chubsdad: exactly what says on the answer: the compiler is free to optimize all the copies away (both the one from temp to the return value of g() and the one from the return value to h2) and construct only a single object. – Ass

"by constructing the automatic object directly into the function’s return value". Doesn't it still mean that there are two objects that are created. One is 'temp' and the other is 'h2'. – Eolic

@Chubsdad: no. temp is constructed directly into h2. – Ass

@Chubsdad: I made bold the relevant part in the standard quote which answers your question. – Microphotograph

Worth noting too that it often can be turned off using command line flags, for testing purposes. – Collegiate

Answer 2

C++ allows to avoid creating and copying extra objects in cases like yours. This is known as the named return value optimization. The point is that you know for sure that after the return the object temp would be gone anyway, and the semantics of the copy constructor should be to make an exactly equivalent copy to the original object.

Note that actually there are two optimizations occuring here. Without optimization, the object temp would first be copied into the return value in g, and then the return value would be copied to h2 in main. The named return value optimization elides the copy into the return value. Copying from the return value into h2 is elided because the return value is a temporary object, and here, too, the creation of a copy may be elided.

Note that unlike other optimizations, these optimizations are allowed even if they change observable behaviour (as in your test program). That's because otherwise these optimization could not be performed in many cases where it doesn't make a difference (indeed, except for debugging output, this should never make a difference in a well-written program), because the compiler often cannot proof that the elision would not change observable behaviour. On the other hand, there's no way to manually remove the copies,so it is important for the compiler to be able to do it automatically.

What ultimately happens is that the object temp is directly created in the space h2 occupies, so that at the point of the return statement h2 does already contain the correct value. In other words, due to the optimizations temp and h2 are actually the same object.

Levenson