Move Semantics

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 first understand why we need this feature at all, so let’s introduce some of the problems it’s designed to solve.

Often, the objects we create will need to store other objects within them. These sub-objects can often be containers such as std::vector objects, which themselves may contain many thousands of their own sub-objects.

For example, if we’re working with databases, we might have objects that are storing thousands of other objects, representing entries in that database.

If we were making a video game, we might have an object representing an entire level, comprised of thousands of sub-objects of various types (enemies, environment art, audio, and so on)

Resources and Subresources

In this lesson, we’ll represent subresources like this using a basic Subresource type, which we can imagine being expensive to copy. Below, we create two Subresource objects - one from the default constructor, and one from the copy constructor:

1#include <iostream>
2
3struct Subresource {
4  // Default constructor
5  Subresource(){
6    std::cout << "Creating subresource\n";
7  };
8
9  // Copy constructor
10  Subresource(const Subresource& Source) {
11    std::cout
12      << "Copying subresource (expensive!)\n";
13  }
14};
15
16int main() {
17  std::cout << "Subresource A:\n";
18  Subresource SubA;
19  
20  std::cout << "\nSubresource B:\n";
21  Subresource SubB{SubA};
22}

1Subresource A:
2Creating subresource
3
4Subresource B:
5Copying subresource (expensive!)

Given that a subresource is expensive to copy, it follows that if an object contains these subresources, it will also be expensive to deeply copy. Remember, deep copying refers to copying an object, in addition to copying every object within it.

Below, we introduce a Resource type to represent this idea. It has a default constructor that creates a new Subresource, and a copy constructor that copies the other object’s Subresource:

1#include <iostream>
2
Subresource|Show
3struct Subresource {/*...*/};
14
15struct Resource {
16  // Default constructor
17  Resource()
18    : Sub{std::make_unique<Subresource>()} {
19    std::cout << "Creating resource\n";
20  }
21
22  // Copy constructor
23  Resource(const Resource& Source)
24    : Sub{std::make_unique<Subresource>(
25      *Source.Sub)} {
26    std::cout << "Copying resource\n";
27  }
28
29  std::unique_ptr<Subresource> Sub;
30};
31
32int main() {
33  std::cout << "Resource A:\n";
34  Resource A;
35
36  std::cout << "\nResource B:\n";
37  Resource B{A};
38}

1Resource A:
2Creating subresource
3Creating resource
4
5Resource B:
6Copying subresource (expensive!)
7Copying resource

Why We Need Move Semantics

Naturally, we want to avoid causing expensive actions to occur unnecessarily, as they can degrade performance. Therefore, when copying an object is an expensive action, we naturally want to avoid copying things unnecessarily.

Below, we create a Resource, and then move it into a std::vector. With our current implementation, moving our Resource involves copying it, therefore incurring the performance cost:

1#include <iostream>
2#include <vector>
3
Subresource|Show
4struct Subresource {/*...*/};
15
16struct Resource {
17  // Default constructor
18  Resource()
19    : Sub{std::make_unique<Subresource>()} {
20    std::cout << "Creating resource\n";
21  }
22
23  // Copy constructor
24  Resource(const Resource& Source)
25    : Sub{std::make_unique<Subresource>(
26      *Source.Sub)} {
27    std::cout << "Copying resource\n";
28  }
29
30  std::unique_ptr<Subresource> Sub;
31};
32
33int main() {
34  std::cout << "Creating resource:\n";
35  Resource A;
36
37  std::vector<Resource> Resources;
38  std::cout << "\nMoving it into the vector:\n";
39  Resources.push_back(A);
40}

1Creating resource:
2Creating subresource
3Creating resource
4
5Moving it into the vector:
6Copying subresource (expensive!)
7Copying resource

The Move Constructor

The basic idea that helps us solve this situation involves introducing an alternative constructor. It works similiarly to the copy constructor but, instead of copying all the subresources to the new object, we just have the new object take control of the existing subresources.

In other words, rather than deeply copying the entire object, we perform a shallow copy, and then transfer ownership of the subresources to this new object. This process is referred to as moving and, to support it, our type would need to implement move semantics.

Let’s take a look at an example type that includes the move constructor: For now, this constructor isn’t doing anything different to the copy constructor, but we’ll add that complexity later in the lesson:

1#include <iostream>
2
3struct Resource {
4  // Default constructor
5  Resource() {}
6
7  // Copy constructor
8  Resource(const Resource& Source) {
9    std::cout << "Copying resource\n";
10  }
11
12  // Move constructor
13  Resource(Resource&& Source) {
14    std::cout << "Moving resource\n";
15  }
16};

Compared to the copy constructor, we should note two differences in how we define a move constructor:

• An additional & is appended to the parameter type, as in Resource&& instead of Resource&. We cover what this && syntax means in the next lesson
• Given the move constructor is eventually going to modify the source object (specifically, to steal its subresources), we don’t mark the parameter as const

std::move()

When we have implemented both copy and move semantics, we can then decide on a case-by-case basis whether it is more appropriate to copy or move an object.

In situations where we want to use our move semantics over our copy semantics, we can wrap the argument with the std::move() function. Below, we create three Resource objects:

• Original is created using the default constructor.
• A is created by copying Original using our type’s copy semantics
• B is created by moving from Original by wrapping the argument in std::move(), signalling to the compiler it’s safe to use our type’s move semantics in this scenario:

1#include <iostream>
2
Resource|Show
3struct Resource {/*...*/};
20
21int main() {
22  std::cout << "Original Resource:\n";
23  Resource Original;
24
25  std::cout << "\nResource A:\n";
26  Resource A{Original};
27
28  std::cout << "\nResource B:\n";
29  Resource B{std::move(Original)};
30}

Implementing Move Semantics

Getting back to our original goal, we can now represent it as wanting the flexibility of two different ways to create copies of our objects:

• The copy constructor is for scenarios where we still want to use the original object. The copy constructor leaves the original’s subresources in place, so it can continue operating as normal.
• The move constructor is for scenarios where we no longer need the original object. It moves the original object’s subresources to the new object. This is faster than copying them, but the original object may not be usable afterward, as it no longer has its subresources.

Let’s go back to our original example where our Resource was managing a Subresource, and implement our move constructor to implement this behaviour. How exactly move semantics should be implemented entirely depends on the nature of the resource and the nature of its subresources.

In this example, we have a single subresource - a std::unique_ptr. Standard library unique pointers have also implemented move semantics elegantly, allowing us to transfer ownership using std::move():

1#include <iostream>
2
Subresource|Show
3struct Subresource {/*...*/};
14
15struct Resource {
16  // Default constructor
17  Resource()
18    : Sub{std::make_unique<Subresource>()} {
19    std::cout << "Creating resource\n";
20  }
21
22  // Copy constructor
23  Resource(const Resource& Source)
24    : Sub{std::make_unique<Subresource>(
25      *Source.Sub)} {
26    std::cout << "Copying resource\n";
27  }
28
29  // Move constructor
30  Resource(Resource&& Source)
31    : Sub{std::move(Source.Sub)} {
32    std::cout << "Moving resource\n";
33  }
34
35  std::unique_ptr<Subresource> Sub;
36};

We covered std::unique_ptr in more detail earlier in the chapter:

Smart Pointers and std::unique_ptr

An introduction to memory ownership using smart pointers and std::unique_ptr in C++

We can now choose on a situation-by-situation basis whether we want to copy our Resource objects and take the performance hit, or wrap the argument in std::move() indicating it’s safe to just harvest the original’s subresources:

1#include <iostream>
2
Subresource|Show
3struct Subresource {/*...*/};
14
Resource|Show
15struct Resource {/*...*/};
38
39int main() {
40  std::cout << "Original Resource:\n";
41  Resource Original;
42
43  std::cout << "\nCopying Original:\n";
44  Resource A{Original};
45
46  if (Original.Sub.get()) {
47    std::cout
48      << "Original still has its subresource\n";
49  }
50
51  std::cout << "\nMoving Original:\n";
52  Resource B{std::move(Original)};
53
54  if (!Original.Sub.get()) {
55    std::cout << "Original no longer"
56      " has its subresource";
57  }
58}

1Original Resource:
2Creating subresource
3Creating resource
4
5Copying Original:
6Copying subresource (expensive!)
7Copying resource
8Original still has its subresource
9
10Moving Original:
11Moving resource
12Original no longer has its subresource

The Moved-From State

When our move semantics steal the resources from our original object for performance reasons, the original object may no longer be usable. Without its subresources, it can be in a dilapidated state, sometimes called the moved from state.

To tell the compiler we’re no longer interested in the object, and it’s safe to leave it in this state, we wrap it in std::move()

Most compilers can detect when we’re trying to use an object in this state and issue us with warnings:

1int main() {
2  Resource A;
3  Resource B{std::move(A)};
4
5  A.SomeFunction();
6}

1Warning	C26800	Use of a moved from object: 'A'

We also need to be mindful that our moved-from objects still exist until they are freed from memory. This means that even if we don’t directly use the object again, it could still have a destructor that is going to be called at some point in the future.

If we’re not mindful of our move semantics when writing that destructor, it can cause problems. Consider the following example:

1struct Resource {
2  ~Resource() { delete Sub; } 
3  
4  Resource(Resource&& Source)
5  : Sub{Source.Sub} {
6    // ...
7  }
8  
9  Subresource* Sub;
10};

