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 has a Character object.

When using new we can still construct our objects any way we normally would. For example, we can pass arguments to the constructor:

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 when the stack frame is removed after the function ends:

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 often too much of a burden.

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 C++ memory management, we've seen how manual management using new and delete can be cumbersome and error-prone. C++ offers a solution to this: smart pointers.

Smart pointers manage dynamic memory automatically, helping to avoid common memory management errors. Smart pointers are lightweight objects that can "own" an underlying resource in memory. When smart pointers get destroyed, they can automatically deallocate the underlying resource.

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.

Smart Pointer Usage

In the following example, we use a smart pointer, removing the need to manually call delete:

1#include <iostream>
2#include <memory>
3
Character Class (Unchanged)|Show
4class Character {/*...*/};
13
14int main(){
15  std::unique_ptr<Character> MyCharacter{
16    new Character{"Aragorn"}  
17  };
18
19  std::cout << MyCharacter->Name << '\n';
20  // No need to call delete
21  // it's handled automatically
22}

1Aragorn
2Destroying Character

Next Lesson

Smart Pointers and std::unique_ptr

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

ContinueView Course