Rvalue References

A reference is a name that you can use as an alias for something else. That much you already know from Chapter 6. What you don’t know yet—how could you?—is that there are actually two kinds of references: lvalue references and rvalue references.

All references that you’ve worked with thus far are lvalue references . Normally, an lvalue reference is an alias for another variable; it is called an lvalue reference because it normally refers to a persistent storage location in which you can store data so it can appear on the left of an assignment operator. We say “normally” because C++ does allow reference-to-const lvalue references—so variables of type const T&—to be bound to temporary rvalues as well. We established as much in Chapter 8 already.

An rvalue reference can be an alias for a variable, just like an lvalue reference, but it differs from an lvalue reference in that it can also reference the outcome of an rvalue expression, even though this value is generally transient. Being bound to an rvalue reference extends the lifetime of such a transient value. Its memory will not be discarded as long as the rvalue reference is in scope. You specify an rvalue reference type using two ampersands following the type name. Here’s an example:

This code will compile and execute, but of course it is definitely not the way to use an rvalue reference, and you should never code like this. This is just to illustrate what an rvalue reference is. The rvalue reference is initialized to be an alias for the result of the rvalue expression count + 3. The output from the next statement will be 8. You cannot do this with an lvalue reference —at least not unless you add a const qualifier . Is this useful? In this case, no, indeed it is not recommended at all; but in a different context, it is very useful. It’s high time you found out when and why, don’t you agree?

Traditional Workarounds

In older code, one would often use an output parameter to output large objects instead of a return value. We first introduced the concept of output parameters in Chapter 8. For our example, this would mean redefining buildStringArray() as follows:

But let’s not dwell on this approach any further! The main message should be clear by now. While extra copies and allocations can mostly be avoided using output parameters, the problem is that doing so typically involves a rather awkward coding style. What you really want is code that is clear and intuitive—as close as possible to that of Ex17_01.cpp, ideally—but that at the same time avoids all the expensive copying.

Another traditional workaround is to allocate all Array<> objects in the free store. With this approach, the outline of your code already comes much closer to what you want. Using a C++11 smart pointer, it looks as follows:

However, even if we ignore the extra dynamic allocations, this approach clearly comes with a hefty syntactical overhead. For starters, you’d need a variable of type std::vector<std::unique_ptr<Array<std::string>>>, which is quite the impressive type name already. Also, you’d constantly have to dereference the Array<> pointers through their * and -> operators. Surely there must be a better, more elegant way, right?

Defining Move Members

Thankfully, modern C++ offers precisely what you want. C++11’s move semantics allows you to program in a natural, intuitive style, while at the same time avoiding any unnecessary, costly copy operations. You even do not have to alter the code of Ex17_01.cpp at all. Instead, you extend the Array<> template to ensure that the compiler knows how to instantly move a transient Array<> object into another Array<>, without effectively copying its elements.

For this, we’ll take you back to our earlier example, Ex17_01.cpp. There you studied the following statement:

Given a statement such as this, any C++11 compiler is, of course, well aware that copying the result of buildStringArray() is just silly. After all, the compiler knows full well that it’s a temporary object that is passed to push_back() here and is an object that is scheduled to be deleted right after. So, the compiler knows that you’d prefer not to copy the pushed Array<>. Clearly that’s not the problem. Rather, the problem is that the compiler has no other option but to copy this object. After all, all it has to work with is a copy constructor. The compiler cannot just magically “move” a temporary Array<> object into a new Array<> object—it needs to be told how.

Since the code to construct a copy of an object is defined by the copy constructor of its class (see Chapter 11), it’s only natural that the code to construct a new object from a moved object is defined by a constructor as well. We’ll discuss how you can define one next.

Move-Only Types

No discussion of std::move() is complete without an honorary mention of std::unique_ptr<>—undoubtedly the type whose variables you’ll be moving the most in modern C++ programming. As explained in Chapter 6, and again in Chapter 12, there must never be two unique_ptr<> smart pointers pointing to the same address in memory. Otherwise, both would delete (or delete[]) the same raw pointer twice, which is a perfect way to initiate a tragic failure of your program. It is thus only fortunate that neither of the two lines that are commented out at the end of the following code snippet compiles:

