Return value optimization is a particular case of copy elision. It may occur in the following situation as described by the standard:
in 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
There is no reason this should result in a memory leak. If the class performs some dynamic allocation in its constructor, this will happen when the object is constructed directly into the function's return value.
In response to your comment (where foo1
and foo2
both construct T
objects and return them):
T a = foo1();
a = foo2();
We're not only looking at RVO here, but another kind of copy elision that occurs when attempting to construct an object from a temporary.
In the first line, two copies/moves can be elided:
- Returning the constructed object from
foo1
- Copying the returned object into
a
That is, the object constructed in foo1
can be directly created in the location of a
. If the constructor dynamically allocates some object, that will only be done once, for the a
object.
In the second line, a single copy/move can be elided - only the return from the function. So the object that foo2
constructs will be created directly in the return value of the function, then it will be copy/move assigned into a
. Copy/move assignments aren't elided.
It is then up to the copy/move assignment operator to ensure that the original allocated resource is discarded safely and the only remaining resource is the one that was created inside foo2
.