Course 1 built the OOP foundation. Course 2 starts with the everyday tool that foundation — and the rest of the standard library — is actually built on top of.

The Problem Templates Solve

Writing the same logic separately for every type — a max_int and a separate max_double — is genuinely repetitive. C has no generic mechanism beyond void * plus manual casting (losing type safety entirely) or macros (c2-4's own text-substitution trap, applied to "generic" code with none of the type checking a real function would provide).

Function Templates

Compile-Time Monomorphization

The real mechanism: the compiler generates a separate, fully concrete function for each distinct type actually used. Calling max_value with int and again with double produces two genuinely distinct compiled functions, each fully type-checked and optimized exactly as if hand-written for that specific type — not a single generic, runtime-dispatched function. Zero runtime overhead, at the cost of larger compiled binary size. This is a direct parallel to rust2-3's own generics chapter — Rust uses the identical monomorphization strategy, another rare point of real convergence between the two languages, alongside cpp1-5's own RAII/Drop parallel.

Class Templates

This is exactly the shape cpp2-2's own STL containers use — std::vector<int> genuinely is a template instantiation, not a special built-in construct.

Template Type Deduction

In most cases the compiler infers T from the arguments automatically — max_value(3, 7) works with no need to write max_value<int>(3, 7) explicitly, though the explicit form is always allowed.

A Compile Error You'll See — No Matching Function

If T doesn't support an operation the template body actually uses (e.g. calling max_value on a type with no > operator defined), the error surfaces at the instantiation site, often with a genuinely confusing, deeply nested message — a well-known rough edge of pre-C++20 templates. C++20 concepts improve this substantially; full depth is deferred to cpp3-2's own "Templates, Deeper" chapter.

Coding Challenges

c3-2 built a linked list and a hash table entirely by hand, because C offers nothing. This chapter is the direct payoff: the same shapes, already written, tested, and optimized, as class templates.

std::vector

A growable array. c3-2's own linked list required a manual malloc/free pair per node; std::vector manages its own memory internally via RAII — the caller never calls free at all.

std::vector Under the Hood

Contiguous memory, not a linked list — growing occasionally reallocates a larger block and moves every element over. Despite this, push_back is amortized O(1) — a real, important performance characteristic: individual calls are occasionally more expensive (during a reallocation), but averaged over many calls, the cost per call stays constant.

std::map

A direct resolution of c3-2's own hand-built hash table. std::map specifically is typically a balanced tree internally, not a hash table — giving O(log n) operations and genuine key ordering as a side benefit. std::unordered_map is the hash-table-based sibling — closer to c3-2's own separate-chaining structure — giving O(1) average operations but no ordering.

std::string

A real, growable string type — contrasted directly with c1-8's own char arrays: no manual null-termination tracking, no manual sizing, and .length()/.size() are O(1), unlike c1-8's own O(n) strlen scan. Concatenation uses +, via exactly cpp1-6's own operator overloading mechanism.

RAII All the Way Down

Every one of these containers is itself an RAII wrapper — exactly cpp1-5's own mechanism. A vector's destructor frees every element's memory automatically when the vector goes out of scope. Nothing here is new magic — it's cpp1-5's own idea, already written for you by the standard library.

Coding Challenges

cpp2-2's containers gave C++ real, standard data structures. This chapter is what makes them interchangeable: one std::sort, working identically across every container that offers iterators.

What an Iterator Is

A generalized pointer-like object. begin() points at the first element; end() points one past the last — never the last element itself, the "half-open range" convention [begin, end). Dereferencing (*it) gives the element; ++it advances.

Iterating With Iterators

cpp1-2's own range-based for (auto x : container) is genuinely sugar for exactly this iterator pattern, generated automatically underneath.

Why Iterators Exist — Generic Algorithms Over Any Container

The real payoff: std::sort/std::find/and friends don't know or care whether they're operating on a vector, a list, or a raw array — they only need begin()/end() iterators satisfying certain requirements. This is cpp2-1's templates applied one level up, at the algorithm level rather than the container level — std::sort is itself a function template.

std::sort

Sorts a range in place. c3-2's own hand-built structures never included a general sorting algorithm at all — writing one in C means implementing the actual algorithm by hand, every time.

std::find

A linear search returning an iterator to the found element, or end() if not found — the end()-as-sentinel pattern is idiomatic and used constantly across the STL.

Iterator Invalidation, Revisited

cpp2-2's own warn-box flagged reallocation invalidating iterators — with iterators now properly introduced, the fuller picture: erasing or inserting into a vector can invalidate iterators at or after the modification point too, not just growth-triggered reallocation.

Coding Challenges

cpp1-5's own Challenge 2 built a leak on purpose: a Circle* allocated with new, never deleted, because RAII only protects objects whose own lifetime is tied to a scope — and a raw pointer variable's scope has nothing to do with the heap object it points at. This chapter is the real fix.

The Gap Raw Pointers Leave Open

A raw pointer going out of scope destroys only the pointer itself, never the object it points to. Smart pointers close this gap by wrapping the raw pointer inside an RAII-managed object — exactly cpp1-5's own idea, applied specifically to ownership.

unique_ptr — Sole Ownership

Exactly one unique_ptr owns a given object at a time. When it's destroyed, it automatically deletes the object it owns — genuinely just cpp1-5's own IntArray wrapper, generalized and already written for you.

unique_ptr Cannot Be Copied

A real, deliberate constraint: copying a unique_ptr would mean two owners both believing they're responsible for deleting the same object — exactly the double-free class from c2-3's own catalog. The compiler enforces this directly; attempting to copy one is a compile error, not a runtime risk.

Ownership can be transferred via std::move — a direct preview of cpp2-5's own Move Semantics chapter. After the move, the source unique_ptr becomes empty.

shared_ptr — Shared Ownership via Reference Counting

Multiple shared_ptrs can jointly own the same object, tracked by a hidden reference count. The object is deleted only when the last owning shared_ptr is destroyed.

The Real Comparison to Rust

unique_ptr is essentially Rust's Box<T> — sole ownership, moved not copied, deterministic destruction. shared_ptr is essentially Rust's Rc<T> — reference-counted shared ownership, the identical strategy. This is genuinely another point of real convergence, alongside cpp1-5's RAII/Drop parallel and cpp2-1's monomorphization parallel — C++'s and Rust's own ownership models visibly converge here.

A Genuine Gap Even Here — No Compile-Time Enforcement

The honest caveat: nothing stops a programmer from also keeping a raw pointer to the object a unique_ptr owns, and using that raw pointer after the unique_ptr is destroyed — a genuine use-after-free, still fully possible. Smart pointers eliminate the forgetful class of memory bug — nobody forgets to call delete anymore — not the deliberate-misuse class. Rust's borrow checker closes both.

Coding Challenges

cpp2-4 used std::move to transfer a unique_ptr's ownership without explaining why it worked. This chapter is that explanation, in full.

The Problem — Unnecessary Copies

Returning a large object like a vector by value historically meant a full, expensive deep copy. Before C++11, this was a genuine performance problem, pushing programmers toward awkward workarounds — passing output parameters by reference instead of simply returning by value.

lvalues and rvalues

A necessary vocabulary: an lvalue has a name and persistent identity — an ordinary variable. An rvalue is a temporary with no persistent identity — a literal, or a function's return value. T& binds only to lvalues; T&& (a new syntax — a rvalue reference) binds only to rvalues. This distinction is exactly what lets the compiler choose between a copy and a move, at compile time, based on which kind of value is actually being used.

Move Constructors and Move Assignment

A class can define a move constructor, taking an rvalue reference. Instead of copying the source object's resources, it steals them — pointer/handle fields are copied over, then explicitly nulled out in the source, so the source's own destructor doesn't also try to free the same resource. This directly avoids c2-3's own double-free bug class, by deliberate design.

std::move — Casting an lvalue to an rvalue

The real mechanism: std::move doesn't actually move anything by itself — it's purely a cast, converting an lvalue (which would normally bind to T&, triggering a copy) into an rvalue reference (T&&), so the move constructor gets selected instead of the copy constructor. A genuinely important, often-misunderstood fact: std::move performs no action of its own at all.

After a Move, the Source Is in a "Valid But Unspecified" State

A precise, real rule: a moved-from object is guaranteed to still be safely destructible and (usually) safely reassignable — but its actual value is unspecified. Reading it for anything else is a logic bug, though not undefined behavior the way c1-7's dangling pointer would be — a genuinely important, precise distinction.

Contrasted With Rust's Own Move-By-Default Semantics

Rust performs this exact optimization automatically and by default, per rust1-3's own ownership model — passing or returning a value moves it unless the type is Copy, with no special syntax needed and no possibility of forgetting to move efficiently. C++ requires explicitly opting in via std::move, or relying on the compiler's own automatic Return Value Optimization in specific cases — another point where Rust simply enforces, by default, a discipline C++ makes available but optional.

Coding Challenges

cpp1-5 previewed exception safety briefly. This chapter delivers it in full — and closes with the honest, three-way comparison this whole course has been building toward.

C's Total Absence of Error Propagation

Worth naming directly, for the first time: C has no exceptions, no Result type, nothing beyond a manual return code or errno that the caller must remember to check, every single time, with nothing enforcing that check at all.

throw, try, catch

Stack Unwinding

When an exception is thrown, the stack unwinds: every function between the throw site and the matching catch exits, and every local object along the way has its destructor called, in reverse order of construction. This is exactly cpp1-5's own "Exception Safety, Briefly" preview, now shown in full.

RAII's Role in Exception Safety

The real payoff: because destructors run during unwinding, RAII-managed resources — smart pointers, containers, file handles wrapped in RAII types — are cleaned up automatically even when an exception is thrown mid-function, with zero additional code from the programmer. A raw resource acquired with new/malloc and manually freed at a function's end leaks if an exception is thrown before that manual free line is ever reached — a genuine, concrete argument for using RAII wrappers pervasively, not just a style preference.

Standard Exception Types

std::exception is the base type, with std::runtime_error, std::out_of_range, and others derived from it. Catch by reference (const std::exception&) to avoid slicing — a real forward pointer to cpp3-1's own object-slicing material.

Exceptions vs. Return Codes vs. Rust's Result<T, E>

Three real, genuinely different guarantees. C's manual return codes/errno: nothing enforces checking them — silently ignorable. C++ exceptions: an uncaught exception terminates the program rather than silently continuing with a wrong value — genuinely stronger than C — but which exceptions a function might throw is invisible in its own signature, a real, honest downside. Rust's Result<T, E>: the possibility of failure is part of the function's own type, and the compiler forces the caller to at least acknowledge it — via ?, .unwrap(), or a match — genuinely the strongest of the three.

Coding Challenges

cpp2-3's std::sort works with any callable — this chapter introduces the concise way real C++ code writes one inline, and reveals it's built from a mechanism already covered.

Lambda Syntax

[capture](params) { body } — a lambda passed directly as std::sort's custom comparator, exactly cpp2-3's own algorithm-plus-callable pattern.

Capture Lists

The real new concept: how a lambda accesses variables from its surrounding scope.

• [] — captures nothing
• [=] — captures everything used, by value (a copy)
• [&] — captures everything used, by reference
• [x] — captures just x, by value
• [&x] — captures just x, by reference

What a Lambda Actually Is — A Class With operator()

The real mechanism, connecting directly back to cpp1-6: a lambda is compiler-generated syntactic sugar for an anonymous class, with captured variables as member fields and an overloaded operator() containing the lambda's body. Not a new language feature at its core — cpp1-6's own mechanism, applied automatically. Capturing by value copies into those member fields at the point the lambda is created, not when it's called — a real, sometimes-surprising timing detail.

std::function

A type-erased wrapper capable of holding any callable matching a given signature — a lambda, a function pointer (c2-7's own material), or a class with operator(). Useful because every lambda genuinely has its own unique, compiler-generated type, even when two lambdas look identical in source — std::function gives them a common type to be stored or passed around as.

Contrasted With Rust's Own Closures

Rust closures work via the same underlying idea — the compiler generates a hidden struct capturing referenced variables, implementing one of the Fn/FnMut/FnOnce traits, genuinely comparable to operator(). The real difference: Rust's own capture rules are inferred automatically from how the closure body actually uses each variable (by reference, mutable reference, or move), rather than requiring an explicit capture-list syntax the way C++ does. A genuine ergonomic difference — but the underlying "anonymous callable object" mechanism is, once again, a real point of convergence, alongside RAII/Drop and monomorphization.

Coding Challenges

Course 2 built templates, containers, smart pointers, move semantics, exceptions, and lambdas. This closing chapter ties them together into the actual practice of writing idiomatic modern C++.

const-Correctness, In Full

cpp1-2 introduced const briefly; cpp1-8 covered const T& parameters. The remaining piece: a const member function promises not to modify the object, enforced by the compiler.

This is a real, propagating discipline — a const object can only call const-qualified member functions on itself.

The Rule of Three

Revisiting cpp1-5's own preview directly: if a class defines any one of a destructor, a copy constructor, or a copy assignment operator, it almost certainly needs all three. It's managing a resource manually, and the compiler's own default-generated versions of the other two would perform a shallow copy — two objects both believing they own the same resource, leading straight to c2-3's own double-free bug class.

The Rule of Five

C++11 extended it: the move constructor and move assignment operator (cpp2-5's own material) join the same rule. Writing any one of the five is a real signal you likely need to think through all five.

The Rule of Zero

The modern, actually-recommended alternative: don't manage raw resources directly at all. Use RAII wrappers — smart pointers (cpp2-4), STL containers (cpp2-2) — for every member, and let the compiler's default-generated destructor, copy, and move operations work correctly automatically, since each member's own RAII type already does the right thing on its own. A genuine, real best practice: the Rule of Five exists to be understood; the Rule of Zero exists to be practiced. Most well-written modern C++ classes need none of the five written by hand.

auto and Range-Based for Loops, Revisited

cpp1-2's auto and cpp2-3's range-based for, named together now as part of "modern C++ style" — alongside the Rule of Zero, smart pointers, and RAII, this is what a well-written modern codebase actually looks like, in sharp contrast to older, pre-C++11 "C with Classes" style still using raw new/delete and hand-written Rule-of-Three classes everywhere.

Closing Course 2

Templates → STL containers → iterators/algorithms → smart pointers → move semantics → exceptions → lambdas — now const-correctness and the Rule of Zero tie the whole course together into a genuine practice, not just a list of features. Course 3 goes deeper still: multiple inheritance, templates in more depth, the Rule of Five's full mechanics, concurrency, C++-specific undefined behavior, and a real capstone.

Coding Challenges