Gotcha #58: Ignorance of the Return Value Optimizations

It is often necessary for a function to return a result by value. For instance, the String class below implements a binary concatenation operator that must return the newly created concatenation of two existing Strings by value:

class String { 


 public:


   String( const char * );


   String( const String & );


   String &operator =( const String &rhs );


   String &operator +=( const String &rhs );


   friend String


       operator +( const String &lhs, const String &rhs );


   // . . .


 private:


   char *s_;


};

As with formal argument initialization, initialization of the function return value by the return expression is accomplished with copy initialization:

String operator +( const String &lhs, const String &rhs ) { 


   String temp( lhs );


   temp += rhs;


   return temp;


}

Logically, a copy constructor is used to initialize a return area in the caller with temp, and then temp is destroyed. Generally, the compiler chooses to implement the return by including the destination of the return value as an implicit argument to the function, as if the function were written something like this:

void 


operator +( String &dest, const String &lhs, const String &rhs ) {


   String temp( lhs );


   temp += rhs;


   dest.String::String( temp ); // copy ctor


   temp.~String();


}

Note that the compiler is generating the call to the copy constructor above, but we're not allowed to do that. Mere programmers have to resort to subterfuge:

new (&dest) String( temp ); // placement new trick, see Gotcha #62 

One implication of this transformation is that it's generally more efficient to initialize a class variable with the return value of a function than to assign to it:

String ab( a+b ); // efficient 


ab = a + b; // probably not efficient

In the declaration of ab, the compiler is free to copy the result of a+b directly into ab. However, this is not possible in the case of the assignment. The assignment operator for String is a member function that performs operations similar to a destruction of ab followed by a reinitialization of it; therefore, we should never attempt to assign to uninitialized storage (see Gotcha #47):

String &String::operator =( const String &rhs ); 

To initialize the rhs argument of String's member operator =, the compiler will be obliged to copy the value of a+b into a temporary, initialize rhs with the temporary, and destroy the temporary after operator = returns. For efficiency, prefer initialization to assignment.

Consider the meaning of copy initialization when returning the result of an expression that is not the same as the return type:

String promote( const char *str ) 


   { return str; }

Here, the copy initialization semantics demand that str be used to initialize a local temporary String, which will then be used to copy-construct the return value. Finally, the local temporary will be destroyed. However, the compiler is permitted to apply the same program transformation on the return initialization that it applies to declarations and formal argument initializations. It's likely that str will be used to initialize the return value directly with a call of the non–copy constructor of String and avoid the creation of a local temporary. When the program transformation of the copy initialization to the direct initialization is performed in the context of function return, it's often called the "return value optimization," or RVO.

Programmers commonly attempt to achieve greater efficiency by using a lower-level approach:

String operator +( const String &lhs, const String &rhs ) { 


   char *buf = new char[ strlen(lhs.s_)+strlen(rhs.s_)+1];


   String temp( strcat( strcpy( buf, lhs.s_ ), rhs.s_ ) );


   delete [] buf;


   return temp;


}

Unfortunately, this code may well be slower than our previous implementation of operator +. We're allocating a local character buffer in which to concatenate the representation of the two argument Strings, only to use the buffer to initialize a temporary String return value. The buffer is then tossed away.

In cases like this, it's sometimes useful to employ a "computational constructor" in the implementation of a class. A computational constructor is a constructor that is really part of the implementation of a class and is typically private. It's basically a "helper" function implemented as a constructor, to access the special properties constructors possess that regular member functions do not. Generally, the property of interest is the guarantee that the constructor is working with uninitialized storage, not an object. This guarantee means that there is nothing to "clean up":

class String { 


   // . . .


 private:


   String( const char *a, const char *b ) { // computational


       s_ = new char[ strlen(a)+strlen(b)+1];


       strcat( strcpy( s_, a ), b );


   }


   char *s_;


};

This computational constructor can then be used to facilitate efficient return by value for other functions in the implementation of the class:

inline String operator +( const String &a, const String &b ) 


   { return String( a.s_, b.s_ ); }

Recall that the copy initialization of the return value is analogous to that of a declaration:

String retval = String( a.s_, b.s_ ); 

If the compiler applies the transformation to the initialization, we have the functional equivalent of direct initialization:

String retval( a.s_, b.s_ ); 

Often, computational constructors are simple and can be inlined. The invoking operator + is now also a suitable candidate for inlining, resulting in a highly efficient implementation, equivalent to a hand-coded solution. However, note that computational constructors typically do nothing to enhance the public interface of a type. They should therefore generally be considered part of a class's implementation and be declared in the private section. Any single-argument computational constructors should without exception be declared to be explicit, so as not to affect the set of implicit conversions applied to a class (see Gotcha #37).

C++ compilers also implement one other common transformation in the context of function return, known as the "named return value optimization," or NRV. This transformation is similar to the RVO but allows the use of a named local variable to hold the return value. Consider our initial implementation of operator +:

String operator +( const String &lhs, const String &rhs ) { 


   String temp( lhs );


   temp += rhs;


   return temp;


}

If a compiler applies the NRV to this code, the local variable temp will be replaced by a reference to the eventual destination of the return value in the caller. It's as if the function were written as follows:

void 


operator +( String &dest, const String &lhs, const String &rhs ) {


   dest.String::String( lhs ); // copy ctor


   dest += rhs;


}

The NRV is typically applied only if the compiler can determine that all return expressions from a function are identical and refer to the same local variable. To increase the likelihood that the NRV will be applied, it is best to have a single return of a local variable or, failing that, have all returns return the same local variable. The simpler the better. Note that the NRV is a program transformation and not an optimization, because any side effects of the temporary initialization and destruction will be removed.

The performance gain from the application of these transformations can be significant, and it's often a good idea to facilitate their application through the use of computational constructors or the use of simple local variables to hold return values.