Dynamic Memory — new & delete

Stack vs Heap Memory

So far, every variable you've declared — int x;, int arr[5]; — has lived on the stack: a region of memory that's automatically managed. When a function ends, its stack variables are automatically cleaned up. Fast, simple, but limited in size and lifetime.

The heap is a much larger pool of memory that you control manually. Memory on the heap stays allocated until you explicitly free it — even after the function that created it has returned. This is what makes the heap useful for data that needs to outlive a single function call, or whose size isn't known until the program is running.

Allocating a Single Value with new / delete

The new operator allocates memory on the heap and returns a pointer to it. When you're done with that memory, you must free it with delete — the exact counterpart to new.

// heap_single.cpp
#include <iostream>
using namespace std;

int main() {
    int* score = new int;   // allocate one int on the heap
    *score = 95;

    cout << "Score: " << *score << endl;

    delete score;   // free the memory — every new needs a matching delete
    score = nullptr;   // avoid a dangling pointer

    return 0;
}

Allocating a Dynamic Array with new[] / delete[]

To allocate an array on the heap — one whose size can be decided while the program is running, not fixed at compile time — use new[]. It must be freed with delete[], using the square brackets to match.

// heap_array.cpp
#include <iostream>
using namespace std;

int main() {
    int n = 5;
    int* arr = new int[n];   // allocate an array of 5 ints on the heap

    for (int i = 0; i < n; i++) {
        arr[i] = i * 10;
    }

    for (int i = 0; i < n; i++) {
        cout << arr[i] << " ";
    }
    cout << endl;

    delete[] arr;   // must use delete[] for arrays allocated with new[]
    arr = nullptr;

    return 0;
}

Memory Leaks — Why delete Matters

A memory leak happens when you allocate memory with new but never free it with delete. The memory stays reserved on the heap forever — even though your program has lost every pointer that could reach it — because nothing tells the operating system it's safe to reuse.

// leak_example.cpp — DON'T DO THIS, this function leaks memory
#include <iostream>
using namespace std;

void leakyFunction() {
    int* data = new int[100];
    // ... data is used here ...
    // BUG: missing "delete[] data;" — this memory is never freed
}   // data (the pointer) goes out of scope, the address is lost, the 100 ints leak forever

int main() {
    leakyFunction();   // every call leaks another 100 ints worth of memory
    return 0;
}

The fix is simple: always free what you allocate, in every code path — including any early return statements. A correct version of leakyFunction() would end with delete[] data; before its closing brace.

Dangling Pointers — The Bug to Avoid

A dangling pointer is a pointer that still holds the address of memory that has already been freed. Using it — reading it, writing to it, or even just checking it carelessly — is undefined behavior.

// dangling_pointer.cpp — DON'T DO THIS, the bug is using ptr after delete
#include <iostream>
using namespace std;

int main() {
    int* ptr = new int(42);
    delete ptr;              // memory is freed here

    // BUG: ptr still holds the OLD address — this is a dangling pointer
    cout << *ptr << endl;   // undefined behavior — do NOT do this

    return 0;
}

The fix, shown earlier in this lesson, is to set the pointer to nullptr immediately after deleting it: delete ptr; ptr = nullptr;. Dereferencing a nullptr still crashes your program — but it crashes predictably and immediately, which is far easier to debug than the silent corruption a dangling pointer can cause.

Looking Ahead: std::vector

Manually pairing every new with a delete is important to understand — but in modern C++, most day-to-day dynamic arrays are built with std::vector instead, which you'll meet later in this course's STL section.

Lesson Summary

Let's recap everything you learned in this lesson: