Dangling Pointers and References

1#include <iostream>
2using namespace std;
3
4int* GetNumber(){
5  int Number{1};
6  return &Number;
7}
8
9int main(){
10  int* Result{GetNumber()};
11  cout << "Result: " << *Result;
12}

We might expect this to log out 1, but that is not the case:

1Result: -858993460

The compiler should give us a warning that we might have been doing something wrong on our return statement:

1Address of stack memory associated with local variable Number returned

Let's delve a little deeper into this warning, as we should understand what's going on here.

In the introductory lessons, we covered the idea of the stack, and how our functions each create stack frames.

Stack frames are a form of memory management.

The parameters and local variables that our functions create are stored within these stack frames.

Within our call to GetNumber(), we are allocated memory to store the int we created. We then returned that memory address to our main function:

However, stack frames are an automated form of memory management. When the function ends, its stack frame, and all the objects stored within it are destroyed.

We can see this by using a custom type with a destructor:

1#include <iostream>
2using namespace std;
3
4struct SomeType {
5  int Value{1};
6  ~SomeType(){ cout << "Destroying\n"; }
7};
8
9SomeType* GetObject(){
10  SomeType SomeObject;
11  return &SomeObject;
12}
13
14int main(){
15  SomeType* Result{GetObject()};
16  cout << "Result: " << Result->Value;
17}

1Destroying
2Result: -858993460

When we have a pointer or reference to an object, and that object is then deleted, the pointer is no longer useful. It is sometimes referred to as a dangling pointer or dangling reference.

If we attempt to use a dangling pointer or reference, our program's behavior becomes undefined. This often leads to unpredictable results, and may cause crashes or other serious issues.

This is because the memory our object was using is freed up for other purposes, meaning we no longer know what will be stored there by the time we use our pointer or reference.

In C++, objects have different lifetimes depending on how they're created. This concept is known as storage duration. The local variables we've been using in functions have what's called automatic storage duration - they're automatically created when the function is called and destroyed when it ends.

However, there are other storage durations in C++:

1. Static storage duration: Objects exist for the entire run of the program.
2. Thread storage duration: Each thread has its own copy of the object.
3. Dynamic storage duration: The programmer controls when objects are created and destroyed.

For now, we're primarily concerned with automatic storage duration and its implications. When we need an object to last longer than a single function call, we have several options:

• Create it in the global scope (though this should be used sparingly)
• Create it inside the main function
• Make it part of a longer-lived object

Later in the course, we'll cover memory management in more detail, and learn how to control object lifetimes more precisely. This will include techniques for dynamic allocation and smart pointers, which give us more flexibility in managing object lifetimes.

In this lesson, we briefly introduced the concept of storage durations, and how memory allocated on the stack is automatically freed when the stack frame is destroyed.

In particular, we covered the implications this has for objects returned by pointer or reference from functions, and how improper usage can cause memory problems.