🐸Memory Model

Memory Layout

Variables can either be created or destroyed. They can also exists on different locations (i.e the stack, heap or static storage)

Stack vs Heap

Stack

Variables created (i.e allocated) on the stack possess automatic storage duration. This means they are:

• allocated when execution enters their scope
• deallocated when out of scope

Why is stack allocation fast?

src: https://chessman7.substack.com/p/how-your-code-executes-a-guide-to

Allocating (and deallocating) variables on the stack is fast as it mainly involves incrementing (and decrementing) the stack pointer.

This is also the reason why uninitialized variables on the stack possess garbage values because the memory they occupy is not automatically zeroed.

To jog your memory, all the previous variable declarations in Variables and Pointers were all allocated on the stack.

int main () {
    int x = 5;
    int* p = &x;
    int arr[3] = {10, 20, 30};     
    // this copies the string literal onto the array on the stack
    char str[] = "hello";
    
    // the pointer str2 is on stack
    // the string literal world is stored in ROM
    const char* str2 = "world"; 
}

Consider the following example (please ignore the implementation details of Person class for now)

main.cpp

#include <iostream>

class Person
{
private:
    int age_;

public:
    Person(int age) : age_(age)
    {
        std::cout << "creating a person with " << this->age_ << std::endl;
    }
    int get_age()
    {
        return this->age_;
    }
    ~Person()
    {
        std::cout << "destroying a person with " << this->age_ << std::endl;
    }
};

int main()
{
    Person p1(10);
    Person p2(15);
    Person p3(20);
}

The following output is as shown:

Observe that similar to the Last-In-First-Out (LIFO) behaviour of literal stack data structure, objects are constructed in order of declaration. They are also destroyed in order of reverse order.

Note that the behaviour is tied to scope, objects are destroyed as soon as it exits the scope.

Code	Output
main.cpp int main() { Person p1(10); { Person p2(15); } Person p3(20); }

Heap

While the stack is fast, it does suffer from a few limitations:

• Size of the objects must be known / determinable at compile time
• The lifetime of objects is tied to scope

⚠️ More about the limitation

Consider the following code snippet:

int main()
{
    int n;
    std::cin >> n;
    int arr[n];
}

It appears to work when we try running with clang++ main.cpp -o hello-world

But look what happens when I try to run with stricter flags: clang++ -std=c++17 -Wall -Wextra -pedantic-errors main.cpp

This is because VLA (Variable-Length Arrays) are actually not part of standard C++. Indeed, the size of arrays must be known at compile-time.

Following the above school of thought, why does the below code still not work? 🤔

int main()
{
    int n = 5;
    int arr[n];
}

You can use a new keyword to allocate memory on the heap. Unlike the stack, the heap memory is not tied to scope. It persists until it is explictly deallocated with delete.

Let's take a look at how heap tackles these limitations:

main.cpp

#include <iostream>

int main()
{
    int n;
    std::cin >> n;
    int* arr = new int[n];
    for (int i = 0; i < n; i++) 
        arr[i] = i;
    for (int i = 0; i < n; ++i)
        std::cout << arr[i] << " ";
}

⚠️ Spot the error in the above code snippet

We've just encountered a common pitfall of allocating variables on the heap. The above code snippet is plagued by a memory leak.

The memory allocated using new is never deallocated using delete . This means the allocated memory remains reserved after after it's no longer needed.

We can fix the code by appending delete[] arr; to the back of the program like so:

main.cpp

#include <iostream>

int main()
{
    int n;
    std::cin >> n;
    int* arr = new int[n];
    for (int i = 0; i < n; i++) 
        arr[i] = i;
    for (int i = 0; i < n; ++i)
        std::cout << arr[i] << " ";
    delete[] arr;
}

Dangling Pointers

Another common pitfall that programmers often stumble upon is the issue of dangling pointers. This refers to the situation when we try to access memory that already has been deallocated.

main.cpp

#include <iostream>
int main() {
    int *p = new int(5);
    std::cout << *p << std::endl;
    delete p;
    std::cout << *p << std::endl; 
}

The above is an example of undefined behavior. For me, it prints 0 but the C++ standard makes no guarantees about what happens.

It could also potentially print 5, print garbage values or crash through a segmentation fault.