Move Semantics, std::move and rvalues

In our previous lesson, we saw how we could implement copy constructors and operators to implement copy semantics. Here, we’re going to implement move semantics.

However, it’s helpful to get some brief historical context first. The idea of "moving things" in C++ doesn’t work how most people expect, so a quick overview of how it came about is pretty helpful to understand what’s going on.

Implementing Move Semantics in the Copy Constructor

The first thing to note about the move constructor is that it didn’t always exist. It was added to the C++ spec in 2011 (C++11).

However, the desire to “move” objects had existed for decades. Before 2011, one of the ways we implemented move semantics was within the copy constructor.

Imagine we have a large, complex object with many thousands of sub-objects, perhaps contained in collections like vectors. Creating a deep copy of this object would be an expensive process.

There are situations where we can be more efficient with this. Rather than deeply copying everything to the new object, we can just have our copy constructor create the new object by stealing the resources of the old:

1struct MyStruct {
2  MyStruct(MyStruct& Source) {
3    Resources = Source.Resources;
4    Source.Resources = nullptr;
5  }
6  Resource* Resources;
7};
8

This would leave the old object in a dilapidated, semi-useless state. But, in situations where we weren’t going to use the old object again, that didn’t matter - we can just enjoy the performance gains.

A common use case for this is when we were returning the object by value from a function. Expending resources maintaining the integrity of the original object, given it was about to be deleted, seemed especially wasteful.

This process, where we quickly-but-destructively "copy" and object colloquially became known as “moving” the object. We didn’t move it - the old object is still there, it was just left in a deteriorated state, sometimes called the “moved-from” state.

Improving the Approach

Fundamentally, this was a hack, and it had some drawbacks. Most notably, the copy constructor is also called in situations where we really do want to create a deep copy of the object. For example, passing an object by value into a function also calls the copy constructor.

If our copy constructor was ruining our object for performance gains in a different context, that meant any time we pass our object into a function, it will also be ruined.

Eventually, C++11 gave us better options here, by giving us the ability to implement copying and moving as separate functions. However, from C++’s perspective, what copying and moving means is defined by us, the users.

The only thing the compiler is responsible for is deciding which constructor to call. What those functions do is up to us.

As a general practice, it’s perhaps easier to understand what’s going on if we don’t even think of our functions as copying and moving, but rather as two different ways to copy our objects:

• A “slow” copy, that prioritizes preserving the integrity of the original object, even if it means the new object takes longer to create
• A “fast” copy, that prioritizes creating the new object as quickly as possible, even if it means damaging the original object

Copy and Movement Semantic Interactions

Viewing movement as nothing more than a faster copy for situations where we don’t care about the original also helps us understand some of the behaviors we will see coming from the compiler. Most notably, the copy constructor can stand in for the movement constructor.

For example, if we try to “move” an object that doesn’t have a movement constructor, the compiler will not throw an error. It will just use the copy constructor instead.

After all, when we move something, we don't necessarily care if the old object is left in a dilapidated or pristine state, we only care about the new object. Both the copy and move constructors treat the new object with the same respect, so the copy constructor can safely stand in for a missing movement constructor. It just may run slightly slower than a movement constructor could.

The opposite is not true. When we copy something, we want the old object to still be usable afterward. The movement constructor isn’t intended for that - its main concern is creating the new object as quickly as possible, even if it means damaging the original object. So, it cannot be used instead of the copy constructor.

As such, if we try to copy an object, and all we have is a movement constructor, the compiler will throw an error

Lvalues and Rvalues

When we pass an object by value, the compiler needs to know whether it is safe to move the object, or it needs to perform a slower copy. The mechanism for deciding this is determining whether our function received an lvalue or an rvalue.

A simplification that helps understand the difference is to imagine lvalues are containers, and rvalues are the contents of the container. In the following example, x is an lvalue, and 5 is an rvalue:

1int x { 5 };
2

Without a container, an rvalue doesn’t last long. Typically, it is lost right after the expression it is used in is evaluated.

In the following example, 1, 5, and 6 are all rvalues. After this line of code, the rvalues 1 and 5 are forgotten as they’re not in an lvalue container. This specific rvalue 6 is bound to the x lvalue container, so it remains available as long as x is available.

1int x { 1 + 5 };
2

But how does this help us with move semantics? Imagine we have two function calls:

1int x { 5 };
2
3Function(x);
4Function(5);
5

The first function call receives x. x is an lvalue - it continues to exist after our function call.

The second function call receives 5. 5 is an rvalue - it is forgotten after our function call.

As such, the second call to our function does not have to afford it's argument the same level of respect, because it's just an rvalue..

Lvalue and Rvalue References

Within our functions parameters, we previously saw how we could capture lvalue references using the & character:

1void myFunc(int &x) {}
2

Whilst we didn’t draw attention to this nuance in the past, an error would be thrown if we attempted to pass an rvalue into an lvalue reference:

1void myFunc(int &x) {}
2
3int main() { myFunc(5); }
4

1candidate function not viable:
2expects an lvalue for 1st argument
3

This makes conceptual sense - by our function accepting a non-const reference, we are suggesting that it is going to modify it’s argument. But, it doesn’t make sense to modify an rvalue.

If we specify our argument as const, our code will compile successfully:

1void myFunc(const int &x) {}
2
3int main() { myFunc(5); }
4

We can explicitly create variables and parameters that accept rvalue reference. An rvalue reference is identified by two && characters.  Therefore:

• int& is an lvalue reference to an int
• int&& is an rvalue reference to an int

Let's see an example:

1#include <iostream>
2
3void myFunc(int& x) {
4  std::cout << "lvalue\n";
5}
6
7void myFunc(int&& x) {
8  std::cout << "rvalue\n";
9}
10
11int main() {
12  int x{2};
13  myFunc(x);
14  myFunc(5);
15}
16

1lvalue
2rvalue
3

The && syntax works alongside any of the other type concepts we’ve seen. For example, we can have a const int&&, an auto&&, and so on.

Let's see an example with a custom type:

1#include <iostream>
2#include <vector>
3
4struct Resource {};
5struct BigStruct {
6  std::vector<Resource>* Resources;
7};
8
9void myFunc(BigStruct& x) {
10  std::cout << "lvalue\n";
11}
12
13void myFunc(BigStruct&& x) {
14  std::cout << "rvalue\n";
15}
16
17int main() {
18  BigStruct Example{BigStruct{}};
19  myFunc(Example);
20
21  myFunc(BigStruct{});
22}
23

1lvalue
2rvalue
3

lvalue and rvalue references are the key mechanisms that allow us to differentiate between the copy and movement constructors.

• The copy constructor receives an lvalue reference (eg MyType& Source). Lvalues are assumed to continue to exist after our function ends, so our function needs to respect it. We need to copy (preserve) its resources.
• The move constructor receives an rvalue reference (eg MyType&& Source). Rvalues are assumed to be deleted right after our function ends, so our function doesn’t need to respect it. We can move (steal) its resources.

What std::move really does

With an understanding of lvalues and rvalues under our belt, we can go a little deeper on what std::move actually does. From our earlier discussion, it’s perhaps not surprising to find that std::move doesn’t move anything.

Rather, it is equivalent to static casting its argument to an rvalue reference. The following two lines are identical:

1BigStruct Example{BigStruct{}};
2
3std::move(Example);
4static_cast<BigStruct&&>(Example);
5

The effect of this is that the reference to our object that is returned by std::move it may (but not necessarily) change which version of an overloaded function is invoked when passed that reference.

The following code sample is identical to the previous one, with one difference: on the highlighted line, we’ve wrapped our Example lvalue with a call to std::move before passing it to myFunc. In the previous code, Example was passed to the lvalue overload of myFunc, but by casting it to an rvalue, it's now going to be passed to the rvalue overload of myFunc:

1#include <iostream>
2#include <utility>
3#include <vector>
4
5struct Resource {};
6struct BigStruct {
7  std::vector<Resource>* Resources;
8};
9
10void myFunc(BigStruct& x) {
11  std::cout << "lvalue\n";
12}
13
14void myFunc(BigStruct&& x) {
15  std::cout << "rvalue\n";
16}
17
18int main() {
19  BigStruct Example{BigStruct{}};
20  myFunc(std::move(Example));
21
22  myFunc(BigStruct{});
23}
24

1rvalue
2rvalue
3

Creating the Movement Constructor

Let's pick up from an example close to where we left off in our copy semantics lesson, where we have a Character class that implements a copy constructor:

1#include <iostream>
2#include <memory>
3
4struct Sword {};
5
6class Character {
7 public:
8  Character()
9      : Weapon{std::make_unique<Sword>()} {};
10
11  Character(const Character& Source)
12      : Weapon{std::make_unique<Sword>(
13            *Source.Weapon)} {
14    std::cout << "\nCopying!";
15  }
16
17  std::unique_ptr<Sword> Weapon;
18};
19
20int main() {
21  Character A{};
22
23  std::cout << "A's Weapon: " << A.Weapon.get();
24  Character B{std::move(A)};
25  std::cout << "\nA's Weapon: "
26            << A.Weapon.get();
27  std::cout << "\nB's Weapon: "
28            << B.Weapon.get();
29}
30

Within our main function, we cast A to an rvalue reference, and pass it to our Character constructor. We haven’t implemented move semantics yet, so we trigger the copy semantics instead. As a result, to give B its Sword, we create a copy of A's sword :

1A's Weapon: 0x1391eb0
2Copying!
3A's Weapon: 0x1391eb0
4B's Weapon: 0x13922e0
5

Let's implement the move constructor:

