Gotcha #57: Direct Argument Initialization

class Y { 
 public:
   Y( int );
   ~Y();
 private:
   Y( const Y & );
   // . . .
};
void f( Y yFormalArg ) {
   // . . .
}
// . . .
f( 1337 );

If argument passing is implemented as a direct initialization, the call to f should be correct. If the argument is initialized with copy initialization, the compiler should issue an error about the implicit attempt to access the private copy constructor for Y. Most compilers will permit the call, so we might conclude that argument passing is implemented with direct initialization. But most compilers are wrong, or at least out of date. The standard says that argument passing is accomplished with copy initialization, so the call to f above is incorrect. The initialization of yFormalArg is entirely analogous to the declaration below:

Y yFormalArg = 1337; // error! 

If we want to write code that's standard, portable, and that will remain correct as compilers move to implement the details of the standard, we should avoid writing code like the call to f.

There may also be performance issues. If the function that calls f had access to Y's private copy constructor, the call would be correct but would mean something like the following:

Y temp( 1337 ); 
yFormalArg( temp );
// body of f . . .
yFormalArg.~Y();
temp.~Y();

In other words, the initialization of the formal argument would consist of a temporary creation, copy construction of the formal argument, destruction of the formal argument on function return, and destruction of the temporary. Four function calls, not counting the call to f. Fortunately, most compilers will perform the program transformation to get rid of the temporary generation and copy constructor and will generate the same object code that would have been generated for a direct initialization:

yFormalArg( 1337 ); 
//body of f . . .
yFormalArg.~Y();

However, even this solution is not optimal in all cases. What if we initialize yFormalArg with a Y object?

Y aY( 1453 ); 
f( aY );

Here we will have a copy construction of yFormalArg with aY and destruction of yFormalArg on return from f. A much better solution is to avoid, if possible, passing class objects by value in favor of passing by reference to constant:

void fprime( const Y &yFormalArg ); 
// . . .
fprime( 1337 ); // works! no copy ctor
fprime( aY ); // works, efficient.

In the first case, the compiler will create a temporary Y initialized with the value 1337 and will use this temporary to initialize the reference formal argument. The temporary will be destroyed immediately after fprime returns. (See Gotcha #44, where I discuss the extreme danger of returning such an argument.) This is equivalent in efficiency to the transformed solution above and has the additional benefit of being legal C++. The second call to fprime incurs no temporary generation overhead at all and, in addition, avoids the necessity of a destructor call on return.