Copy Constructors and Operators

In this lesson, we’ll explore how objects are copied in more depth. There are two scenarios where our objects get copied. The first is when a new object is created by passing an existing object of the same type to the constructor:

1struct Weapon{/*...*/};
2
3int main() {
4  Weapon SwordA;
5  
6  // Create SwordB by copying SwordA
7  Weapon SwordB{SwordA};
8}

This copying process also happens when we pass an argument by value to a function. The function parameter is created by copying the object provided as the corresponding argument:

1struct Weapon{/*...*/};
2
3void SomeFunction(Weapon W) {/*...*/}
4
5int main() {
6  Weapon Sword;
7  
8  // Create the W parameter by copying Sword
9  SomeFunction(Sword);
10}

The second scenario is when an existing object is provided as the right operand to the = operator. In the following example, we’re expecting an existing PlayerTwo to be updated by copying values from PlayerOne:

1struct Weapon{/*...*/};
2
3int main() {
4  Weapon SwordA;
5  Weapon SwordB;
6  
7  // Update SwordA by copying values from SwordB
8  SwordA = SwordB;
9}

As we’ve likely noticed, C++ supports these behaviors by default, even when the objects we’re copying use our custom types. In this lesson, we’ll explore what that default behavior does, and learn how to override it when our classes and structs have more complex requirements.

Subresources

The primary reason we need to override the default copying behavior is when our type is holding pointers to other types. These objects are often referred to as "resources" or "subresources". Below, our Player type is holding a Sword resource in a pointer called Weapon:

1struct Sword{
2  std::string Name{"Iron Sword"};
3  int Damage{42};
4  float Durability{1.0};
5};
6
7struct Player {
8  Player(Sword* Weapon) : Weapon{Weapon} {};
9  Sword* Weapon{nullptr};
10};

When we copy a Player object, we should consider how subresources, such as the Weapon object, are handled as part of that process.

1int main() {
2  Sword Weapon;
3  Player A{&Weapon};
4  A.Weapon->Durability = 0.9;
5  
6  Player B{A};
7  B.Weapon; // What is this, exactly? 
8}

For example

• Should B.Weapon be the same object as A.Weapon? That is, should A.Weapon and B.Weapon point to the same memory address?
• Should B.Weapon be a new object, initialized with the same state (Name, Damage, and Durability) that A.Weapon had when it was copied?
• Should B.Weapon be a new object, initialized with some default values, ignoring A.Weapon's state?

The correct answer to questions like this depends entirely on the type of object we’re creating and the requirements of our program. This lesson will explore how we can control this copying process for our custom types, thereby allowing us to implement the behaviors that are most appropriate for our use cases.

Sharing Resources

Let’s start by examining how C++ behaves by default when we copy objects. We have a Player class that carries a Sword, which it stores as a pointer:

1struct Sword{};
2struct Player {
3  Player(Sword* Weapon) : Weapon{Weapon} {};
4  Sword* Weapon{nullptr};
5};
6
7int main() {
8  Sword IronSword;
9  Player PlayerOne{&IronSword};
10}

When we copy an object, we copy the pointers to its subresources, but not necessarily the objects to which they point. In the following example, we copy PlayerOne to create PlayerTwo.

Accordingly, PlayerOne.Weapon is copied to create PlayerTwo.Weapon. However, copying a pointer just means we now have two pointers pointing at the same underlying resource:

1#include <iostream>
2
3struct Sword{};
4struct Player {
5  Player(Sword* Weapon) : Weapon{Weapon} {};
6  Sword* Weapon{nullptr};
7};
8
9int main() {
10  Sword IronSword;
11  Player PlayerOne{&IronSword};
12  Player PlayerTwo{PlayerOne};
13
14  if (PlayerOne.Weapon == PlayerTwo.Weapon) {
15    std::cout << "Players sharing same weapon";
16  }
17}

1Players sharing same weapon

We can imagine this situation as representing PlayerOne and PlayerTwo sharing the exact same weapon. This is unlikely to be what we want and could cause problems as we build out our program with more complex behaviors.