What would compile, however, are these two lines:

That is, while both copy members of std::unique_ptr<> are deleted (as explained in Chapter 12), both its move assignment operator and its move constructor are present. This is an outline of how you’d normally accomplish this:

To define a move-only type, you always start by deleting its two copy members (like we taught you in Chapter 12). By doing so, you implicitly delete the move members as well (more on this later), so to allow uncopiable objects to be moved, you must explicitly define the move members. Often, but not in the case of unique_ptr<>, it would suffice to use = default to define the two move members and have the compiler generate them for you.

Extended Use of Moved Objects

An lvalue expression by definition evaluates to a persistent value, which is a value that remains addressable after the execution of the lvalue’s parent statement. This is why the compiler normally prefers to copy the value of an lvalue expression. We just told you, however, how you can overrule this preference with std::move() . That is, you can force the compiler to pass any object to a move constructor or move assignment operator, even if it’s not a temporary. This raises the question, what happens if you keep using an object after it has been moved? Here’s an example (if you want, you can try this in Ex17_04):

In this specific case, you of course already know what will happen. After all, you’ve written the code for the move assignment operator of Array<> yourself. Once moved, an Array<> object will contain an elements pointer that is set to nullptr. Any further use of a moved Array<> then would trigger a null pointer dereference, which, as always, is destined to end in the tragic, gruesome death of your program. This example therefore nicely underlines the rationale behind this guideline:

This guideline applies for objects of Standard Library types as well. Completely analogous to Arrays, for instance, you must never simply keep using a moved std::vector<>. Doing so could very well end equally badly. You might hope that a moved vector<> is equivalent to an empty one. And while this may be so for some implementations, in general the C++ standard does not specify at all in which state a moved vector<> should be. What is (implicitly) allowed, however, and which is something that not too many developers will know, is this:

In the rare cases where you do want to reuse moved Standard Library objects, you should thus always check the specification of their move members. When a std::optional<T> object that contains a T value is moved, for instance, it will still contain a T value—a T value that is now moved (we covered std::optional<> in Chapter 8). Similar to a vector<>, the optional<> can safely be reused after calling its reset() member. Smart pointers are a scarce exception:

std::move() Does Not Move

Make no mistake, std::move()does not move anything. All this function does is turn a given lvalue into an rvalue reference. std::move() is effectively nothing more than a type conversion, not at all unlike built-in cast operators static_cast<>() and dynamic_cast<>(). In fact, you could almost implement your own version of the function simply like so (somewhat simplified):

Clearly, this moves nothing. What it does do, however, is make a persistent lvalue eligible for binding with the rvalue reference parameter of a move constructor or assignment operator. It’s these member functions then that are supposed to move the members of the former lvalue into another. std::move() only performs a type cast to make the compiler pick the right function overload.

If no function or constructor overload exists with an rvalue reference parameter, an rvalue will happily bind with an lvalue reference instead. That is, you can move() all you want; but if there’s no function overload standing ready to receive the resulting rvalue, it’s all in vain. To demonstrate this, we’ll again start from Ex17_04.cpp. As you may recall, this latest variant of our running example ended with these statements:

Obviously, the intent of this final statement is to move the 2,000 strings of more_strings into strings. And in Ex17_04 this worked flawlessly. But now see what happens if you remove the declaration and definition of the move assignment operator from its Array<> template. If you then run the main() function of Ex17_04.cpp once more, unaltered, the last line of the output reverts to this:

It does not matter that you still call std::move() in the body of main(). If there’s no move assignment operator for Array<> to accept the rvalue, the copy assignment operator will be used instead. So, always remember, adding std::move() is of no consequence if the function or constructor that you are passing a value to has no overload with an rvalue reference parameter!

An Rvalue Reference Is an Lvalue

To be precise, the name of a named variable with an rvalue reference type is an lvalue. Let’s show what we mean by this, as it turns out that many struggle with this idiosyncrasy at first. We’ll keep on milking the same example, naturally, so take Ex17_04 once again (make sure it contains the original Array<> template where the move assignment operator is still defined) and change the last two lines of the program to the following:

