Copy Semantics, Elision, and RVO

When we’re dealing with dynamic memory and smart pointers, interesting questions and problems soon begin to arise.

Consider the following setup. We have Character objects who carry Sword objects. When a character is created, it creates a sword for itself, and it dutifully cleans up the sword when it gets destroyed:

1struct Sword {};
2
3class Character {
4 public:
5  Character() : Weapon{new Sword{}} {};
6  ~Character() { delete Weapon; }
7
8  Sword* Weapon;
9};
10

Problems arise when we try to use this simple class. What happens if we copy it?

1#include <iostream>
2
3struct Sword {};
4
5class Character {
6 public:
7  Character() : Weapon{new Sword{}} {};
8  ~Character() { delete Weapon; }
9
10  Sword* Weapon;
11};
12
13int main() {
14  Character A{};
15  Character B{A};
16
17  std::cout << "A's Weapon: " << A.Weapon;
18  std::cout << "\nB's Weapon: " << B.Weapon;
19}
20

1A's Weapon: 000002894CBD6F90
2B's Weapon: 000002894CBD6F90
3

Our two characters are sharing the same sword.

When one of our characters gets deleted, the shared weapon is also deleted. Then, the other character has a pointer to an object that, unbeknownst to it, no longer exists. This is referred to as a dangling pointer, and it’s a problem that we generally try to avoid.

On some machines, this program will also crash right before it exits, suggesting a second problem. Specifically, both characters are trying to free the same memory address from their destructor. That works fine when the first character is deleted, but when the second character is being removed, it will try to free a pointer that had already been deleted. This is a double-free error, which will typically result in a crash.

Trying Shared Pointers

We could try switching our implementation to use a shared pointer instead. This solves our crashing problem:

1#include <iostream>
2#include <memory>
3
4struct Sword {};
5
6class Character {
7 public:
8  Character()
9      : Weapon{std::make_shared<Sword>()} {};
10
11  std::shared_ptr<Sword> Weapon;
12};
13
14int main() {
15  Character A{};
16  Character B{A};
17
18  std::cout << "A's Weapon: " << A.Weapon;
19  std::cout << "\nB's Weapon: " << B.Weapon;
20}
21

But, it doesn’t solve the root problem - our characters are still sharing the same weapon:

1A's Weapon: 000002E2E7C944E0
2B's Weapon: 000002E2E7C944E0
3

Trying Unique Pointers

In our lesson on memory ownership, we saw that weak pointers take steps to try to prevent themselves from being copied.

As such, when we try to implement our above code using weak pointers, the compiler will throw an error:

1#include <iostream>
2#include <memory>
3
4struct Sword {};
5
6class Character {
7 public:
8  Character()
9      : Weapon{std::make_unique<Sword>()} {};
10
11  std::unique_ptr<Sword> Weapon;
12};
13
14int main() {
15  Character A{};
16  Character B{A};
17}
18

1'Character::Character(const Character &)':
2attempting to reference a deleted function
3

This error is somewhat indirect - it does not mention unique pointers. Instead, it is telling us that it is trying to find a Character constructor that takes a reference to another Character and that the function has been deleted.

The first part of that error does make sense - the line in our code that is causing the error is Character B{A}. This expression is indeed trying to construct a Character by passing a reference to another Character.

The constructor that handles code like this is referred to as the copy constructor. We haven’t defined one before, but code like this has generally worked anyway. This is because our classes come with default copy constructors.

However, now that we’ve added a unique pointer to our class, and unique pointers can’t be copied, the default copy constructor can no longer help us. That explains the second part of the error - the default copy constructor has been deleted.

So, we need to step in and define what it means to copy a Character.

Copy Semantics

The process of defining what it means for our objects to be copied is often referred to as implementing copy semantics.

In the previous example, we are constructing a Character by passing a reference to an existing Character. As with any construction, this calls a constructor on our class, specifically the copy constructor.

In the past, when we hadn’t defined a copy constructor, the compiler was calling a default one. That constructor was implementing the shallow copy behavior we were seeing.

Let's start to implement copy semantics, by implementing our copy constructor, thereby defining how our objects should be copied:

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    std::cout << "I'm being copied!";
13  }
14
15  std::unique_ptr<Sword> Weapon;
16};
17
18int main() {
19  Character A{};
20  Character B{A};
21
22  std::cout << "\nA's Weapon: " << A.Weapon;
23  std::cout << "\nB's Weapon: " << B.Weapon;
24}
25

