Return value optimization

Return value optimization, or simply RVO, is a compiler optimization technique that involves eliminating the temporary object created to hold a function's return value.^[1] In C++, it is particularly notable for being allowed to change the observable behaviour of the resulting program.^[2]

Summary

In general, the C++ standard allows a compiler to perform any optimization, as long as the resulting executable exhibits the same observable behaviour as if all the requirements of the standard have been fulfilled. This is commonly referred to as the as-if rule.^[3] The term return value optimization refers to a special clause in the C++ standard that allows an implementation to omit a copy operation resulting from a return statement, even if the copy constructor has side effects,^[4] something that is not permitted by the as-if rule alone.^[3]

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).^[4] The first copy that may be eliminated is the one where C() is copied into the function f's return value. The second copy that may be eliminated is the copy of the temporary object returned by f to obj.

#include <iostream>
 
struct C {
  C() {}
  C(const C&) { std::cout << "A copy was made.\n"; }
};
 
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:

Hello World!
A copy was made.
A copy was made.

Hello World!
A copy was made.

Hello World!

Background

Returning an object of builtin 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 achieve 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.^[5] 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 Data 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.^[6] Around 1991, Walter Bright invented a technique to minimize copying, effectively replacing the hidden object and the named object inside the function with the object used to hold the result:^[7]

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.^[6] This particular technique was later coined "Named return value optimization", referring to the fact that the copying of a named object is elided.^[7]

Compiler support

Return value optimization is supported on most compilers.^[1][8][9] 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:^[5][8][10]

#include <string>
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();
}

See also

• Copy elision

References

1. ^ ^{a b} Meyers, Scott (1996). More Effective C++. Addison Wesley. 
2. ^ Alexandrescu, Andrei (2003-02-01). "Move Constructors". Dr. Dobbs Journal. http://www.ddj.com/cpp/184403855. Retrieved 2009-03-25. 
3. ^ ^{a b} ISO/IEC (2003). ISO/IEC 14882:2003(E): Programming Languages - C++ §1.9 Program execution [intro.execution] para. 1
4. ^ ^{a b} ISO/IEC (2003). ISO/IEC 14882:2003(E): Programming Languages - C++ §12.8 Copying class objects [class.copy] para. 15
5. ^ ^{a b} Bulka, Dov; David Mayhew (2000). Efficient C++. Addison-Wesley. ISBN 0-201-37950-3. 
6. ^ ^{a b} Lippman, Stan. "The Name Return Value Optimization". Stan Lippman. http://blogs.msdn.com/slippman/archive/2004/02/03/66739.aspx. Retrieved 2009-03-23. 
7. ^ ^{a b} "Glossary D Programming Language 2.0". Digital Mars. http://www.digitalmars.com/d/2.0/glossary.html. Retrieved 2009-03-23. 
8. ^ ^{a b} Shoukry, Ayman B.. "Named Return Value Optimization in Visual C++ 2005". Microsoft. http://msdn.microsoft.com/en-us/library/ms364057(VS.80).aspx. Retrieved 2009-03-20. 
9. ^ "Options Controlling C++ Dialect". GCC. 2001-03-17. http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC5. Retrieved 2009-03-20. 
10. ^ Hinnant, Howard; et al. (2002-09-10). "N1377: A Proposal to Add Move Semantics Support to the C++ Language". WG21. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm. Retrieved 2009-03-25.