This week-end I looked at C++ rvalue references and move semantics. Here’s the code, the good stuff is in  matrix.h.

Rvalue references seem useful, but way too treacherous. Any programming construct that raises doubts on the nature of objective reality and evokes associations with quantum physics (‘reference collapse’ ~ ‘wave function collapse’) is probably too complicated for its own good. But… maybe you don’t believe me? The great Scott Meyers explains it beautifully in his channel 9 presentation on rvalue references. I was unable to get it right on my own before I watched that.

Rvalue references can be used to reduce unnecessary data copying. I was able to create a matrix class that passes matrices by value, but avoids actually duplicating the data whenever possible. This is great, but let’s see the laundry list of gotchas I ran into:

1. Variable of type T&& cannot be passed to a function that accepts T&& (oops!).
2. You fix it by using forward(v) or move(v), but the difference between the two is confusing.
3. When you see T&& in code, it may not in fact be an rvalue reference.
4. If you are not careful, you may silently get copy behavior instead of move behavior.
5. Overloads may not work the way you expect.

But let’s start with the good stuff.

What you can do with rvalue references.

I created a class matrix with operator+: complete source at https://github.com/ikriv/cpp-move-semantics.

Rvalue references are traditionally used to optimizing copy constructors and assignment, but they can be as useful in case of operator +. Traditional implementation of such operator for matrices would look something like this:

matrix operator+(matrix const& a, matrix const& b)
{
    matrix result = a;
    result += b;
    return result;
}

If we have an experssion like matrix result = a+f(b)+f(c)+d; the compiler will have no choice, but to create a bunch of temporary matrices and copy a lot of data around. We can significantly reduce the amount of copying by adding rvalue-based overloads of operator +() that modify an rvalue parameter “in place” instead of allocating a new matrix. The idea is that rvalue is by definition inaccessible outside the expression, and thus there is no harm in modifying it.

matrix operator+(matrix&& a, matrix const& b) // rvalue+lvalue
{
    return std::move(a += b);
}

matrix operator+(matrix const& a, matrix&& b) // lvalue+rvalue
{
    return std::move(b += a);
}

matrix operator+(matrix&& left, matrix&& right) // rvalue+rvalue
{
   return std::move(a += b);
}

This does improve the performance dramatically. With the move semantics my code allocates 8 matrices. All rvalue reference overloads are conditionally compiled via #define MOVE_SEMANTICS. If I turn that off, the number of matrices allocated jumps to 12 in release mode and to 24 in debug mode.

So, rvalue references are useful, but they are still a minefield. You must really want those optimizations, and even then if you are not careful, you may not get what you expected. To be continued…