Managing Memory Manually

In principle, manually controlling the lifecycles of our objects is incredibly simple. We use the new keyword to create an object, and use the delete keyword to get rid of it when it's no longer needed.

The new operator allocates memory for the type of object we want to create, and forwards any provided arguments to its constructor.

1new int(42);

It creates our object in dynamic memory, and returns a pointer to it:

1#include <iostream>
2
3int main() {
4  int* Number{new int(42)};
5  std::cout << "Number: " << *Number;
6}

1Number: 42

Below, we use new to create an object from a custom type:

1#include <iostream>
2
3struct Player {
4  std::string Name;
5  int Level;
6};
7
8int main() {
9  Player* PlayerOne{
10    new Player("Anna", 42)  
11  };
12
13  std::cout << "Name: " << PlayerOne->Name;
14}

When we no longer need an object created from new, we pass its pointer to the delete operator:

1#include <iostream>
2
3int main() {
4  int* Number{new int(42)};
5  std::cout << "Number: " << *Number;
6  delete Number;
7}

Whilst using new and delete seems simple in theory, as we'll see in this lesson, this is surprisingly difficult to do well. Additionally, the consequences of not doing it well can lead to serious bugs that are hard to detect and have unpredicable consequences.

The most obvious issue that we'll encounter when manually managing memory is not deleting every object we create. The effect of such mistakes is rarely noticable in the simple programs we create in an introductory course.

However, in the real world, C++ programs typically run for much longer periods of time. Such programs are designed as a loop, which continues until some signal is received that the program should end:

1int main() {
2  bool continueRunning{true};
3  while (continueRunning) {
4    // Do stuff...
5    if (userWantsToQuit()) {
6      continueRunning = false;
7    }
8  }
9}

Throughout a long-running program, we'll typically need to create many new objects. These might be new transactions to process in a banking application or new monsters to fight in a video game.

If we don't delete every object we create, the memory usage of our program increases over time. This is known as a memory leak:

1int main() {
2  bool continueRunning{true};
3  while (continueRunning) {
4    new int(42); 
5    // Memory leaks here
6  }
7}

Profiling tools can show the memory usage of our program. IDEs typically include tools that allow us to analyse what resources our programs are using, or we can use standalone tools such as Valgrind.

When debugging in Visual Studio, we can see what's going on in memory using the diagnostic tools. Our previous program continuously creates 42s and deletes none of them, causing its memory footprint to steadily increase over time:

Eventually, the system we're running on will have no more memory available. This means our program can't create any more objects, which likely means it can no longer function correctly.

Profiling tools are useful, but they can't catch everything. In complex programs with a lot of moving parts, memory leaks often aren't obvious. They don't always happen when our program is left idle. Rather, they happen in specific cases, or in response to specific user actions.

If we don't perform those actions whilst debugging, those memory leaks won't happen, so they won't show up in our tools. However, once our program is released and widely used, at least some of those users are likely to create the circumstances where the leak happens.

Therefore, we should proactively take steps to ensure all the components of our program - the classes and functions - are memory-safe. The best option for this is to simply avoiding new and delete entirely, and instead rely on containers that take care of the memory management for us. Examples include std::unique_ptr for single items, and std::vector for collections.

When that isn't possible, we should consider adopting design patterns that make memory management easier, such as RAII.

As our programs get more complex, scattering new and delete expressions throughout our code quickly gets difficult to keep track of. At any point in our program, it can be difficult to understand which objects have been deleted and which are still alive.

We should instead strive to establish some standard convention to describe when objects get created and destroyed.

The Resource Acquisition Is Initialization (RAII) pattern is one such example. In this context, the word resource refers to something that an object needs in order for that object to work correctly. These subresources are other objects.

For example, we can imagine having a Monster type, where each Monster object has some artwork that it uses to render itself to the screen. Therefore, each Monster might have a resource in the form of an Image object held as a pointer:

1struct Image {
2  int Width;
3  int Height;
4  // ...
5};
6
7class Monster {
8public:
9  Image* Art{nullptr}; 
10};

