Copy Semantics and Return Value Optimization

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};

However, problems will soon arise once we begin using this class. We’ll introduce some of the problems, and how to solve them throughout this lesson.

Why do we need Copy Semantics?

Let’s see what happens when we try to create a copy of instances of our Character class:

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}

The first problem is that our two characters are sharing the same Sword, which is unlikely to be what we want:

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

Another problem arises when one of our characters gets deleted - the shared weapon is also deleted by the destructor. 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 removed, the destructor will try to free a memory location that had already been freed. This is a double-free error, which will typically result in a crash.

Using 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}

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

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

Shared Pointers using std::shared_ptr

An introduction to shared memory ownership using std::shared_ptr

Using Unique Pointers

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

Smart Pointers and std::unique_ptr

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

As such, when we try to implement our above code using unique 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}

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

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. We do this by defining the copy constructor ourselves, rather than relying on the default one.

Implementing 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}

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

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}

Now, we’re successfully copying the Character, and our new Character gets its own Weapon:

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

Deep Copying

The previous example gives our new Character its 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
Character Class (Unchanged)|Show
8class Character {/*...*/};
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}

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

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>()} {}

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)} {}

The Weapon class doesn’t use 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 { int Damage{10}; };
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
15  std::unique_ptr<Sword> Weapon;
16};
17
main Function (Unchanged)|Show
18int main() {/*...*/}

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

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:

1#include <iostream>
2#include <memory>
3
4struct Sword { int Damage{10}; };
5
Character Class (Unchanged)|Show
6class Character {/*...*/};
18
19int main() {
20  Character A{};
21  A.Weapon->Damage = 20;
22  Character B;
23  B = A;
24}

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

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

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 assignment 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 ossignment perators tends to be very similar to copy constructors:

1#include <memory>
2
3struct Sword { int Damage{10}; };
4
5class Character {
6 public:
7  Character()
8      : Weapon{std::make_unique<Sword>()} {};
9
10  // Copy constuctor
11  Character(const Character& Source)
12      : Weapon{std::make_unique<Sword>(
13            *Source.Weapon)} {}
14
15  // Copy assignment operator
16  Character& operator=(const Character& Source) {
17    Weapon =
18      std::make_unique<Sword>(*Source.Weapon);
19
20    return *this;
21  }
22
23  std::unique_ptr<Sword> Weapon;
24};

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

Operator Overloading

This lesson introduces operator overloading, a fundamental concept to create more intuitive and readable code by customizing operators for user-defined types

The this Pointer

Learn about the this pointer in C++ programming, focusing on its application in identifying callers, chaining functions, and overloading operators.

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

1#include <iostream>
2#include <memory>
3
4struct Sword { int Damage{10}; };
5
Character Class (Unchanged)|Show
6class Character {/*...*/};
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}

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

Copying Objects 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}

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}

1Objects are the same
2Objects are different

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 often, 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}

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

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 Optimization

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, our MyStruct object is unlikely to be copied. In almost all compilers, our "Copying" message will not be displayed:

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

1Done

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 constructed in the main() stack frame right from the start.

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\n";
7  }
8};
9
10MyStruct GetStruct(bool B) {
11  MyStruct Example1{};
12  MyStruct Example2{};
13  return B ? Example1 : Example2;
14};
15
16int main() {
17  GetStruct(true);
18  std::cout << "Done";
19}

1Copying
2Done

Summary

In this lesson, we explored copy semantics. The key concepts we learned include:

• The difference between shallow copying and deep copying.
• The Rule of Three in C++, which suggests that if you implement any of the destructor, copy constructor, or copy assignment operator, you should probably implement all three.
• A review of smart pointers, and how they can be used to avoid memory management issues like double-free errors.
• Implementing copy semantics in classes by defining copy constructors.
• The concept of copy assignment operators and how to properly handle self-assignment.
• How copy semantics affect passing objects by value and the function return values.
• An introduction to copy elision and Return Value Optimization (RVO) as compiler optimizations to reduce unnecessary copies

Next Lesson

Move Semantics

Learn how we can improve the performance of our types using move constructors, move assignment operators and std::move()

ContinueView Course