Memory Management and the Stack

An introduction to memory management within C++, starting with stack-allocated memory.

In the beginner course, we introduced the concept of the call stack, which is generated by the function calls in our program.

The Call Stack and Debugging Functions

An introduction to how our function calls create a call stack, and how we can navigate it in a debugger.

We can see the call stack in action using a class with a constructor and destructor:

1#include <iostream>
2
3class Character {
4 public:
5  Character(){
6    std::cout << "Creating Character\n";
7  }
8  ~Character(){
9    std::cout << "Destroying Character\n";
10  }
11};
12
13void SelectCharacter() {
14  // A new stack frame is created for
15  // SelectCharacter.  Local variable Frodo is
16  // allocated on the stack
17  Character Frodo;
18  // When SelectCharacter ends, Frodo is
19  // deallocated. Destructor is called as the
20  // stack frame is removed
21}
22
23int main() {
24  std::cout << "Program Starting\n";
25
26  // Call SelectCharacter, creating and
27  // destroying Frodo
28  SelectCharacter();
29  // After SelectCharacter returns, its stack 
30  // frame is removed. Memory used by Frodo is freed
31  std::cout << "Program Ending\n";
32}

1Program Starting
2Creating Character
3Destroying Character
4Program Ending

If the concept of constructors and destructors are unfamiliar, I’d recommend reviewing this lesson:

Constructors and Destructors

Learn about special functions we can add to our classes, control how our objects get created and destroyed.

We’re already familiar that we can create objects within the local scope of our functions. An example of this is the Frodo object, created within the SelectCharacter() function of our previous example.

Stack Allocated Memory

Given we can create objects in our functions, we may have predicted, therefore, that the stack has memory available to store these objects.

This is indeed the case. When we create variables in our functions, we are given the appropriate amount of memory from the stack to store those variables.

When the function ends, the stack frame is removed, local variables are deleted, and the memory is freed up for other uses.

However, while the stack is incredibly efficient for managing memory on a function-by-function basis, it is not without its limitations.

Stack Limitation 1: Space

Typically, the size of the stack in a C++ program is determined by the operating system and the settings of the compiler used. For instance, on many systems, the default stack size might be around 1 MB to 2 MB.

This is generally sufficient for most routine operations and function calls. However, it's often not sufficient to store large objects, or large collections of objects.

Attempting to allocate large data structures on the stack can lead to a stack overflow, where the stack's limit is exceeded, potentially causing the program to crash or behave unpredictably.

Stack Limitation 2: Flexibility

This form of memory management where objects are deleted automatically is often useful, but it does restrict our options

For example, consider a scenario where we want our SelectCharacter function to return a pointer to the character:

1#include <iostream>
2
3class Character {
4public:
5  ~Character() {
6    std::cout << "Destroying Character\n";
7  }
8  string Name { "Frodo" };
9};
10
11Character* SelectCharacter() {
12  Character Frodo;
13  return &Frodo;
14}
15
16int main() {
17  Character* SelectedCharacter {
18    SelectCharacter()
19  };
20  std::cout << "Getting Character Name:\n";
21  std::cout << SelectedCharacter->Name;
22}

The output of this program could be something like the following:

1Destroying Character
2Getting Character Name:
31�I�^H�H�PTI�#@H�`#@H�@�* �D�f.�@�@

The fact that line 3 was garbage is perhaps predictable given the proceeding output. The Character has already been destroyed by the time we come to log its name. This is because it was allocated within the SelectCharacter function’s stack frame.

So, the Frodo pointer within our main function is pointing at memory no longer allocated to our program.

Hopefully, our compiler will have warned us of this:

1warning: reference to stack memory associated
2with local variable 'Frodo' returned

1Character SelectCharacter() {
2  Character Frodo;
3  return Frodo;
4}
5
6int main() {
7  Character SelectedCharacter {
8    SelectCharacter()
9  };
10  std::cout << "Getting Character Name:\n";
11  std::cout << SelectedCharacter.Name << '\n';
12}

1Getting Character Name:
2Frodo
3Destroying Character

Preview: The Free Store

So far, we've delved into the workings of stack memory in C++ and its limitations. In the next lesson, we’ll explore the Free Store, often referred to as the Heap.

What is the Free Store?

The Free Store is a region of memory that programs use to allocate objects whose lifetime is not tied to the scope of a function. Unlike stack memory, where objects are automatically managed and limited in size, the Free Store allows for dynamic memory allocation.

This means we can allocate memory at runtime, and it's your responsibility to free it when it's no longer needed.

Why Learn About the Free Store?

Understanding the Free Store is crucial because:

1. Flexibility in Memory Allocation: It provides a more flexible way to manage memory, especially when dealing with large data or when the size of data is not known at compile time.
2. Control Over Object Lifetimes: Objects in the Free Store remain alive until they are explicitly destroyed, giving us more control over their lifetimes.
3. Essential for Advanced C++ Features: It lays the foundation for understanding more advanced C++ concepts like smart pointers and dynamic data structures.

What We’ll Learn

In our upcoming lesson, we'll dive into:

• How to allocate and deallocate memory on the Free Store
• Best practices for managing dynamic memory
• Common pitfalls and how to avoid them
• Real-world examples to solidify our understanding

Next Lesson

Dynamic Memory and the Free Store

Learn about dynamic memory in C++, and how to allocate objects to it using new and delete

ContinueView Course