Dynamic Memory and the Free Store

In the previous lesson, we introduced memory management, and how memory is allocated on the stack.

The automatic memory management done for us in the stack kept our lives simple through the beginner courses. But, we saw two big constraints of stack-allocated memory:

• The amount of memory available on the stack is limited
• When a frame is removed from the stack, the memory it was using is released.

But, inevitably, there are going to be scenarios where we need to intervene and take control of the memory allocation and deallocation process.

When we need to do this, we will be placing our objects in dynamic memory.

Allocating Dynamic Memory with new

To create an object in dynamic memory, we use the new keyword.

Below, we create a Character object in dynamic memory, and we log out what was returned by that operation:

1#include <iostream>
2
3class Character {
4 public:
5  std::string Name{"Frodo"};
6
7  ~Character(){
8    std::cout << "Destroying Character\n";
9  }
10};
11
12int main() {
13  std::cout << new Character;  
14}

This will log out something like this:

10x624e70

0x624e70 looks like a memory address, which would suggest that new perhaps returns a pointer. This is indeed the case:

1#include <iostream>
2
Character Class (Unchanged)|Show
3class Character {/*...*/};
12
13int main() {
14  std::cout << (new Character)->Name;
15}

1Frodo

Like with any other pointer, we can store this in a variable:

1#include <iostream>
2
Character Class (Unchanged)|Show
3class Character {/*...*/};
12
13int main() {
14  Character* MyCharacter { new Character };
15}

During the execution of this program, we have memory on the stack that is being used to store a pointer. That pointer is pointing at a location in dynamic memory that is storing a Character object.

When using new we can still construct our objects any way we normally would, such as by providing arguments to a constructor. Our Character type supports aggregate initialization, so we can also use that in conjunction with new:

1#include <iostream>
2
Character Class (Unchanged)|Show
3class Character {/*...*/};
12
13int main(){
14  int* MyInt{new int{42}};
15  std::cout << *MyInt << '\n';
16
17  Character* MyCharacter{
18    new Character{"Gandalf"}
19  };
20  std::cout << MyCharacter->Name;
21}

142
2Gandalf

We can also use any expression that would create a value of the appropriate type. Below, we initialize our int using an arithmetic expression, and our Character using a function call:

1#include <iostream>
2
Character Class (Unchanged)|Show
3class Character {/*...*/};
12
13Character GetGandalf(){
14  return Character{"Gandalf"};
15}
16
17int main(){
18  int* MyInt{new int{40 + 2}};
19  std::cout << *MyInt << '\n';
20
21  Character* MyCharacter{
22    new Character{GetGandalf()}
23  };
24  std::cout << MyCharacter->Name;
25}

142
2Gandalf

Returning Memory Addresses from Functions

This allows us to address the problem from the previous chapter. Previously, objects created on the stack were deallocated as soon as their stack frame ended. That meant we couldn't use those objects, even if we wanted to.

But now, from within a function, we can create an object in the free store, and return a pointer to it from our function.

Because the underlying object is not being stored in the stack, it will remain available even after the function completes and its stack frame has been removed:

1#include <iostream>
2
Character Class (Unchanged)|Show
3class Character {/*...*/};
12
13Character* SelectCharacter(){
14  return new Character{"Gandalf"};
15}
16
17int main(){
18  Character* MyCharacter{SelectCharacter()};
19  std::cout << MyCharacter->Name;
20}

1Gandalf

Our program now logs out Gandalf as expected.

Freeing Memory using delete

Previously, we alluded to the fact that memory allocated to the free store isn't automatically managed for us.

We can see the effect of this from our previous examples. Our Character class defines a destructor, and that destructor logs to the console. But, throughout our program, we've never seen that message being logged.

Because we're now allocating memory in the free store rather than the stack, we are now responsible for deleting our objects.

This no longer happens automatically and, if we do not free the memory when it is no longer needed, we have a type of defect called a memory leak.

To delete an object we previously created by calling new, we call delete, with the pointer to the object:

1#include <iostream>
2
Character Class (Unchanged)|Show
3class Character {/*...*/};
12
13Character* SelectCharacter(){
14  return new Character{"Gandalf"};
15}
16
17int main(){
18  Character* MyCharacter{SelectCharacter()};
19  std::cout << MyCharacter->Name << '\n';
20  delete MyCharacter;
21}

Our program now works as expected, and cleans up after itself:

1Gandalf
2Destroying Character

Problems with new and delete