For example, if PlayerOne modifies the weapon in some way, those changes will affect PlayerTwo too. As we begin to rely more heavily on manual memory management, this will cause further resource management problems which we’ll discuss in the next lesson.

Copying Unique Pointers

We covered std::unique_ptr in the previous lesson, and in particular, we introduced how unique pointers prevent this sharing problem by preventing themselves from being copied:

1#include <memory>
2
3struct Sword {};
4
5int main() {
6  auto WeaponA{std::make_unique<Sword>()};
7  std::unique_ptr<Sword> WeaponB{WeaponA};
8}

1error C2280: 'std::unique_ptr<Sword>(const std::unique_ptr<Sword>&)': attempting to reference a deleted function
2note: 'std::unique_ptr<Sword>(const std::unique_ptr<Sword>&): function was explicitly deleted

This also applies to classes that have std::unique_ptr member variables. If a class has such a variable, the objects of that class cannot be copied by default, as they contain a member variable that cannot be copied.

Let’s update our Player class to store its Weapon as a unique pointer (std::unique_ptr<Sword>) rather than a raw pointer (Sword*), so we can see this in action:

1#include <iostream>
2#include <memory>
3
4struct Sword{};
5struct Player {
6  Player()
7  : Weapon{std::make_unique<Sword>()} {}
8
9  std::unique_ptr<Sword> Weapon;
10};
11
12int main() {
13  Player PlayerOne;
14  Player PlayerTwo{PlayerOne};
15}

1error: 'Player::Player(const Player&)': attempting to reference a deleted function
2note: 'Player::Player(const Player&)': function was implicitly deleted because a data member invokes a deleted or inaccessible function 'std::unique_ptr<Sword>(const std::unique_ptr<Sword>)'
3note: 'std::unique_ptr<Sword>(const std::unique_ptr<Sword>)': function was explicitly deleted

Copy Constructors

If we pay close attention to the previous error message, we can note that the line that is attempting to copy PlayerOne is calling the function Player::Player(const Player&)

We might also recognize that the Player::Player syntax identifies this function as a Player constructor. We can also see it seems to be receiving a const Player& as an argument - that is, a constant reference to another Player object.

This constructor is called the copy constructor. It is invoked when we construct a new object from an existing object of the same type.

As we’ve seen in the past, we can copy objects by default. This is because the compiler provides default copy constructors for the types we create. We can replace these default constructors with our own custom implementations.

Let’s see an example by adding a custom copy constructor to our Sword:

1struct Sword {
2  Sword(const Sword& Original) {
3    std::cout << "Copying Sword\n";
4  }
5};

As usual, defining a constructor will delete the default constructor, but we can re-add it if needed:

1struct Sword {
2  Sword() = default;
3  Sword(const Sword& Original) {
4    std::cout << "Copying Sword\n";
5  }
6};

As we might expect, the copy constructor is invoked any time we construct a new object using an existing object of the same type. This includes when a function needs to create an object based on an argument passed to it by value:

1#include <iostream>
2
3struct Sword {
4  Sword() = default;
5  Sword(const Sword& Original) {
6    std::cout << "Copying Sword\n";
7  }
8};
9
10void SomeFunction(Sword) {}
11
12int main() {
13  Sword WeaponA;
14
15  // Constructing new Swords by copying WeaponA
16  Sword WeaponB{WeaponA};
17  Sword WeaponC = WeaponA;
18
19  // Passing by value is copying, too
20  SomeFunction(WeaponA);
21}

1Copying Sword
2Copying Sword
3Copying Sword

Let’s return to our original example, and implement the copy constructor for our Player objects. For now, we’ll simply replicate the behavior of the default copy constructor, with some additional logging:

1#include <iostream>
2
3struct Sword {
4  Sword() = default;
5  Sword(const Sword& Original) {
6    std::cout << "Copying Sword\n";
7  }
8};
9
10struct Player {
11  Player(Sword* Weapon) : Weapon{Weapon} {}
12  Player(const Player& Original) {
13    Weapon = Original.Weapon;
14    std::cout << "Copying Player\n";
15  }
16
17  Sword* Weapon{nullptr};
18};
19
20int main() {
21  Sword IronSword;
22  Player PlayerOne{&IronSword};
23  Player PlayerTwo{PlayerOne};
24
25  if (PlayerOne.Weapon == PlayerTwo.Weapon) {
26    std::cout << "Players sharing same weapon";
27  }
28}

As we can see from the output, the copy constructor for Sword is not invoked, and both of our Player objects are left sharing the same weapon:

1Copying Player
2Players sharing same weapon

1struct Player {
2  Player(Sword* Weapon) : Weapon{Weapon} {}
3  Player(const Player& Original)
4  : Weapon{Original.Weapon} {
5    std::cout << "Copying Player\n";
6  }
7
8  Sword* Weapon{nullptr};
9};

1struct Player {
2  Player(Sword* Weapon) : Weapon{Weapon} {}
3  Player(const Player& Original)
4  : Player{Original.Weapon} {
5    std::cout << "Copying Player\n";
6  }
7
8  Sword* Weapon{nullptr};
9};

Deep Copying

Let’s fix our root problem. Instead of having our copies share their subresources, let’s ensure every copy gets a complete copy of the subresources too.

This is easier and safer to do using smart pointers, so we’ll switch our implementation back to using a std::unique_ptr for now. We’ll cover how to do this using raw pointers in the next lesson.

Remember, the function arguments passed to std::make_unique() are forwarded to the constructor of the type we’re creating. We can invoke the copy constructor of that type by passing the object we want to copy.

This may include dereferencing a pointer to that object if necessary:

1auto WeaponA{std::make_unique<Sword>()};
2auto WeaponB{std::make_unique<Sword>(*WeaponA)};

Let’s use this in our Player example, where we retrieve the Weapon we want to copy by dereferencing the original player’s Weapon:

1#include <iostream>
2
3struct Sword {
4  Sword() = default;
5  Sword(const Sword& Original) {
6    std::cout << "Copying Sword\n";
7  }
8};
9
10struct Player {
11  Player() : Weapon{std::make_unique<Sword>()} {}
12  Player(const Player& Original)
13  : Weapon{std::make_unique<Sword>(
14    *Original.Weapon
15  )} {
16    std::cout << "Copying Player\n";
17  }
18
19  std::unique_ptr<Sword> Weapon;
20};
21
22int main() {
23  Player PlayerOne;
24  Player PlayerTwo{PlayerOne};
25
26  if (PlayerOne.Weapon != PlayerTwo.Weapon) {
27    std::cout << "Players are NOT sharing "
28    "the same weapon";
29  }
30}

As we can see from the output, the entire Sword object is now being copied, rather than just a pointer to it. As a result, our Player objects are no longer sharing the same Sword - they each get their own.

1Copying Sword
2Copying Player
3Players are NOT sharing the same weapon

Fully copying an object in this way is often referred to as deep copying. Before, where we were simply copying the pointer to the same underlying object, is referred to as shallow copying.

Copy Assignment Operator

There is another context in which objects are copied that we need to be mindful of when creating our classes. This happens when the = operator is used to update an existing object using the values of some other object of the same type:

1Player PlayerOne;
2Player PlayerTwo;
3
4PlayerTwo = PlayerOne;

As we’ve seen in the past, the compiler provides a default implementation of this operator for our types. The default implementation of this operator behaves in the same way as the default copy constructor, shallow-copying values from the right operand to the left operand.

In this case, our type contains a std::unique_ptr, which cannot be copied. As such, we get a similar error to what we had before if we attempt to use the = operator:

1#include <iostream>
2
Sword Struct|Show
3struct Sword {/*...*/};