Notwithstanding that the rvalue_ref variable clearly has an rvalue reference type, the output of the program will show that the corresponding object is copied:

Every variable name expression is an lvalue, even if the type of that variable is an rvalue reference type. To move the contents of a named variable, you must therefore always add std::move():

While you’d normally not create an rvalue reference in the middle of a block of code like rvalue_ref in our latest example, the analogous situation does occur regularly if you define function parameters that are rvalue references . You can find an example of this in the next section.

Pass-by-Rvalue-Reference

In Exercise 16-1, you were tasked with defining a push_back() member function template for Array<>. If all went well, you created a function similar to this:

The part we’d like to draw your attention to here is the blatant amount of copying that this function performs. First, all existing elements are copied into the new, larger Array<> and then the newly added element as well. While still excusable for a Chapter 16 exam, in your Chapter 17 exam such needless copying will start costing you grades . And in this case it is not because copying on your exam is cheating, but because clearly you should at least try to move all these elements instead!

Fixing the loop that copies all existing elements appears easy enough. Simply apply std::move() to turn the lvalue elements[i] into an rvalue, right? Doing so clearly avoids all copies, provided that the template argument type T has an appropriate move assignment operator:

Now that all existing elements have been move()’d, let’s focus our attention on the newly added element. Omitting all irrelevant parts, this is thus the code we will consider next:

Your first instinct might be to simply slap another std::move() onto element, like so:

This will not work, though, and with good reason. element is a reference to a const T, meaning that the caller of the function expects the argument not to be modified. Moving its contents into another object is therefore completely out of the question. This is also why the std::move() type conversion function will never cast a const T or const T& type to T&&. Instead, std::move() converts it to the rather pointless type const T&&—a reference to a transient value that you’re not allowed to modify. In other words, because the type of element is const T&, the type of std::move(element) is const T&&, meaning that assigning the latter expression still goes through the copy assignment operator, despite the std::move().

But of course you still want to cater for those cases where the caller does not need the element argument anymore—that is, for those cases where push_back() is called with an rvalue. Luckily, you cannot only use rvalue reference parameters for move constructors and move assignment operators; you can use them for any function you want. And so you could easily add an extra overload of push_back() that accepts rvalue arguments:

The Return of Pass-by-Value

The introduction of move semantics has caused a significant shift in how you can and should define the parameters of certain functions. Before C++11, life was easy. To avoid copies, you simply always passed objects by reference, just like we taught you in Chapter 8. Now that support for move semantics is prevalent, however, pass-by-lvalue-reference is no longer always your best option. In fact, it turns out that passing arguments by value is back on the table, at least in some specific cases. To explain when and why, we’ll build further on the same push_back() example as just now.

In the previous subsection, we created two separate overloads of push_back(), one for const T& and one for T&& references . For your convenience, you can find this variant in Ex17_05A. While using two overloads is certainly a viable option, it does imply some tedious code duplication. One way to work around this duplication is to redefine the const T& overload in terms of the T&& one like so:

But there is an even better, more compact way, one where one single function definition is all you need. Somewhat surprisingly, this single push_back() definition will use pass-by-value. You’d probably never have guessed to replace two pass-by-reference overloads with one single definition that uses pass-by-value, but once you see it in action, you’ll surely appreciate the sheer elegance of this approach. If we again omit the irrelevant, this is what your new push_back() would look like:

Provided you only use types that support move semantics (such as Standard Library types), this function always does precisely what you want. It does not matter what kind of argument you pass it: lvalue arguments are copied, once, and rvalue arguments are moved. Because the function parameter is of value type T, a new object of type T is created whenever push_back() is called. The beauty is that in order to construct this new T object, the compiler will use a different constructor depending on the kind of argument. If the function’s argument is an lvalue, the element argument is constructed using T’s copy constructor. If it’s an rvalue, however, element will be constructed using T’s move constructor.

For nontemplated functions that inherently copy any lvalue input, however, the use of a single function with a pass-by-value parameter is a wonderfully compact alternative. Concrete examples would be functions with signatures such as setNumbers(std::vector<double> values) or add(BigObject bigboy). The traditional reflex would be to use pass-by-reference-to-const, but by passing the arguments by value instead, you can actually kill two birds with one stone. If defined like this, the same single function can handle both lvalues and rvalues with near-optimal performance!

To demonstrate that this effectively works, simply add the push_back(T) function we laid out here into the Array<> template of Ex17_04. Now that Array<> supports push_back(), it also makes sense to give the arraySize parameter of its constructor a default value of zero:

All other members can remain as they were in Ex17_04. With this, you can compose the following example program (the definition of buildStringArray() can be taken from Ex17_04 as well):

In main(), we create an Array of Arrays of strings, aptly named array_of_arrays. We begin by inserting an Array<> of 1,000 strings into this container. This Array<> element, aptly named array, is clearly pushed as an lvalue, so we expect it to be copied. That is a good thing: we still need its contents for the remainder of the program. At the end of the program, we add array a second time, but this time we first convert it into an rvalue by applying std::move() to the variable’s name. We do so in the hopes that the Array<> and its string array will now be moved instead of copied. Running Ex17_05B confirms that this is indeed the case; in total, array is copied only once:

The various move assignments occur in the body of the push_back() function. In between adding array as an lvalue and adding it again as an rvalue, we inject one extra string into it to be able to differentiate the two Array<> elements in the output. Note that in the process of pushing this additional string none of the 1,000 preexisting string elements inside array are copied either. They are all moved to a larger string Array<> through the move assignment operator of std::string!

In the following tip, we summarize the various guidelines regarding function parameter declarations that you have encountered throughout the book, mainly in Chapter 8 and here:

Return-by-Value

The recommended way for returning an object from a function has always been to return it by value; even for larger objects such as a vector<>. As we’ll discuss shortly, compilers have always been good at optimizing away any redundant copies of objects that you return from a function. The introduction of move semantics therefore doesn’t change anything for the best practices. There are many misconceptions in this area (believe us, there are!), however, so it remains well worth reviewing this aspect of defining functions as well.

Many sample programs in this chapter were built around the following function:

For our example, NRVO would entail that the compiler stores the result object directly in the memory designated to hold the function’s return value. That is, after applying NRVO, no memory is set aside anymore for a separate automatic variable named result.

So, adding std::move() at best makes things a little bit slower, and at worst it causes the compiler to copy the return value where it otherwise would not! Therefore:

Note that for return statements such as return value + 1; or return buildStringArray(100); you never have to worry about adding std::move() either. In both these cases you are already returning an rvalue, so adding std::move() would again be redundant.

Common examples for the latter case are return statements of the form return condition? var1 : var2;. While not obvious, a conditional expression such as condition? var1 : var2 is in fact an lvalue. Because it’s clearly no variable name, the compiler forsakes NRVO and will not implicitly treat it as an rvalue either. It will, in other words, look for a copy constructor to create the returned object (either var1 or var2). To avoid this, you have at least three options. Any of the following return statements will at least attempt to move the value that is returned:

Out of these three, the last one is most recommended. The reason is again that it allows a clever compiler to apply NRVO, something that with the former two forms is not allowed.

Always Add noexcept

It is important that all your move members have a noexcept specifier, assuming they do not throw, of course, though in practice move members rarely do. Adding noexcept is so important that we’ll even go out of our way to explain why this is so. The reason is that we firmly believe that knowing why a guideline exists makes you remember it all the better!

For this, let’s pick up where we left off earlier with Ex17_05B. In this example, you defined the following push_back() function for Array<>:

Looks good, right? Running Ex17_05B also confirmed that all redundant copies are gone. So, what’s wrong with this definition then? In Chapter 16 we cautioned you to look beyond apparent correctness. For one, we urged you to always consider what happens in case of unexpected exceptions. Any idea as to what could be wrong with push_back()? It might be good for you to reflect on this for a moment.

The answer is that, while unlikely, the move assignment operator of T could in principle throw an exception. This is especially relevant here since the Array<> template should work for any type T. Now consider what happens if such an exception occurred in the middle of the function’s for loop, or even while moving the new element?