The RAII pattern ensures that the lifecycle of resources is tied to the lifecycle of the objects that manage them. In practice, this means resources are initialized in the object's constructor and released in the destructor, simplifying memory management:

1struct Image {
2  int Width;
3  int Height;
4  // ...
5};
6
7class Monster {
8public:
9  Monster() : Art{new Image(256, 256)} {}
10
11  ~Monster() {
12    delete Art;
13  }
14
15  Image* Art{nullptr};
16};

This pattern simplifies things in a few ways. First, it establishes the convention that if an object is alive, we can assume that the resources it depends on are also alive.

Secondly, it establishes a clear understanding of which code is responsible for deleting resources. If we delete a Monster we know we don't need to delete its subresources directly. The Monster class implements RAII, so it will take care of that for us:

1class Encounter {
2 public:
3  Encounter()
4  : A{new Monster()},
5    B{new Monster()},
6    C{new Monster()} {}
7
8  ~Encounter() {
9    // The Monster type uses RAII so they'll delete their
10    // Image resources - we don't need to worry about it here
11    delete A;
12    delete B;
13    delete C;
14  }
15
16  Monster* A{nullptr};
17  Monster* B{nullptr};
18  Monster* C{nullptr};
19}

RAII is also inherently recursive, so scales for arbitrarily deep dependency trees. This Encounter class also uses RAII, so can be managed in the same way from some object that holds an Encounter as a resource, such as a Dungeon:

1class Dungeon {
2 public:
3  Dungeon()
4  : A{new Encounter()},
5    B{new Encounter()} {}
6
7  ~Dungeon() {
8    // We don't need to worry about the Monsters
9    // as they're deleted by the Encounters
10    delete A;
11    delete B;
12  }
13
14  Encounter* A{nullptr};
15  Encounter* B{nullptr};
16}

Let's introduce another common way attempting to manage memory manually can trip us up. We'll create a Character class, and make it polymorphic by giving it a virtual function:

1class Character {
2public:
3  virtual void Render() {}
4};

We covered polymorphism and virtual functions earlier in the course if you need a refresher:

We'll update our Monster class to inherit from this polymorphic base type. We'll also add some logging to our Monster's constructor and destructor, so we can see when they're called:

1// CharacterTypes.h
2#pragma once
3#include <iostream>
4
Character Class (Unchanged)|Show
5class Character {/*...*/};
10
11class Monster : public Character {
12public:
13  Monster()
14  : Art{new Image{256, 256}} {
15    std::cout << "Creating Monster\n"; 
16  }
17
18  ~Monster() {
19    std::cout << "Deleting Monster\n"; 
20    delete Art;                        
21  }
22
23  Image* Art{nullptr};
24};

Let's use this polymorphism to create a Monster, and store it in a Character pointer. Some time later, when we're done with our Character, we'll dutifully delete it:

1// main.cpp
2#include "CharacterTypes.h"
3
4int main() {
5  Character* C{new Monster{}};
6
7  // ...
8
9  delete C;
10}

Running our program, we can see that the Monster constructor was called, but annoyingly, its destructor wasn't:

1Creating Monster

This Monster destructor deletes the Image asset that the constructor allocated, so the fact that it's not being called means we have a memory leak.

But why isn't the destructor being called?

Like with any C++ function, a destructor is statically bound by default as a performance optimization. The delete operator sees we're passing it a Character pointer, and the Character destructor is not virtual. Therefore, it calls the Character version of the destructor rather than searching for the more derived Monster version.

In general, if a type has any virtual function, then it should also have a virtual destructor. If we don't need any custom behaviour in the destructor, we can implement a virtual default destructor like this:

1// CharacterTypes.h
2#include <iostream>
3#pragma once
4
5class Character {
6public:
7  virtual void Render() {}
8  virtual ~Character() = default; 
9};
10
Monster Class (Unchanged)|Show
11class Monster : public Character {/*...*/};

With no further changes, our delete operator now calls the Monster destructor, fixing the memory leak:

1Creating Monster
2Deleting Monster

The previous lesson on copy constructors and operators may have prompted you to notice a further problem with our Monster class.

Let's create a copy of a Monster object by passing it by value to a function. After the function ends, we'll try to use its Art resource:

1#include <iostream>
2
Image Struct (Unchanged)|Show
3struct Image {/*...*/};
8
Monster Class (Unchanged)|Show
9class Monster {/*...*/};
20
21void Render(Monster EnemyCopy) {
22  // ...
23}
24
25int main() {
26  Monster* Enemy{new Monster()};
27
28  Render(*Enemy);
29
30  std::cout << "Art Width: "
31    << Enemy->Art->Width;
32}

1Art Width: -572662307

As the terminal output would indicate, our Image subresource has some issues. The problem is that it is being deleted too early. The highlighted line in the main function is then attempting to use a resource that has already been deleted. This is called a Use After Free (UAF) error, and it is yet another common pitfall we'll encounter when trying to manage memory manually.

Additionally, this simple program has a second memory issue, called a double free error. Specifically, we're calling new once (when we construct Enemy ) but delete twice (in the destructor of both Enemy and EnemyCopy).

Calling delete on a location that has already been freed results in memory corruption. In this case, the error happens in Enemy's destructor, which is called at the end of main, just before our program closes.

But, if we create two copies of a Monster instance, the corruption can happen when our program is still running. The following program is likely to crash before it logs anything:

1int main() {
2  Monster* Enemy{new Monster()};
3
4  Render(*Enemy);
5  Render(*Enemy);
6
7  std::cout << "Art Width: "
8    << Enemy->Art->Width;
9}

1.\out\build\x64-release\example.exe (process 11576) exited with code -1.

As we might expect, to solve these problems, we have to intervene in the copying process of Monster objects by defining the copy constructor and copy assignment operators.

Copy Constructor

Let's implement the copy constructor. This follows the same principles we covered in the previous lesson, but we now apply it to raw pointers. When a Monster object is copied, the copy needs to create its own Art resource, which we can do using the new operator:

1class Monster {
2 public:
3  // ...
4  Monster(const Monster& Other)
5  : Art{new Image{
6      Other.Art->Width, Other.Art->Height
7    }} {}
8  // ...
9};

Copy Assignment Operator

In the copy assignment operator, we have two approaches we can use. Either approach is valid - the best option will depend on our specific requirements.

The first option is to update the existing Art resource, using values from the Monster we're trying to copy. Typically, this involves calling the subresource's copy assignment operator.

In this case, we haven't implemented a copy assignment operator for the Image class, so we'd use the default provided by the compiler:

1class Monster {
2 public:
3  // ...
4  Monster& operator=(const Monster& Other) {
5    if (&Other == this) return *this;
6    *Art = *Other.Art;
7    return *this;
8  }
9  // ...
10};

The second option is to delete the existing resource and create a new one from scratch. This typically means calling the copy constructor of the resource type.

Again, we haven't provided a copy constructor for the the Image type, so this code will use the compiler-provided default:

1class Monster {
2 public:
3  // ...
4  Monster& operator=(const Monster& Other) {
5    if (&Other == this) return *this;
6    delete Art;
7    Art = new Image(*Other.Art);
8    return *this;
9  }
10  // ...
11};

The problem we encountered in the previous section is so ubiquituous that a convention exists to deal with it: the rule of three. It relates to the following three functions of a class:

• The destructor
• The copy constructor
• The copy assignment operator

The rule states that if we need to provide an implementation for any of these functions, we'd typically need to implement all of them.

This is because the primary scenario we'd need to provide a custom implementation for one of these functions is that the compiler-provided default isn't managing memory properly. As such, the compiler-provided defaults for the other two functions probably aren't managing memory properly either.

In modern C++, the rule of three is not a strict requirement. For example, we've seen how smart pointers like std::unique_ptr can automate the management of a resource, removing the need to create a destructor.

However, it still remains a useful rule of thumb. If we find ourselves writing a destructor, for example, we should consider whether we need to customise the copy constructor and operator too.

In modern C++, we want to avoid manual memory management as much as possible. To this end, a common goal is to minimise the occurrances of the new and delete operators in our code.

Smart pointers, such as std::unique_ptr, are the main way we can achieve this. When our object is managing its resource through a std::unique_ptr, we replace the new operator with std::make_unique(), and we don't need to use the delete operator at all:

1class Monster {
2 public:
3  Monster()
4  : Art{std::make_unique<Image>(256, 256)} {}
5
6  Monster(const Monster& Other)
7  : Art{std::make_unique<Image>(*Other.Art)} {}
8
9  Monster& operator=(const Monster& Other) {
10    if (&Other == this) return *this;
11    *Art = *Other.Art;
12    return *this;
13  }
14
15  std::unique_ptr<Image> Art;
16};

However, we can't use smart pointers everywhere. In this section, we'll cover some of the main techniques that are used to combine smart pointers with "raw" pointers, such as those returned by the new operator.

The get() Method

The get() method of standard library smart pointers returns the raw memory address of the object it is managing. This is useful when we need to provide that pointer to some function.

Such functions typically have no interest in assuming ownership over the object - they just need access to it. As such, they tend to receive the object as a raw pointer, and should never delete the object:

1void Render(Image* Art) {
2  // Render() can use Art
3  // ...
4  
5  // But it doesn't own it, so shouldn't delete it
6}
7
8int main() {
9  Monster A;
10  Render(A.Art.get());
11}

Constructor from Raw Pointer

Sometimes, we'll work with functions that dynamically allocate some memory, then return that memory address:

1Image* GetArt() {
2  return new Image{256, 256};
3}

We can imagine these functions transferring ownership of the object they create, and therefore the code that calls this function is responsible for ensuring the object that it returns is deleted.

Note that, in the examples in this section, we're imagining that GetArt() is a function that we cannot easily change. Perhaps it is coming from some external library. If we could change this function, we'd update it to create and return a std::unique_ptr, making the memory ownership intent clear.

But, if we can't update GetArt() to return a smart pointer, the next best thing is to immediately store its return value in a smart pointer. To help with this, std::unique_ptr has a constructor that accepts a raw, dynamically-allocated memory address as an argument:

1class Monster {
2 public:
3  Monster() : Art{GetArt()} {}
4  
5  // ...
6
7  std::unique_ptr<Image> Art;
8};

As always, the smart pointer is then assumed to be the owner of that resource, and will automatically handle deletion.

The reset() Method

The reset() method is how we tell a smart pointer it is now responsible for a different resource from what it is currently managing. We pass the dynamically allocated memory address to the reset() method.

The smart pointer will assume responsibility for this new resource. Additionally, if the smart pointer was previously managing a different resource, it will delete that resource:

1Image* GetArt() {
2  return new Image{256, 256};
3}
4
5class Monster {
6 public:
7  // ...
8  void UpdateArt(Image* NewArt) {
9    Art.reset(NewArt);
10  } 
11  // ...
12  std::unique_ptr<Image> Art;
13};
14
15int main() {
16  Monster A;
17  A.UpdateArt(GetArt());
18}

The release() Method

Finally, the release() method will cause the smart pointer to give up ownership over its resource without deleting it. It returns a raw pointer to the resource, so that some other object or function can take ownership, and ultimately delete it:

1void HandleArt(Image* Art) {
2  // ...
3  delete Art;
4}
5
6class Monster {
7 public:
8  // ...
9  ~Monster() {
10    HandleArt(Art.release());
11  }
12
13  std::unique_ptr<Image> Art;
14};

Having a function receive an argument by a raw pointer which it eventually deletes is rarely a good design. But, in this hypothetical example, we're imagining HandleArt() is a function that we cannot easily change. Therefore, we need to use the smart pointer's release() function to adapt to HandleArt()'s unusual behaviour.

If we could change HandleArt(), we'd update it to accept its argument as a std::unique_ptr. This makes it clear to callers that HandleArt() is going to assume unique ownership of the resource they provide, and that it will ultimately delete it.

In this lesson, we covered the following topics:

• We explored manual memory management using the new and delete operators.
• We discussed potential issues like memory leaks, use-after-free, and double-free errors.
• We introduced the RAII pattern to simplify resource management
• The Rule of Three was explained to guide the proper implementation of class functions that manage memory
• Finally, we examined how to combine smart pointers with raw pointers for effective resource management