1error C2280: 'Player& Player::operator =(const Player&)': attempting to reference a deleted function
2note: 'Player& Player::operator=(const Player&)': function was implicitly deleted because a data member invokes a deleted or inaccessible function
3note: 'std::unique_ptr<Sword>::operator=(const std::unique_ptr<Sword>&)': function was explicitly deleted

We can provide a custom implementation of this operator, using the same syntax we would when overloading any other operator. The error message above hints at what the function signature would be:

1Player& Player::operator=(const Player&)

That is, a function called operator= in the Player class that accepts a const reference to a Player object and returns a Player reference. The basic scaffolding would look like this:

1#include <iostream>
2
Sword Struct|Show
3struct Sword {/*...*/};
10
11struct Player {
Default Constructor|Show
12  Player() {/*...*/};
14
Copy Constructor|Show
15  Player(const Player& Original) {/*...*/};
21  
22  // Copy assignment operator
23  Player& operator=(const Player& Original) {
24    // Update this Player using data from Original
25    // ...
26    
27    // Then return a reference to it:
28    return *this;
29  }
30  
31  std::unique_ptr<Sword> Weapon;
32}
33
Main Function|Show
34int main() {/*...*/};

Our program will now compile, but our copy assignment operator isn’t doing anything useful. Let’s make it copy the Weapon.

However, unlike with the copy constructor, the copy assignment operator is not creating a new Player object. Rather, it is updating an existing Player, and this existing Player already has a Weapon.

Depending on our specific requirements, there are two main options we have to deal with this. We can update the existing Weapon to match the values from the Weapon we want to copy. That typically involves using the = operator, thereby calling the copy assignment operator on the Sword class:

1#include <iostream>
2
Sword Struct|Show
3struct Sword {/*...*/};
14
15struct Player {
Default Constructor|Show
16  Player() {/*...*/};
18
Copy Constructor|Show
19  Player(const Player& Original) {/*...*/};
25
26  // Copy assignment operator
27  Player& operator=(const Player& Original) {
28    *Weapon = *Original.Weapon;
29    return *this;
30  }
31
32  std::unique_ptr<Sword> Weapon;
33};
Unchanged Code|Show

1Copying Sword by Assignment

Alternatively, we can delete the existing Weapon and construct a new one, thereby calling the copy constructor for the Sword type.

As we saw within the Player copy constructor, we can pass the original player’s Weapon as the argument to std::make_unique<Sword>():

1std::make_unique<Sword>(*Original.Weapon)

This will invoke the Sword type’s copy constructor and return a std::unique_ptr that manages this new Sword.

The std::unique_ptr type has overloaded the = operator make updates like this easier. It ensures the object it was previously managing is deleted, so updating a std::unique_ptr looks much the same as updating any other type:

1#include <iostream>
2
Sword Struct|Show
3struct Sword {/*...*/};
10
11struct Player {
Default Constructor|Show
12  Player() {/*...*/};
14
Copy Constructor|Show
15  Player(const Player& Original) {/*...*/};
21
22  // Copy assignment operator
23  Player& operator=(const Player& Original) {
24    Weapon = std::make_unique<Sword>(
25      *Original.Weapon);
26    return *this;
27  }
28
29  std::unique_ptr<Sword> Weapon;
30};
Unchanged Code|Show

1Copying Sword by Constructor

Copying an Object to Itself

When defining a copy assignment operator, there is an edge case we need to consider: that both operands are the same object. This is rare, but technically valid code:

1int main() {
2  Player PlayerOne;
3  PlayerOne = PlayerOne;
4}

We should ensure the logic in our operator remains valid in this scenario.

The most common approach is to have our operator start by comparing the this pointer to the memory address of the right operand. If these values are equal, both of our operands are the same.

When this is the case, our copy operator typically doesn’t need to do anything, so we can return immediately:

1struct Player {
Default Constructor|Show
2  Player() {/*...*/};
4
Copy Constructor|Show
5  Player(const Player& Original) {/*...*/};
10
11  // Copy assignment operator
12  Player& operator=(const Player& Original) {
13    if (&Original == this) {
14      return *this;
15    }
16
17    Weapon = std::make_unique<Sword>(*Original.Weapon);
18    return *this;
19  }
20
21  std::unique_ptr<Sword> Weapon;
22};