In complex programs, managing memory manually using new and delete can become very difficult. This is particularly true when many different components of our system rely on the same objects stored in the free store.

1. If we do not call delete, we have a memory leak
2. If we call delete on a resource that was already deleted, we cause memory corruption and defects (this is called a double-free error)
3. If we call delete too early, a component that was still using that resource will stop functioning

Additionally, even code that looks innocuous can cause memory leaks:

1void MyFunction() {
2  int* ptr { new int { 42 } };
3  AnotherFunction();
4  delete ptr;
5}

In this seemingly safe example, AnotherFunction() can fail, but our program may be able to recover from that failure. We show how to implement this in our later chapter on error handling.

But, even applying those techniques, we would still be left with a memory leak. This is because, when AnotherFunction() throws an error, MyFunction() will end before it reaches the instruction to delete the memory it allocated.

In complex software, the responsibility to delete every object exactly once, at the correct time, and in every scenario, is extremely difficult. The relatively unrestricted freedom we have to manage memory is one of the main reasons C++ is the most popular language for creating high-performance programs, but equally, improper handling of memory is by far the most common cause of defects.

Because of this, we typically adopt a more structured design around how memory is managed, and we use smart pointers to help us implement it.

Preview: Memory Ownership and Smart Pointers

In our journey through memory management, we've seen how manual management using new and delete can be cumbersome and error-prone. Rather than having an unstructured program where arbitrary unconnected objects are floating in memory, a model based around memory ownership can help mitigate this.

In this design, objects in memory are conceptually owned by some other object, which is in turn might be owned by some other object. When an object gets destroyed, it should destroy the objects it owns, and those objects should in turn destroy the objects they own. This continues down the hierarchy of ownership.

For example, a Dungeon object might own some Monster objects, and each Monster object owns an Image object that represents its visual appearance. When the Dungeon gets destroyed, it should destroy the Monsters it owns, and when each Monster gets destroyed, it should destroy the Image it owns.

Smart Pointers

Ideally, this destruction should happen automatically, so we don't even need to remember to set up and maintain a destructor that deletes the things we own. The C++ standard library offers some useful utilities to help set up this up: smart pointers.

Smart pointers are lightweight objects that can own an underlying resource in memory. When smart pointers get destroyed, they automatically deallocate the underlying resource, too.

Therefore, if a Dungeon holds a smart pointer to a Monster, the Dungeon conceptually owns the memory associated with that Monster, and the intermediate smart pointer takes care of the deletion automatically.

In the following code, std::unique_ptr<Monster> is an example of a smart pointer, with the < and > syntax indicating it is a template. We cover templates in more detail in the next chapter.

1#include <iostream>
2#include <memory> // For std::unique_ptr
3
4struct Image {
5  ~Image() {
6    std::cout << "Deleting Image\n";
7  }
8};
9
10struct Monster {
11  std::unique_ptr<Image> Texture{new Image};
12
13  ~Monster() {
14    std::cout << "Deleting Monster\n";
15  }
16};
17
18struct Dungeon {
19  std::unique_ptr<Monster> Goblin{new Monster};
20  std::unique_ptr<Monster> Dragon{new Monster};
21
22  ~Dungeon() {
23    std::cout << "Deleting Dungeon\n";
24  }
25};
26
27int main() {
28  Dungeon* D{new Dungeon};
29  std::cout << "Dungeon Complete!\n";
30  delete D;
31  std::cout << "Everything is cleaned up!";
32}

1Dungeon Complete!
2Deleting Dungeon
3Deleting Monster
4Deleting Image
5Deleting Monster
6Deleting Image
7Everything is cleaned up!

Types of Smart Pointers

We have access to several types of smart pointers, each with specific properties in how they implement ownership:

1. std::unique_ptr: This smart pointer maintains exclusive ownership of the object it points to. When the std::unique_ptr is destroyed, the object it was managing is automatically destroyed too.
2. std::shared_ptr: This pointer allows multiple std::shared_ptr instances to share ownership of the underlying resource. The resource is only deallocated when all of the std::shared_ptr objects that own it are destroyed.
3. std::weak_ptr: It works similarly to a std::shared_pointer, sharing access to an underlying resource, but without sharing ownership of the resource. In other words, once all the shared pointers go out of scope, a weak pointer will not prevent the underlying resource from being deallocated.

We explore std::unique_ptr in full in the next lesson.

Free and Unlimited Access

Professional C++

Unlock the true power of C++ by mastering complex features, optimizing performance, and learning expert workflows used in professional development

View Course