Within our copy constructor, we’re constructing our new object, and we have a reference to our source object from which we can grab what we need. In the above constructor, we’re creating B, and Source is a reference to A.

Typically we don’t want to modify the source object when copying it, so we mark that reference as const.

Our code now compiles, although our new object doesn't have a Weapon:

1I'm being copied!
2A's Weapon: 000001A6C70170D0
3B's Weapon: 0000000000000000
4

Let's update our copy constructor so our new Character gets their own Weapon:

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    std::cout << "I'm being copied!";
14  }
15
16  std::unique_ptr<Sword> Weapon;
17};
18
19int main() {
20  Character A{};
21  Character B{A};
22
23  std::cout << "\nA's Weapon: " << A.Weapon;
24  std::cout << "\nB's Weapon: " << B.Weapon;
25}
26

1I'm being copied!
2A's Weapon: 00000135B3CF6D90
3B's Weapon: 00000135B3CF6E10
4

Implementing Deep Copying

The previous example gives our new Character its own new Weapon, but that might not be exactly what we want. Our second character's weapon isn’t copying the values from the original character’s weapon. Consider this example:

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

1A's Weapon: 00000244F4126410
2A's Weapon Damage: 20
3B's Weapon: 00000244F4126FD0
4B's Weapon Damage: 10
5

We modified A's weapon damage to 20 before we created a copy, but the copy had the default value of 10. This is because, within the Character's copy constructor, we’re not passing any arguments when we create the Weapon. Therefore, we’re creating the weapon using the default constructor:

1Character(const Character& Source)
2      : Weapon{std::make_unique<Sword>()} {}
3

We may instead what to call the copy constructor of the Weapon too, by passing in a reference to the source character’s weapon:

1Character(const Character& Source)
2    : Weapon{std::make_unique<Sword>(
3          *Source.Weapon)} {}
4

The Weapon class isn’t using any unique pointers, so it still has its default copy constructor in place. Our code now looks like this:

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

1A's Weapon: 0000021852C570D0
2A's Weapon Damage: 20
3B's Weapon: 0000021852C57110
4B's Weapon Damage: 20
5

We’ve now deeply copied our Character. Our new Character's weapon has the same values as the source Character's weapon. But, they are different weapons. Each Character now has its own, which can subsequently be updated and deleted independently.

Copy Assignment Operator

Copy construction isn’t the only way we can copy objects. We can also create copies with the assignment operator, =. Let's make a small adjustment to our main function to create an example of that:

1int main() {
2  Character A{};
3  A.Weapon->Damage = 20;
4  Character B;
5  B = A;
6}
7

Once again we’re getting a compiler error, which sounds similar to what we had before:

1'&Character::operator =(const Character &)':
2attempting to reference a deleted function
3

Similar to the copy constructor, classes come with a copy assignment operator by default, which implements shallow copying. But, given our class contains a unique pointer that cannot be copied, we now have to extend our copy semantics to implement the copy operator too.

The copy operator receives a reference to the object to be copied. Typically, we don’t want to modify the original object, so that reference will be const.

Our function needs to return a reference to itself, which we can do via the this pointer.

Beyond these considerations, the implementation of copy operators tends to be very similar to copy constructors:

1Character& operator=(
2    const Character& Source) {
3  Weapon =
4      std::make_unique<Sword>(*Source.Weapon);
5
6  return *this;
7}
8

If the above code is unclear, we have a two-part lesson on operator overloading which is likely to be helpful:

C++ Operator Overloading

Learn how we can enhance our classes and structs by letting them define their our own operators.

Overloading Unary Operators in C++

Learn how to enhance our C++ classes and structs by overloading unary operators such as ++ and --

Our objects should now work as expected, regardless of how they are copied:

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

1A's Weapon: 000001F5879668D0
2A's Weapon Damage: 20
3B's Weapon: 000001F587966F50
4B's Weapon Damage: 20
5

Objects Copying to Themselves

There is an edge case where both operands to the copy operator can be the same object:

1int main() {
2  Character A{};
3  A = A;
4}
5

This is quite an unusual expression, but it is valid code, and it means we can’t assume that the argument passed to the copy operator is different from the object we’re updating. If the logic in our operator is predicated on that, we are leaving a landmine in our code.

We can test whether the objects are the same by comparing the address of the incoming object to the this pointer:

1#include <iostream>
2
3class Character {
4 public:
5  Character& operator=(
6      const Character& Source) {
7    if (this == &Source) {
8      std::cout << "Objects are the same\n";
9    } else {
10      std::cout << "Objects are different\n";
11    }
12    return *this;
13  }
14};
15
16int main() {
17  Character A{};
18  A = A;
19
20  Character B;
21  B = A;
22}
23

1Objects are the same
2Objects are different
3

Copy Semantics and Pass-by-Value

Copy semantics also come into play when we have code that implicitly creates copies of our object. Typically, this involves scenarios where we’re passing our objects around by value.

The main scenario where this happens is when we’re passing an object by value into a function parameter. There, the copy constructor is used to create the object that our function receives.

Below, we’ve defined a copy constructor for our class. We’re passing by value twice in the following code - once when we pass A into our function parameter B, and again when that function is returning B

The exact behavior of the following code can vary based on the compiler, but for me, the copy constructor is used twice, and we have three different objects throughout the lifecycle of our program:

1#include <iostream>
2
3struct MyStruct {
4  MyStruct() = default;
5  MyStruct(const MyStruct& Source) {
6    std::cout << "\nCopying " << &Source
7              << " to " << this;
8  }
9};
10
11MyStruct Function(MyStruct B) {
12  return B;
13};
14
15int main() {
16  MyStruct A{};
17  Function(A);
18}
19

1Copying 000000448D99FC34 to 000000448D99FD14
2Copying 000000448D99FD14 to 000000448D99FD54
3

These two instructions requiring three different copies of our object in memory seem like a waste of resources.

In many cases, this is true - particularly if those objects are complex, and the act of deeply copying them is an elaborate process.

In the next lesson, we’ll see how we can implement move semantics, which allows us to make our classes more efficient.

Copy Elision and Return Value Optimisation (RVO)

Creating copies of our objects always has a performance overhead, so eliminating unnecessary copies is desirable. Compilers can help us here, through what is known as copy elision.

In the following example, likely, our MyStruct object is never copied. In almost all compilers, our std::cout message will not be displayed:

1#include <iostream>
2
3struct MyStruct {
4  MyStruct() = default;
5  MyStruct(const MyStruct& Source) {
6    std::cout << "Copying";
7  }
8};
9
10MyStruct GetStruct() {
11  MyStruct Example{};
12  return Example;
13};
14
15int main() {
16  GetStruct();
17}
18

When the compiler sees our Example struct being created in our GetStruct function, it understands where in memory our object is going to end up. From looking at the return value, Example is guaranteed to end up in the stack frame of main. So it just creates it there directly.

As a result, when we reach the return statement, we no longer need to copy our object from the GetStruct stack frame to the main stack frame - it was in the main stack frame the entire time. In this case, the compiler has avoided (or elided) the unnecessary copy. This is an example of return value optimization or RVO.

With a subtle change to our program, the compiler may no longer be able to invoke this form of RVO. Depending on the compiler, the following program likely creates both objects in the GetStruct frame and then copies the chosen one back to main.

This would trigger a single copy operation, noted by the output to the console:

1#include <iostream>
2
3struct MyStruct {
4  MyStruct() = default;
5  MyStruct(const MyStruct& Source) {
6    std::cout << "Copying";
7  }
8};
9
10MyStruct GetStruct(bool a) {
11  MyStruct ExampleA{};
12  MyStruct ExampleB{};
13  return a ? ExampleA : ExampleB;
14};
15
16int main() {
17  GetStruct(true);
18}
19

1Copying
2

The fact that a compiler can choose whether or not to call one of our functions is likely making some feel uneasy. The compiler making our program more performant is great, but it is also changing the behavior in this case.

Our copy constructor has a side-effect: it writes things to the console. How is it reasonable that the compiler can sometimes change the behavior of our program?

In this case, the compilers are doing what the C++ standard asks of them. The rules state that the compilers can (and in some cases, must) eliminate unnecessary copying, even if the copy constructor has side effects like updating global variables or outputting messages.

Because we don’t always know when copies are going to be created, it’s important that we only use the copy constructor for its specific purpose: copying objects.

If the compiler avoids creating a copy, any arbitrary code we had in a copy constructor will not run. But, if our constructor's only purpose is to copy objects, and no objects need to be copied, there’s no issue. We can enjoy the performance benefits the compiler gave us by not running it.

This same recommendation applies to destructors. When we have fewer copies, we also have fewer objects to destroy, so copy elision also indirectly reduces the number of destructors being run.