C++ from the Machine Up

One linearized path that uses C++ to teach the thing that makes you a better engineer in any language: the cost model of computation. Where your data lives, when it dies, who owns it, what a copy costs, how a call dispatches — every other language decides these for you, silently. C++ makes you decide, so you must understand. Every lesson assumes only the ones before it; every cost claim comes with a number or a "what it compiles to."

The thesis, in one sentence: C++ refuses to hide the machine, and the discipline that organizes the whole language is the zero-overhead principle — you don't pay for what you don't use, and what you do use is as efficient as hand-written code. The series runs in five movements — make the machine visible, get ownership & lifetime under control, ask what abstraction costs, push work to compile time, and confront concurrency & the contract that pays for it all. Read it straight through, or start at the orientation for the map.

Who this is for

A working programmer who knows some high-level language (Python, JS, Java) but little or no C++. No systems background is assumed — every machine-level term (pointer, stack frame, the heap, RAII, vtable, cache line, undefined behavior) is defined when it first appears. By the end you can explain what a program actually is after compilation; reason about stack vs heap, copies vs moves, and ownership; predict whether an abstraction is free or costs a runtime indirection; read a container's cost model off its memory layout; write exception- and thread-safe resource-owning types by reflex; and recognize undefined behavior as the precise price of C++'s speed.

How this track is built

An original first-principles track — not a syntax tour and not a reference manual. It teaches modern C++ (C++17/20) in the order a dependency chain demands: the machine model first, then ownership and lifetime, then the cost of abstraction, then generic and compile-time programming, then concurrency and the undefined-behavior contract. The recurring habit it trains — what does this compile to, where does the memory live, who owns it, when is it freed, what did it cost? — is the part that transfers to every other language.

Part I · The machine (lessons 00–04)

Make the invisible visible: what "compiled" means, what an object and the stack are, what an address is, and the lifetime problem that powers everything after.

Orientation — why C++ makes you a better engineer

The thesis: C++ exposes the decisions other languages hide. The zero-overhead principle that organizes the language, the five questions you'll learn to ask of any line of code, and the full 20-lesson dependency chain in five movements.

Source to running process

What "compiled" really means: preprocess → compile → assemble → link → load. Translation units, declarations vs definitions, the linker and the one-definition rule, and why a build step buys you a program with no interpreter standing between your code and the CPU.

Objects, values, and the memory model

An object is a typed region of storage. Fundamental types and their sizeof, signed/unsigned overflow as a real hazard, the three storage durations (automatic/dynamic/static), and the stack frame drawn explicitly — why stack allocation is nearly free.

Pointers and references

An address is a value you can hold. &, *, nullptr, pointer arithmetic and the a[i] == *(a+i) identity, references as aliases, and the four jobs pointers do — optionality, sharing, iteration, and runtime polymorphism.

The heap and the lifetime problem

Why a heap exists, what new/delete cost, and the central question that drives the next movement — who frees this, and when? The three failure modes (leak, dangling pointer, double free) and the proof that manual management can't be won by discipline alone.

Part II · Ownership & lifetime (lessons 05–07)

The answer to "who frees this, and when?": deterministic destruction, how values copy and move, and ownership encoded in the type.

RAII — the central idea of C++

Bind a resource's lifetime to a scope so the destructor releases it deterministically — even on an early return or a thrown exception. The idea no garbage-collected language teaches, contrasted with GC and try/finally. Solves the leak from lesson 04.

Copy, move, and value semantics

C++ copies by default. Copy constructor and assignment, deep vs shallow copy and why a shallow copy of an owning pointer double-frees, move semantics as ownership transfer, and the rule of zero/three/five — with copy-vs-move cost in concrete numbers.

Ownership and smart pointers

Ownership as a design decision made explicit in the type: unique_ptr (sole, zero-overhead), shared_ptr (shared, with an atomic refcount cost), and weak_ptr (breaks reference cycles). Closes the leak/dangle/double-free trio for good.

Part III · The cost of abstraction (lessons 08–11)

Is it free? Layout against the cache, why a non-virtual call costs nothing, the virtual call you do pay for, and how to design a type that pulls it together.

Data layout and the cache

Struct alignment and padding, the memory hierarchy with real latency numbers (L1 ~1ns vs DRAM ~100ns), the 64-byte cache line, and why contiguous data beats pointer-chasing. The mechanical-sympathy lesson that explains why vector beats list.

Classes and zero overhead

Encapsulation, the implicit this pointer, and the zero-overhead principle made concrete: a non-virtual method compiles to a plain function call with a hidden argument — the same cost as a free function. Abstraction in C++ is often genuinely free; proven.

Polymorphism and the vtable

Dynamic dispatch is the abstraction you do pay for. The vtable and per-object vptr drawn explicitly, the cost of a virtual call (indirection, defeated inlining, a possible cache miss), object slicing, and when dynamic dispatch earns its keep.

Resource-safe class design

Movements I–III assembled into how you actually design a type: choose ownership first, prefer the rule of zero, apply RAII to any raw resource, and establish invariants in the constructor. A small resource-owning type built start to finish.

Part IV · Generic & compile-time thinking (lessons 12–16)

The cheapest abstraction is resolved before the program runs: templates, the containers and algorithms built from them, error handling, and using types to push bugs to compile time.

Templates — compile-time polymorphism

Write one algorithm for many types with zero runtime cost. Instantiation as the compiler stamping out a concrete version per type — the code-bloat trade and why there's no vtable cost. Why error messages are bad, and how C++20 concepts fix them.

STL containers and their cost models

Every container is an ownership + layout decision. vector as the default (with its geometric-growth amortization), why list is almost always wrong, map vs unordered_map, and the iterator-invalidation rules — in one cost table.

STL algorithms, iterators, and ranges

The iterator decouples algorithm from container — M+N code instead of M×N. Iterator categories, <algorithm> with lambdas, the half-open [begin, end) range, and C++20 ranges and lazy views as composable pipelines.

Error handling and exception safety

Two channels: exceptions (stack unwinding runs destructors — safe only because of RAII; ~zero cost until thrown) and value-based errors (optional, expected). The no-throw / strong / basic guarantees, and why RAII makes the basic guarantee almost free.

const & constexpr — types as a tool

Push bugs left: turn runtime errors into compile errors. Full const-correctness as a machine-checked contract, making illegal states unrepresentable with strong types, and constexpr to move computation to compile time with static_assert.

Part V · Concurrency & the contract (lessons 17–19)

The hardest costs: shared mutable state, what the CPU and compiler may reorder, and the undefined-behavior bargain that pays for the speed of the whole language.

Threads and races

Threads sharing one address space, the data race defined precisely (and why it's undefined behavior), shared mutable state as the enemy, RAII locks that never leak, deadlock and lock ordering, and false sharing — the cache lesson returning as a concurrency bug.

Atomics and the memory model

Why ++counter isn't atomic, what std::atomic makes indivisible, and the memory model: the compiler and CPU may reorder memory operations. Acquire/release vs seq-cst vs relaxed as a dial, a lock-free counter, and honest limits on lock-free code.

Undefined behavior — the contract, and the capstone

UB is the exact price of zero overhead: the standard lets the compiler assume you never break the rules, so it optimizes hard. The catalog, a worked miscompile where the optimizer deletes a safety check, the sanitizer defense — and the whole cost-model habit assembled.

How to read this

Straight through, in order — the series is a dependency chain, and each lesson's "Linear position" box names exactly what it assumes and what new capability it adds. If you only have time for the spine of the argument, read 00 → 04 → 05 → 07 → 08 → 10 → 12 → 19.