In a way, adding the std::move() in the for loop has undermined the workings of the copy-and-swap idiom. With this idiom it is crucial that the object you are modifying (*this, typically, in the case of a member function) remains in pristine, untouched condition, right up to the final swap() operation. Any modification prior to the swap() does not get undone in case of an exception. So if an exception occurs inside push_back() while moving one of the objects in the elements array, there’s nothing in place to restore any earlier objects that were already moved into newArray.

It turns out that, no matter what you try, if a move member may throw at any time, there is in general no way for you to safely move the existing elements into the new array without copying. If only there was a way for you to know that a given move member never throws any exceptions. After all, if moving never throws, safely moving existing elements into a larger array becomes feasible. But, hang on. Of course, you know of such a way already! It was introduced in Chapter 16: the noexcept specifier. If a function is noexcept, you know for a fact that it will never throw an exception. In other words, what you want to somehow express in push_back() is this:

The move_assign_if_noexcept() function we need here to accomplish an efficient yet safe push_back() template should act as std::move(), yet only if the move assignment operator of T is specified to be noexcept. If not, move_assign_if_noexcept() should turn its argument in an lvalue reference instead, thus triggering the use of T’s copy assignment.

This is where we hit a minor bump in the road:

While implementing such a move_assign_if_noexcept() function is certainly possible, it unfortunately requires a technique that is actually way too advanced for a beginner’s book; concretely, it requires template metaprogramming. Before we go there, here’s an important conclusion already:

The upcoming sidebar briefly explains how you could implement the move_assign_if_noexcept() function required for our exception-safe push_back() member (you can find the result in Ex17_06). It involves template metaprogramming, so it is not for the faint-hearted. So, please feel free to skip straight ahead to the next regular subsection, where we’ll demonstrate the effect of adding noexcept to move members when using your types in Standard Library containers.

The “Move-and-Swap” Idiom

Before we move on to the final section of this chapter, we’ll first revisit the implementation of the Array<> move assignment operator. When we defined it earlier, near the beginning of the chapter, you didn’t know enough yet to implement this operator in a clean and elegant manner. Going back to this definition, isn’t there something that strikes you as suboptimal? We’ll throw in the noexcept specifier to get things going, as shown here:

What if we told you that you’re looking for code duplication?

In Chapter 16 we told you that it’s always good practice to avoid duplication as much as reasonably possible. Any duplication, even that of only one or a couple of lines of code, is just another opportunity for bugs—either now or in the future. Just imagine that one day you add an extra member to Array<>; it would then be easy to forget to update all places where they’re copied one by one. The fewer places you need to update, the better.

For copy assignment operators, you are already familiar with the standard technique to solve the analogous problem: the copy-and-swap idiom. Fortunately, you can use a similar pattern for move assignment operators as well:

This move-and-swap idiom eliminates both accounts of duplication. Any existing elements are deleted by the destructor of the automatic variable moved, and the responsibility of copying the members and assigning nullptr is delegated to the move constructor. Key is not to forget the explicit std::move() of rhs in the function body. Remember, and we cannot repeat this enough, a variable name is always an lvalue, even the name of a variable with an rvalue reference type!

Take care not to go too far in weeding out duplication. Given earlier guidelines, you may be tempted to reduce code duplication even more and combine the copy and move assignment operators into one single assignment operator of the following form:

At first sight, this looks like a nice and elegant improvement. Whenever the right side of an assignment is a temporary object, the rhs value argument to this assignment operator will be constructed and initialized using the move constructor. Otherwise, the copy constructor is used. The problem, however, is that it violates another guideline, which is that the move assignment operator should always be noexcept. Otherwise, you risk that the copy assignment is still used by containers and other Standard Library templates that move only when noexcept is present.

The following guideline thus summarizes our advice regarding defining assignment operators:

Default Move Members

Analogous to the two default copy members (see Chapters 11 and 12), compiler-generated move members simply move all non-static member variables one by one, in the order in which the member variables are declared in the class definition. If the class has base classes, their move constructors or move assignment operators are called first, again in the order in which the base classes are declared. An implicitly defined move member, finally, is always noexcept, as long as the corresponding member function is noexcept for all base classes and non-static member variables as well.

