Memory Model

By the end of this lesson you'll know where every variable lives in memory, how long it stays alive, why structs carry hidden padding, what the compiler is allowed to rearrange behind your back, and the first idea behind safe multithreading — the mental model that separates someone who writes C++ from someone who truly understands it.

Learn Python, JavaScript, Java and more with free interactive lessons, real projects and AI-powered help. Beginner-friendly.

Part of the free C++ course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

Think of your program's memory as a building . The code segment is the printed instruction manual bolted to the wall — fixed, read-only. The static/data segment is the lobby noticeboard: a few items that stay pinned up the entire time the building is open. The stack is a tall stack of trays in the canteen — you can only add or remove from the top , and trays vanish in the exact reverse order you added them. The heap is a giant warehouse: you can request a shelf of any size at any time, but you must remember to hand the shelf back, or it stays reserved forever (a memory leak ). Almost everything in this lesson is just "which part of the building does this object live in, and who clears it away?"

The stack and heap grow toward each other . A stack overflow happens when the stack runs past its limit (often 1–8 MB) — deep or infinite recursion is the usual culprit.

1. Where Variables Live: The Memory Layout

When your program runs, the operating system hands it an address space split into the segments above. Where a variable lives is decided by how you create it: a plain local goes on the stack , a global or static goes in the static/data segment, and anything you create with new goes on the heap . The compiled instructions themselves sit in the read-only code segment. Read this worked example, run it, then check the output against the comments.

2. Storage Duration & Object Lifetime

Storage duration answers "how long does this object's memory stay alive?" C++ has four kinds. Automatic is the default for locals — the object is born when control reaches it and dies at the end of its {' '} block, in reverse order of creation. Static (globals and static locals) lasts the whole program. Dynamic (made with new ) lasts until you call delete . Thread ( thread_local ) gives each thread its own copy. The example below makes the constructor and destructor announce themselves so you can watch lifetimes unfold.

Your turn. A heap object only dies when you free it — forget the delete and its destructor never runs (a leak). Fill in the blank so the Note is cleaned up properly.

3. Alignment & Padding

The CPU reads memory fastest when a value sits on an address that's a multiple of its size — this requirement is called alignment . An int usually wants an address divisible by 4, a double one divisible by 8. To honour that inside a struct , the compiler quietly inserts padding bytes between members, which is why sizeof a struct can be bigger than the sum of its parts. You can measure alignment with alignof(T) , and demand a stricter one with alignas(N) . Reordering members largest-to-smallest often removes padding.

Now you try. Use alignof and sizeof to ask the compiler directly about a type's alignment and a struct's padded size:

4. The As-If Rule & Happens-Before

The compiler is not obliged to run your statements literally. The as-if rule lets it reorder, combine, or delete operations as long as the program's observable behaviour (its I/O and volatile access) is unchanged — that's how optimised builds get fast. On a single thread you never notice. Across threads , though, reordering can be dangerous, so C++ gives you the happens-before relationship: when a thread publishes data through a std::atomic store and another thread sees it through an atomic load, every write before the store is guaranteed visible after the load. That ordering guarantee is the whole foundation of safe multithreading.

The stack is automatic and fast: allocation is just moving a pointer, and cleanup is free because the object dies with its scope. The catch is size — the stack is small, so huge arrays and deep recursion overflow it. The heap is flexible: any size, any lifetime, but every new needs a matching delete , and forgetting leaks memory. The modern answer is to almost never write raw new / delete yourself — let a std::unique_ptr or container own the heap memory so the destructor frees it for you (RAII).

No blanks this time — just a brief and an outline. Predict the destruction order before you run it, then build it and check your output against the comments. Getting this right means you've internalised how lifetimes actually work.

Practice quiz

• Browse all free courses
• Cheat sheets & quizzes
• Coding dictionary