Recursive Copying

As we’ve seen before, if a type doesn’t implement a copy constructor and copy assignment operator, the compiler generates them by default.

These default implementations simply iterate through all the member variables and call the copy constructor or copy assignment operator associated with their respective types. This process respects any custom implementations we’ve provided for those types.

For example, below we define a Party struct that contains Player objects. The Party class uses the default copy functions, whilst Player has provided custom implementations.

When we copy Party objects, the custom Player copy constructor and assignment operators are automatically invoked when appropriate:

1#include <iostream>
2
3struct Player {
4  Player() = default;
5  Player(const Player& Original) {
6    std::cout << "Copying Player by Constructor\n";
7  }
8
9  Player& operator=(const Player& Original) {
10    std::cout << "Copying Player by Assignment\n";
11    return *this;
12  }
13};
14
15struct Party {
16  Player PlayerOne;
17  // Other Players
18  // ...
19};
20
21int main() {
22  Party PartyOne;
23  Party PartyTwo{PartyOne};
24  PartyOne = PartyTwo;
25}

1Copying Player by Constructor
2Copying Player by Assignment

This means that, in general, objects that store subresources do not need to intervene to control how those subresources are copied, even if those subresources have non-standard requirements.

We simply implement those requirements by defining copy constructors and operators on the type that needs them. Objects that store instances of those types will then apply those behaviors automatically, with no additional effort required.

Preventing Copying

Sometimes, we don’t want our types to support copying. This can be an intentional design choice like with std::unique_ptr, or perhaps supporting copying for our type would be a lot of work, and we’d rather not do it until we’re sure we need that capability.

In either case, we should explicitly delete the default copy constructor and copy assignment operator. The syntax for deleting constructors and operators looks like this:

1struct Player {
2  Player() = default;
3  Player(const Player&) = delete;
4  Player& operator=(const Player&) = delete;
5};

Now, if someone tries to copy our object, they’ll get a compiler error rather than a program that could have memory issues or other bugs:

Player Struct|Show
1struct Player {/*...*/};
7
8int main() {
9  Player PlayerOne;
10  Player PlayerTwo{PlayerOne};
11  Player PlayerThree;
12  PlayerThree = PlayerOne;
13}

1error C2280: 'Player::Player(const Player&)': attempting to reference a deleted function
2note: 'Player::Player(const Player&)': function was explicitly deleted
3
4error C2280: 'Player& Player::operator=(const Player&)': attempting to reference a deleted function
5note: 'Player& Player::operator=(const Player&)': function was explicitly deleted

1#include <iostream>
2#include <memory>
3
4struct Quest {};
5
6struct Player {
7  Player()
8  : CurrentQuest{std::make_shared<Quest>()} {}
9
10  std::shared_ptr<Quest> CurrentQuest;
11};
12
13int main() {
14  Player One;
15  std::cout << "Quest Owner Count: "
16    << One.CurrentQuest.use_count();
17
18  // Create a copy
19  Player Two{One};
20  
21  if (One.CurrentQuest == Two.CurrentQuest) {
22    std::cout << "\nPlayers have same quest";
23  }
24  std::cout << "\nQuest Owner Count: "
25    << One.CurrentQuest.use_count();
26}

1Quest Owner Count: 1
2Players have same quest
3Quest Owner Count: 2

Summary

In this lesson, we've explored the intricacies of object copying in C++. We've covered copy constructors, copy assignment operators, and how to implement custom copying behavior. You've learned about shallow vs. deep copying, resource management, and how to prevent copying when necessary.

With this knowledge, you're now equipped to fully control object duplication in your programs. We’ll build on these techniques and learn how to manually manage memory in the next lesson.

Next Lesson

Managing Memory Manually

Learn the techniques and pitfalls of manual memory management in C++

ContinueView Course