So, no surprises there. If the move members are defined by the compiler, they behave exactly as you’d expect. The main questions we still need to answer are as follows: When exactly does the compiler generate these default move members? And, why did it for instance not do so for our Array<> class template? The answer is as follows:

While this rule may appear fairly restrictive at first, it actually makes a lot of sense. Consider our original Array<> template. The compiler observes that you explicitly defined the destructor, copy constructor, and copy assignment operator. The only sensible reason for you to provide such explicit definitions is, of course, because the compiler-generated defaults would be wrong. From this, the compiler can draw only one sensible conclusion: if it were to generate default move members, they would almost certainly be wrong as well (note that for Array<>, this reasoning is most definitely sound!). When in doubt, generating no default move members at all is clearly always better than generating incorrect ones. After all, the worst that could happen to an object without move members is that it gets copied from time to time; this is a fate that pales in comparison to what might happen to objects with incorrect move members!

The Rule of Five

Naturally, whenever you define a move constructor, you should also define its companion, the move assignment operator—and vice versa. From Chapter 12 you’ll recall that the same holds when defining the copy members. These observations are generalized in the so-called rule of five. This best-practice guideline concerns the following five special member functions: the copy constructor, copy assignment operator, move constructor, move assignment constructor, and destructor. In other words, it applies to all special member functions except for the default constructor. The rule goes as follows:

The motivation, not by chance, is analogous to that in the previous subsection. As soon as you need to override the default behavior for any one of these five special functions, you almost certainly need to do so for the other four as well. For instance, if you need to delete or delete[] a member variable memory in the destructor, it stands to reason that a shallow copy of the corresponding member would be extremely dangerous. The converse is perhaps less obvious but generally holds as well.

Notice that the rule of five does not state that it is required to actually provide explicit definitions for all five special member declarations. It is perfectly OK to use = delete at times (for instance when creating uncopiable types—as shown in Chapter 12) or even = default (typically combined with some = delete definitions as well).

The Rule of Zero

The rule of five governs what to do if and when you declare your own special member functions. It does not say anything, however, about when you should do so. This is where the rule of zero comes in:

In a way, the rule of zero is what mathematicians would call a corollary of the rule of five (a corollary is a logical consequence of an already proven proposition). After all, the latter rule stipulates that defining any special member function instantly means defining five of them, as well as perhaps a swap() function, as you already know. Even with the copy-and-swap and move-and-swap idioms, defining these five members always involves writing a significant amount of code. And a significant amount of code means a significant number of opportunities for bugs and a significant maintenance overhead.

The usual motivational example is to consider what you’d need to do after adding a new member variable to an existing class. In how many places then do you need to add a line of code? One more line in the member initializer list of the copy constructor? And one in the move constructor as well? And, oh yes, we almost forgot about the extra line in swap()! Whatever the count is, nothing beats zero! That is, in an ideal world, all you’d have to do to add a new member variable is to add the corresponding declaration to the class definition. Nothing more, nothing less.

If you simply apply these principles to all member variables of your class, none of these variables should contain so-called raw or naked resources anymore. That normally implies that none of the five special member functions that the rule of five speaks about requires an explicit definition anymore either.

One consequence of respecting the rule of zero is that defining the rule of five member functions becomes reserved almost exclusively for when you define either a custom RAII type or (and this should be even rarer) a custom container type. Afterward, with these custom RAII and container types in place, you can then compose higher-level types that then mostly need no explicit copy, move, or destructor declarations of their own anymore.

There is one special member function we haven’t covered yet with the previous guidelines. This is the same one that is not covered by the rule of five: the default constructor. You can typically avoid having to define a default constructor by initializing all member variables in your class definition. We did this, for instance, for the Data class at the beginning of this section:

Mind you, you’ll recall from Chapter 11 that as soon as you declare any constructor, even one that is not a special member function, the compiler will no longer generate a default constructor. The rule of zero therefore most definitely does not preclude defaulting a default constructor like this: