RVO V.S. std::move

Return Value Optimization

Return value optimization, simply RVO, is a compiler optimization technique that allows the compiler to construct the return value of a function at the call site. The technique is also named "elision". C++98/03 standard doesn’t require the compiler to provide RVO optimization, but most popular C++ compilers contain this optimization technique, such as IBM XL C++ compiler, GCC and Clang . This optimization technique is included in the C++11 standard due to its prevalence.  As defined in Section 12.8 in the C++11 standard, the name of the technique is "copy elision".

Let’s start with one example to see how the RVO works. Firstly, we have a class named BigObject. Its size could be so large that copying it would have high cost. Here I just define constructor, copy constructor and destructor for convenience.

class BigObject {

public:

    BigObject() {

        cout << "constructor. " << endl;

}

    ~BigObject() {

        cout << "destructor."<< endl;

 }

    BigObject(const BigObject&) {

        cout << "copy constructor." << endl;

 }

};

We then define one function named foo to trigger the RVO optimization and use it in the main function to see what will happen.

BigObject foo() {

    BigObject localObj;

    return localObj;

}

int main() {

    BigObject obj = foo();

}

Some people will call this case using named return value optimization(NRVO), because foo returns one temporary object named localObj. They think that what returns BigObject() is RVO. You don't  need to worry about it, as NRVO is one variant of RVO.

Let’s compile this program and run: xlC a.cpp ;./a,out. (The version of the XL C/C++ compiler used is V13 and the environment is Linux little endian.) The output is like this:

constructor.

destructor.

It is amazing, right? There is no copy constructor here. When the price of coping is high, RVO enables us to run the program much faster. 

However, when we modify our code a little, things will change.

BigObject foo(int n) {

    BigObject localObj, anotherLocalObj;

    if (n > 2) {

       return localObj;

    } else {

       return anotherLocalObj;

    }

}

int main() {

    BigObject obj = foo(1);

}

The output will be like this:

constructor.

constructor.

copy constructor.

destructor.

destructor.

destructor.

We can find that copy constructor is called. Why?  It's time to show the mechanism of RVO.

 

 

 

 

 

 

 

 

 

 

 

This diagram is a normal function stack frame. If we call the function without RVO, the function simply allocates the space for the return in its own frame. The process is demonstrated in the following diagram:

 

 

 

 

 

 

 

 

 

 

 

What will happen if we call the function with RVO?

 

 

 

 

 

 

 

 

 

 

 

We can find that RVO uses parent stack frame (or an arbitrary block of memory) to avoid copying. So, if we add if-else branch, the compiler doesn’t know which return value to put. 

std::move

We first need to understand what std::move is. Many C++ programmers misunderstand std::move so that they use std::move in wrong situations. Let us see the implementation of std::move.

template<typename T> 

decltype(auto) move(T&& param)

{

    using ReturnType = remove_reference_t<T>&&;

    return static_cast<ReturnType>(param);

}

In fact, the key step std::move performs is to cast its argument to an rvalue. It also instructs the compiler that it is eligible to move the object, without moving anything. So you can also call "std::move" as "std::rvalue_cast", which seems to be more appropriate than "std::move".

The price of moving is lower than coping but higher than RVO.  Moving does the following two things:

    1. Steal all the data
    2. Trick the object we steal into forgetting everything

If we want to instruct the compiler to move, we can define move constructor and move assignment operator. I just define move constructor for convenience here.

BigObject(BigObject&&){

    cout << "move constructor"<< endl;

}

Let us modify the code of foo.

BigObjectfoo(intn){

    BigObject localObj, anotherLocalObj;

    if (n > 2) {

       return std::move(localObj);

    } else {

       return std::move(anotherLocalObj);

    }

}

Let’s compile it and run: xlC –std=c++11 a.cpp;./a.out. The result is:
constructor.
constructor.
move constructor
destructor.
destructor.
destructor.

We can find that move constructor is called as expected. However, we must also note that the compiler also calls destructor while RVO doesn’t.

Some people would think that returning std::move(localObj) is always beneficial. If the compiler can do RVO, then RVO. Otherwise, the compiler calls move constructor. But I must say: Don't DO THAT!

Let us see what will happen if we do this:

BigObjectfoo(intn){

    BigObject localObj;

    return std::move(localObj);

}

int main() {

    auto f = foo(1);

}

Maybe you think that the compiler will do RVO, but you actually get this result:
constructor.
move constructor
destructor.
destructor.

The compiler doesn’t do RVO but call move constructor! To explain it, we need to look at the details of copy elision in C++ standard first:

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

That is to say, we must keep our type of return statement the same as function return type.

Let's then, refresh our memory about std::move a little bit. std::move is just an rvalue-cast. In other words, std::move will cast localObj to localObj&& and the type is BigObject&&, but the function type is just BigObject. BigObject is not BigObject&&, so this is the reason why RVO didn’t take place just now.

We now change the foo function return type and obj type is BigObject&&:

BigObject&&foo(intn){

    BigObject localObj;

    return std::move(localObj);

}

int main() {

    auto f = foo(1);

}

Then we compile and run it, and we will get the output like this:

constructor. 

destructor.

move constructor

destructor.

Yes! The compiler does RVO! (Note: We should not use this way in the real development, because it is a reference to a local object. Here just show how to make RVO happened.).  

To summarize, RVO is a compiler optimization technique, while std::move is just an rvalue cast, which also instructs the compiler that it's eligible to move the object. The price of moving is lower than copying but higher than RVO, so never apply std::move to local objects if they would otherwise be eligible for the RVO.

English Editor: Jun Qian Zhou (Ashley). Many thanks to Ashley!