Our movement constructor is taking control of the subresource, which is in a memory address we’ve called Sub. However, when our moved-from object is eventually destroyed, it’s going to delete Sub. So, the destructor of our moved-from object is going to damage our moved-to object, leaving it with a dangling pointer.

And later, when the moved-to object is deleted, it’s going to try to delete Sub; 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 Resource {
2  ~Resource() { delete Sub; }
3  
4  Resource(Resource&& Source)
5  : Sub{Source.Sub} {
6    Source.Sub = nullptr; 
7  }
8  
9  Subresource* Sub;
10};

We’re using raw pointers here to demonstrate the interactions and what can go wrong, but we should be using smart pointers here. They prevent a lot of these issues from ever arising, and allow our type to "just work" without requiring so much manual memory management.

We can delete our destructor and update Sub to be a std::unique_ptr:

1struct Resource {
2  ~Resource() { delete Sub; }
3
4  Resource(Resource&& Source)
5  : Sub{std::move(Source.Sub)} {
6    // ...
7  }
8    
9  std::unique_ptr<Subresource> Sub;
10};

The Move Assignment Operator

As we covered in the previous lesson with the copy assignment operator, we also generally want to implement the movement assignment operator. This allows us to also optimise the performance of our types when they’re used in expressions such as B = std::move(A):

1#include <iostream>
2
Subresource|Show
3struct Subresource {/*...*/};
14
15struct Resource {
16  // Default constructor
17  Resource()
18    : Sub{std::make_unique<Subresource>()} {
19    std::cout << "Creating resource\n";
20  }
21
22  // Move constructor
23  Resource(Resource&& Source)
24    : Sub{std::move(Source.Sub)} {}
25
26  // Move assignment
27  Resource& operator=(Resource&& Source) {
28    std::cout << "Moving by assignment\n";
29    Sub = std::move(Source.Sub);
30    return *this;
31  }
32
33  std::unique_ptr<Subresource> Sub;
34};
35
36int main() {
37  std::cout << "Resource A:\n";
38  Resource A;
39
40  std::cout << "\nResource B:\n";
41  Resource B;
42
43  std::cout << "\nMoving A to B:\n";
44  B = std::move(A);
45
46  if (!A.Sub.get()) {
47    std::cout << "A no longer"
48      " has its subresource";
49  }
50}

1Resource A:
2Creating subresource
3Creating resource
4
5Resource B:
6Creating subresource
7Creating resource
8
9Moving A to B:
10Moving by assignment
11A no longer has its subresource

Moving an object to itself

When implementing the copy operator in the previous lesson, we pointed out how it is technically valid to attempt to copy an object to itself, using an expression like A = A.

This consideration applies when writing a move assignment operator, too. An expression like A = std::move(A) is valid, so our move assignment operator should ensure its logic still holds up when both objects are the same.

We can test for this scenario by comparing the address of the source object (that is, the function parameter) to the this pointer:

1#include <iostream>
2
3struct Resource {
4  Resource() = default;
5
6  Resource& operator=(Resource&& Source) {
7    if (&Source == this) {
8      std::cout << "Same object - skipping";
9      return *this;
10    }
11    
12    // ...
13
14    return *this;
15  }
16};
17
18int main() {
19  Resource A;
20  A = std::move(A);
21}

1Same object - skipping

1#include <iostream>
2
3struct Resource {
4  Resource() = default;
5
6  // Copy constructor
7  Resource(const Resource& Source) {
8    std::cout << "Copying resource\n";
9  }
10};
11
12int main() {
13  Resource Original;
14  Resource Moved{std::move(Original)};
15}

1Copying resource

1#include <iostream>
2
3struct Resource {
4  Resource() = default;
5  
6  // Move constructor
7  Resource(Resource&& Source) {
8    std::cout << "Moving resource\n";
9  }
10};
11
12int main() {
13  Resource Original;
14  Resource Copied{Original};
15}

1error: 'Resource::Resource(const Resource &)': attempting to reference a deleted function

Summary

In this lesson, we've explored the concept of move semantics, learning how to efficiently transfer resources between objects to improve performance. The key points we learned include:

• The difference between copy semantics and move semantics, and the situations where each is appropriate.
• How subresources within objects make deep copying expensive and the role of move semantics in mitigating this cost.
• The implementation of the move constructor, which allows an object to take ownership of another object's resources.
• The use of std::move() to explicitly indicate that an object's resources can be moved, rather than copied.
• The concept of the moved-from state, and how objects in this state are typically left in a valid but unspecified state.
• How to fully implement move semantics in classes, through both the move constructor and move assignment operator
• The importance of handling self-assignment safely in move operations.
• The interaction between copy and move semantics, and how the compiler chooses between them based on the context.

Next Lesson

Value Categories (L-Values and R-Values)

A straightforward guide to l-values and r-values, aimed at helping you understand the fundamentals

ContinueView Course