Stack vs Heap Allocation

Overview

This lab uses a small console program to make the two places a C++ program stores its data directly visible: the stack, where every local variable lives until its enclosing scope ends, and the heap, where memory outlives any single function and has to be released by hand. Starting from a working demo that allocates a single int and a Person object on the heap, you will add stack-allocated equivalents alongside them, print addresses from both regions to compare them, watch a constructor and destructor fire at different points depending on where an object lives, and finally track down a memory leak caused by a missing delete.

Learning Objectives

By the end of this lab you will be able to:

• Explain the difference between stack memory and heap memory in terms of who allocates it and who is responsible for freeing it
• Identify, from a variable's declaration alone, whether it will be allocated on the stack or the heap
• Distinguish a stack address from a heap address by comparing printed pointer values from both regions in the same program
• Use `new` and `delete` correctly to allocate and release a single heap object
• Trace when a constructor and destructor run to determine whether an object was destroyed automatically at scope end or manually through `delete`
• Diagnose and fix a memory leak caused by a missing `delete`, and explain why a leak has no visible effect at first but becomes serious in a long-running program
• Distinguish the address-of operator `&` from the dereference operator `*`, and explain what each one does to a pointer
• Identify situations, such as a large array of objects or an object that must outlive the function that created it, where heap allocation is necessary and stack allocation is not an option

Concept

A C++ program needs somewhere to put every variable it creates, and it has exactly two places to choose from: the stack and the heap. Get this choice wrong and a program either loses data the moment a function returns, because a local variable stops existing as soon as its enclosing block ends, or it leaves memory reserved forever because nothing ever frees it. Neither failure produces a compiler error, so the difference has to be understood, not discovered by trial and error.

The stack is a fixed block of memory reserved for the current thread, and it behaves exactly like the data structure it is named after, or like a stack of plates in a kitchen cupboard. every function call pushes a new frame holding that function's local variables onto the top, the way a clean plate gets added to the top of the stack, and returning from the function pops that frame straight back off and reclaims its memory instantly, the way the top plate gets lifted off again. nothing is ever added or removed anywhere except the top, so there is never any question of where a stack variable is or how long it takes to find. Because a stack variable's memory is tied to the scope it was declared in, it has automatic storage duration. it is created and destroyed for you. The heap, by contrast, is a much larger pool of memory that any part of the program can request from at any time through dynamic allocation, more like a spare bedroom than a cupboard. things get put wherever there happens to be room, in whatever order they arrive, with no tidy top-of-the-stack rule governing any of it, and nothing about it is tied to a function's scope, so nothing about it is cleaned up automatically either. the only way to find something in the heap again later is to have kept hold of exactly where you put it, which is precisely what a pointer is for.

That push-and-pop rule is not just an analogy, it is exactly what happens while code runs. Every function call pushes a new stack frame holding that function's local variables and parameters, and every return pops the most recently pushed frame straight back off. Step through the short example below, a chain of three calls, to watch it happen. the highlighted line in the code tracks exactly what is executing at each step.

int main() {
    calculateTotal();
}

void calculateTotal() {
    calculateArea(5);
}

int calculateArea(int side) {
    return side * side;
}

A pointer is what connects a piece of code to a heap allocation, and it is simply a variable that stores a memory address instead of an ordinary value, declared with a type followed by an asterisk, such as int* h. Two operators move between a pointer and the thing it targets, and they are opposites. the address-of operator & takes an existing variable and produces its address, as in &stackInt, which is how a pointer can be made to target something that already exists, on the stack or the heap. the dereference operator * does the reverse. given a pointer, it reaches through the stored address to read or write the value sitting there, as in *h = 20, which leaves h itself pointing at the same place but changes the int at that address. The symbol * means two different things depending on where it appears. in a declaration, int* h, it says "h is a pointer to an int". in an expression, *h = 20, it means "the int that h points to".

