Understanding function call in context of temporary objects - c++

Question

Look at this simple code:
class A
{};
A f(A a)
{
return a;
}
int main(void)
{
A a;
A b = f(a);
return 0;
}
It creates a local variable a, calls a function f() and assigns its return value to another variable b. But I'd like to know what happens during the function call.
Could someone describe to be me, step by step, what objects (temporary or otherwise) are created during the process, what constructors, destructors and assign/move operators are called and when?

Answer 1

When in doubt bring out the Noisy class:
struct Noisy {
Noisy() { std::cout << "Default construct" << std::endl; }
Noisy(const Noisy&) { std::cout << "Copy construct" << std::endl; }
Noisy(Noisy&&) { std::cout << "Move construct" << std::endl; }
Noisy& operator=(const Noisy&) { std::cout << "Copy assignment" << std::endl; return *this; }
Noisy& operator=(Noisy&&) { std::cout << "Move assignment" << std::endl; return *this; }
~Noisy() { std::cout << "Destructor" << std::endl; }
};
Noisy f(Noisy a) {
return a;
}
int main(void) {
Noisy a;
Noisy b = f(a);
}
Compiled with gcc-4.9.1 using options g++ -fno-elide-constructors -std=c++11 t.cc gives output:
Default construct // 1. 'a' is default constructed.
Copy construct // 2. Local argument 'a' in function 'f' is copied.
Move construct // 3. Return value is move constructed (*see note below).
Move construct // 4. 'b' is move constructed from return value.
Destructor // 5. Local argument 'a' is destroyed.
Destructor // 6. Return value is destroyed.
Destructor // 7. 'b' is destroyed.
Destructor // 8. 'a' is destroyed.
Note: Even though local argument a is an lvalue, the compiler knows it's about to go out of scope and considers it as an rvalue.
Compiling without option -fno-elide-constructors will enable compiler copy elision optimizations and yields output:
Default construct // 1. 'a' is default constructed.
Copy construct // 2. Local argument 'a' in function 'f' is copied.
Move construct // 3. 'b' is move constructed from argument 'a' (elision).
Destructor // 4. Local argument 'a' is destroyed.
Destructor // 5. 'b' is destroyed.
Destructor // 6. 'a' is destroyed.
Compiling with -std=c++03 i.e. C++03 will result in all moves being replaced with copies.
For more info about copy elision see here: What are copy elision and return value optimization?

Answer 2

A f(A a)
{
return a;
}
A a;
A b = f(a);
The parameter (a) is copy-initialized with the corresponding argument (a). That simply involves the copy-constructor.
The return-value temporary is copy-initialized with a.
b is copy-initialized with the return value of the function call. The implicitly-defined move-constructor is called (as the initializer is a (p)rvalue).
Note that copy elision doesn't apply here as, in return statements, it only works for variables that aren't function (or catch-clause) parameters.

Answer 3

int main(void)
{
A a; // creates `a` using default constructor of `A`
A b = f(a); // initializes `b` using implicitly-defined
// move-constructor from temporary copy of `a` (see [1])
/* where
A f(A a) // gets copy of `A` object as argument
{
return a; // return-value is copy-initialized
}
*/
return 0;
}
[1] The implicit generation of move constructors

Answer 4

Assuming the optimizer does not simplify the process:
The function f you wrote takes its argument a by value. So calling the function f invokes setting up the parameter to f, which means copying the local variable a of your main function into the stack space used for passing the parameter to f (a temporary object). This object is created using the copy constructor.
As f returns by value, all typical C++ implementations work by passing a pointer to storage space for an object of type A (no created object yet) as a hidden parameter to f. In the most simple case, this is a temporary object created on the stack of main for the time of the expression involving the function call.
Now that the parameters for f are set up, the function f is entered. As its sole statement is a return statement, the only thing f does is copying the parameter a into the storage provided by the caller. This is done using the move constructor, but you hit a corner case in the language specification here, so compiler behaviour might vary, and you might get a copy instead. More in this in the last paragraph.
After having constructed the return value, f exits. main regains control and creates the local variable b, taking the temporary object returned by f as source. As this temporary object is an rvalue, the initialization of b is done using move construction (on C++11).
As the statement is completed now, the temporary objects (the parameter and the return value) are destroyed. I don't think the order of destruction is specified, but if it is, it will be last-constructed first, so the return value would be destroyed before the parameter.
Typically, a "move elision" optimization is applied to your code, though. The hidden parameter of f is not given the address of a temporary object which is afterwards moved constructed into b, but f constructs directly int b.
The (non-named) return value optimization is not of a concern for the code given, as the return statement does not consist of a constructor call.
The named return-value optimization is also not applicable. This optimization would place the object you return (i.e. the parameter a) at the place the caller provided for the return value, so a copy/move operation can be avoided. In the function you wrote, the returned object is a parameter, so the compiler gets no chance to "put it where the return value is going to be" while compiling f, as the machine calling convention dictates where that object is to be found.
The before-mentioned corner case in the language specification (whether the return value of f is move- or copy-constructed) is rooted in an implicit "std::move", allowing moving, on the return statement. This is specified in clause [class.copy] (12.8 in n3337) in paragraph 32. It specifies that if a copy is allowed to be elided (accoring to the previous paragraph), an l-value given as copy source (in this case the name of the parameter a) is treated as r-value (i.e. can be moved from). The criteria for allowed copy elisions are given in 12.8/31, which amongst other criteria lists:
a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object (other than a function or catch-clause parameter) with the same cv-unqualified type as the function return type, the copy/move operation can be omitted by constructing the automatic object directly into the function’s return value
This is, in fact, the definition of the named return value optimization! And as already explained above, the named return value optimization can not work, as parameters and returned objects are located in different spaces, but now lets go back to [12.8/32] and look at the precise wording:
When the criteria for elision of a copy operation are met or would be met save for the fact that the source object is a function parameter, and the object to be copied is designated by an lvalue, overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue
The part "or would be met save for the fact that the source object is a function parameter" is our life-saver here. It enables treatment as r-value even in the case where the named return value optimization is not possible just because of object storage locations and not because of semantic constraints.
EDIT: The reason I called this a corner case was missing: The life-save clause has been added very late in the C++11 standardization process, so there are some partly conforming compilers, that do not implicitly move from parameters.