C++ Memory Management - The Stack

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

We saw how we could create local variables within our functions. We may have predicted, therefore, that the stack has some memory available to store things required by our functions.

This is indeed the case - the stack has a small amount of memory available to it. 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.

The C++ 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 this in action using a class with a constructor and destructor:

1#include <iostream>
2using namespace std;
3
4class Character {
5public:
6Character() {
7  cout << "Creating Character" << endl;
8}
9~Character() {
10  cout << "Destroying Character" << endl;
11}
12};
13
14void SelectCharacter() {
15  Character Frodo;
16}
17
18int main() {
19  cout << "Program Starting" << endl;
20  SelectCharacter();
21  cout << "Program Ending" << endl;
22}
23

The output is as follows:

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

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

Class Constructors

Learn about a special type of function we can add to our classes, which we can use to control how our objects get created.

Limitations of Stack Allocation

This automated form of memory management is very useful, but it does have some limitations.

1. The amount of memory available on the stack is limited, so we need alternative techniques once we start creating larger objects
2. The fact that objects are automatically deleted and their memory freed restricts our options

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

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

On my machine, this program outputs the following:

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

The fact that line 3 was nonsense is perhaps predictable given the proceeding output. The Character has already been destroyed because it was allocated within the SelectCharacter function’s stack frame.

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

This is going to cause issues but, hopefully, the compiler will have warned us of this. Clang generated the following warning:

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

Returning stack-allocated data by value

Updating the previous example to return Frodo by value rather than by reference would have worked as expected:

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

1Getting Character Name:
2Frodo
3Destroying Character
4

When we return something from a function, that data is moved to the stack frame that called our function. In this example, it’s the main function that receiving Frodo

When we return Frodo by value, we’re moving the Frodo object. Now, the Frodo object is not destroyed when SelectCharacter ends. It is instead moved to main, and only destroyed once main ends.

Previously, when we returned a pointer, we’re moving just the pointer to the main function. The Frodo object is still within the SelectCharacter stack frame. Therefore, it gets destroyed with the stack frame, and the pointer that was moved to main is no longer useful.

We cover move semantics in more detail later in this course.

The Free Store

To get around these limitations, there is another place in memory where we can store data. This is called the free store.

There, we have much more control over the lifecycle of our objects. Most notably, our functions can place objects there, and they remain in place until we explicitly delete them.

We’ll see how we can use the free store in the next lesson.