1#include <iostream>
2#include <memory>
3
4struct Sword {};
5
6class Character {
7 public:
8  Character()
9      : Weapon{std::make_unique<Sword>()} {};
10
11  Character(const Character& Source)
12      : Weapon{std::make_unique<Sword>(
13            *Source.Weapon)} {
14    std::cout << "\nCopying!";
15  }
16
17  Character(Character&& Source)
18      : Weapon{std::move(Source.Weapon)} {
19    std::cout << "\nMoving!";
20  }
21
22  std::unique_ptr<Sword> Weapon;
23};
24
25int main() {
26  Character A{};
27
28  std::cout << "A's Weapon: " << A.Weapon.get();
29  Character B{std::move(A)};
30  std::cout << "\nA's Weapon: "
31            << A.Weapon.get();
32  std::cout << "\nB's Weapon: "
33            << B.Weapon.get();
34}
35

We've added only the highlighted lines - no other code has changed. But, now that our class has defined move semantics, B can just take A's sword, avoiding the expensive copy operation:

1A's Weapon: 0xb63eb0
2Moving!
3A's Weapon: 0
4B's Weapon: 0xb63eb0
5

The Movement Assignment Operator

As we covered in the previous lesson with the copy assignment operator, we also generally want to implement the movement assignment operator. We've done that below, with the remaining class code unchanged:

1#include <iostream>
2#include <memory>
3
4struct Sword {};
5
6class Character {
7 public:
8  // ...
9  Character& operator=(Character&& Source) {
10    std::cout << "\nMoving by assignment!";
11    Weapon = std::move(Source.Weapon);
12    return *this;
13  }
14
15  std::unique_ptr<Sword> Weapon;
16};
17
18int main() {
19  Character A{};
20  std::cout << "A's Weapon: " << A.Weapon.get();
21  Character B{};
22  B = std::move(A);
23  std::cout << "\nA's Weapon: "
24            << A.Weapon.get();
25  std::cout << "\nB's Weapon: "
26            << B.Weapon.get();
27}
28

1A's Weapon: 0000026A8D586C10
2Moving by assignment!
3A's Weapon: 0000000000000000
4B's Weapon: 0000026A8D586C10
5

The following example implements all four movement and copy semantic functions, so we can see the differences:

1class Character {
2 public:
3  Character()
4      : Weapon{std::make_unique<Sword>()} {};
5
6  // Copy Constructor
7  Character(const Character& Source)
8      : Weapon{std::make_unique<Sword>(
9            *Source.Weapon)} {}
10
11  // Move Constructor
12  Character(Character&& Source)
13      : Weapon{std::move(Source.Weapon)} {}
14
15  // Copy Assignment
16  Character& operator=(
17      const Character& Source) {
18    Weapon =
19        std::make_unique<Sword>(*Source.Weapon);
20    return *this;
21  }
22
23  // Move Assignment
24  Character& operator=(Character&& Source) {
25    Weapon = std::move(Source.Weapon);
26    return *this;
27  }
28
29  std::unique_ptr<Sword> Weapon;
30};
31

Moved-from objects should have "indeterminate but valid" state

It’s worth reiterating that when we move an object, what we’re doing is moving its resources to a new object, and and leaving the original in a dilapidated, "moved-from" state.

We still need to be somewhat considerate of the moved-from object. After all, it still exists, and that means it can still cause issues if we're not careful. As such, the goal for moved-from objects is generally described as leaving them in a "indeterminate but valid" state.

The main factor that makes validity important is the fact that our old object is going to be destroyed at some point in the future. So, it's going to call it's destructor. If the moved-from state is not mindful of that, we can run into issues.

Consider the following example:

1struct MyStruct {
2  ~MyStruct() { delete Resources; }
3  MyStruct(MyStruct&& Source) {
4    Resources = Source.Resources;
5  }
6  Resource* Resources;
7};
8

Our movement constructor is handing over the resources to the new object. However, when our original object is destroyed, it’s going to delete the resources from under the new object, leaving it with a dangling pointer.

And later, when the new object is deleted, it’s going to try to free Resources again, causing a double-free error.

We can update our movement constructor to defuse these issues. Note, calling delete on a nullptr is supported - it just has no effect:

1struct MyStruct {
2  ~MyStruct() { delete Resources; }
3  MyStruct(MyStruct&& Source) {
4    Resources = Source.Resources;
5    Source.Resources = nullptr;
6  }
7  Resource* Resources;
8};
9

We’re using raw pointers here to demonstrate the interactions and what can go wrong, but we should be using smart pointers where possible. They prevent a lot of these issues from ever arising, and allow our class to “just work” without needing us to write so much code to manage memory:

1struct MyStruct {
2  MyStruct(MyStruct&& Source) {
3    Resources = std::move(Source.Resources);
4  }
5  std::unique_ptr<Resource> Resources;
6};
7