What kinds of code need to be aware of rvalue references?

Question

I see lots of people having problems understanding rvalue references. Will "ordinary" C++ code (e.g., that uses the standard library, but doesn't implement it) need to know about rvalue references once the new standard comes out, or can the people/code just pretend rvalue references don't exist? Do rvalue references primarily concern library implementors or all programmers?

Answer 1

I didn't see anything much to disagree with in GMan's (aka gmannickg) blog article on the subject:

http://blackninjagames.com/?p=95

Summary: anyone who knows about copy-and-swap (and in general the rule of three), should know about move semantics (and hence rvalue references), because the best-practice idioms change as a result. I think, therefore, that's anyone who cares at all about C++.

I don't think you have to know, because of course copy-and-swap still works, it's still exception-safe, and so on. And I suppose someone could argue whether "ordinary" C++ code and programmers even need to know copy-and-swap. I'd hope that the answer is "well, duh, obviously", but you never know.

Of course, the point at which one can start using C++0x will vary from place to place. It's probably not a good idea to unlearn C++03 any time soon.

For example, returning huge collections by value in contexts that aren't valid for copy elision becomes a better bet if you can rely on move assignment. This isn't a case of something that's invalid in C++03 becoming valid in C++0x, it's code that's heinously slow in C++03, that you'd work around (even if only with a well-placed swap), becoming fine in C++0x. So if you pretend rvalue references don't exist, you'll carry on working around something you don't need to. If you make the jump then it might backport cleanly to C++03 but run dog-slow, which is a pain.

So the smart thing might be to know about it, and in many contexts pretend it doesn't exist.

Answer 2

At least for most situations, you can ignore them for about as long as you feel like you want to. (Re)writing the standard library to use them allows considerable optimization and some new capabilities, but one of the major goals is that existing code should continue to work just fine (though, in some cases, faster).

Supporting existing code implies that anybody who feels like it can continue to write code the same way they would have previously, and not be affected either (again, except that some library "stuff" they use might be faster).

At the same time, there are some pretty good reasons somebody might want to learn at least a few rules of thumb that let them make some simple use of rvalue-references. One obvious example would be a problem people run into regularly now: they have a class that it doesn't really make sense to copy objects, but they'd still like to be able to put those objects in a collection (e.g., a vector).

They can do that by making objects of that class movable but not copyable. A prime example of this would be streams -- right now, you can't put any kind of iostream object into a collection, but in C++0x you will be able to.

Another possibility is to use "perfect forwarding". This can make it quite a bit easier to consolidate what would previously have been a number of separate functions into one with really trivial front-ends that all forward to the one that does the real work. You can always do without this, but in some cases it can make the code quite a bit less repetitious.

Answer 3

Most people can just pretend that they don't exist, and they'll just see the benefits (faster code in some cases).

Remember that C++0x is going to be 99.9% backwards compatible, so all existing code will still work, meaning that you can continue to write C++0x code as if it were C++03.

If you want to reap the benefits of rvalue references then of course you'll need to learn about them, but most of the time that will only be a concern of library writers.

Answer 4

You may not need to know about rvalue references in the sense of writing some function that takes one, but you may benefit from understanding move semantics, from knowing what a move constructor is, and so on. If you want to use unique_ptr (and gain the perf benefit since it has no reference counting) then you will almost certainly need to use std::move (say, into and out of a collection) and I can't imagine approaching that in the "what if I put a & or a * here?" way that a typical second-year student copes with pointers.

I just did a "what's new in VC++ featuring C++0x" talk at Tech Ed Europe in Berlin that had one slide on rvalue references and I basically said "you need to know that these are here because they make the STL way faster" but I didn't drill any further. That seemed to be better accepted by the attendees than the (longer) variants I have had in other talks.

Answer 5

I agree, that RValue References are not everyones cup of tea -- the cup is quite big.

Because of this I tell learners of C++0x that the best approach to get started and to take advantage of RValue References is to use the STL and embrace its design patterns over time. It is very likely that by this you benefit from RValue References without understanding them completely beforehand.

Answer 6

In c++11 I would pass anything that I plan on 'storing' or 'consuming' by &&. This results in the most efficient code, but 'breaks' lvalue compatibility and forces me to consider having two (or more) versions of every method. Unfortunately, you get a explosion of permutations of rvalue and const& as the number of arguments increases and it makes getting function pointers much more 'ugly'.

Instead of providing two (or more) overloads, one for lvalues and one for rvalue, I have decided to only provide the rvalue overload and if the user wants to pass an lvalue they wrap with std::ref(), std::cref(), std::move() or my own helper copy() which makes the copy explicit and converts the lvalue to a rvalue. (std::ref() and std::cref() could only work if the arguments are template parameters... in which case the method would probably use std::forward<>() to handle the auto-detection of move vs copy semantics.

template<typename T>
T copy( const T& v ) { return v; }

If I am writing a method that does not 'store' or 'consume' the input then I use const&

I should probably clarify, that I would use const& for any types that do not benefit from move semantics (no deep copies). But when you are writing template code, you do not want to make that assumption about the type.

Another practice I am considering is making certain classes 'explicit copy only'.

class test  {
  public:
    test(){...};
    test( test&& t ){...}

  private:
    template<typename T>
    friend T copy(const T&t);

    test& operator=(const test&); // not implemented
    test( const test& t ){...}

    std::vector<char> large_data;
};

int main( int argc, char** argv ) {
  test x;
  test y = copy(x);
  test z = x; // error, test(const test&) is private...
  return 0;
}

I would use this for any class that contains any 'movable members', such a strings, vectors, maps, etc. Technically there is no reason why I couldn't copy them, but why shouldn't I attempt move semantics everywhere possible unless I really do want to copy? With implicit copies there is no way for the compiler to warn me that I am doing something potentially expensive.

Answer 7

Scott Meyers divided C++0x features into:

1. Features for everybody.
2. Features for Class authors.
3. Features for Library authors.

RValues are definitely Library authors.

Answer 8

If you're not implementing a value-semantics class, you don't really need to know.

Edit: Or perfect forwarding. But that's similarly mostly a library use.