Telling the two apart in source code has nothing to do with a variable's type and everything to do with how it is declared. A declaration that includes new somewhere in it, such as Person* peter = new Person();, puts the object on the heap, even though peter itself, the pointer holding that object's address, lives on the stack like any other local variable. A declaration with no new anywhere in it, such as Person stackPerson;, puts the entire object on the stack, with no separate heap request involved at all. A pointer type such as Person* is not by itself evidence of heap allocation, it only means the variable holds an address. the only thing that determines where the pointee lives is whether new produced that address.

Knowing how to tell stack and heap apart still leaves the practical question. given a free choice, why put something on the heap at all instead of just declaring it on the stack? Three situations force the choice. the first is size. the stack is a small, fixed block of memory, often only a few megabytes for an entire thread, so a large array declared directly on the stack, such as Person team[1000];, can exhaust it outright and crash the program with a stack overflow before a single line of useful work runs. The heap is far larger, limited mainly by how much memory the machine actually has, so a large array or a large number of objects, a level's worth of enemies in a game, belongs there instead, built with new Person[1000]. the second is lifetime. a stack object is destroyed the instant its function returns, so a function that needs to hand an object back to whoever called it, or store it somewhere that outlives the function entirely, such as inside a container owned by a different object, cannot return a pointer to a local stack variable. that pointer would point at memory that no longer belongs to anything the moment the function returns, a dangling pointer. only a heap allocation survives past the function that created it. the third is size unknown until the program is already running. a plain stack array's size has to be fixed before the program runs, but the number of enemies to spawn, or the number of lines read from a file, is usually only known once the program is already executing, and only new can request exactly that many elements at runtime.

The tool for requesting heap memory is the new keyword, which returns a pointer, an address, to the memory it reserved. Whoever holds that pointer is responsible for calling delete on it exactly once, and every single new in a program needs exactly one matching delete somewhere, no more and no fewer. forget it and the memory is never released, a memory leak. A leak rarely causes any visible problem right away, since the operating system reclaims all of a process's memory the moment it exits anyway, so a short console program that leaks once and then exits can look perfectly fine. The real damage shows up in a long-running program, such as a game that allocates a new object every frame without a matching delete, where each leaked allocation stays reserved for the rest of the run and the total leaked memory keeps growing the longer the program runs, eventually exhausting available memory and causing an allocation to fail or the process to be killed. Because a leak produces no compiler error and no immediate crash, treat every new as unfinished business until its matching delete exists somewhere in the code. A class's destructor, written as ~ClassName(), is where that matching delete usually belongs, since it runs automatically no matter where the object holding it was allocated.

Tasks

#include <iostream>
#include "Person.h"

int main()
{
    // Heap allocation: h itself is a stack variable, but new int reserves
    // space on the heap and returns its address.
    int* h = new int;
    *h = 20;

    // Heap allocation: peter is a stack variable holding the address of a
    // Person object that was constructed on the heap.
    Person* peter = new Person();

    // TODO: declare a stack-allocated int called stackInt, initialised to 20

    // TODO: declare a stack-allocated Person called stackPerson

    std::cout << "heap int address (h):        " << h << std::endl;
    std::cout << "heap Person address (peter): " << peter << std::endl;
    // TODO: print the address of stackInt with std::cout << &stackInt
    // TODO: print the address of stackPerson with std::cout << &stackPerson

    delete h;
    delete peter;
}

#include "Person.h"
#include <iostream>

Person::Person()
{
    this->age = new int;
    *this->age = 5;

    // TODO: print "Person constructed at " followed by this
}

Person::~Person()
{
    // TODO: print "Person destroyed at " followed by this

    delete this->age;
}

#include <iostream>
#include "Person.h"

int main()
{
    int* h = new int;
    *h = 20;

    Person* peter = new Person();

    int stackInt = 20;
    Person stackPerson;

    std::cout << "heap int address (h):        " << h << std::endl;
    std::cout << "heap Person address (peter): " << peter << std::endl;
    std::cout << "stack int address:           " << &stackInt << std::endl;
    std::cout << "stack Person address:        " << &stackPerson << std::endl;

    delete h;
}