Course 3 goes deeper into C++'s own mechanics, starting with something neither of this course's two comparison languages support in the same form.

Multiple Inheritance

A class can inherit from more than one base class at once — something neither C's plain structs (c2-1, no inheritance concept at all) nor Rust's traits support in this exact form.

The Diamond Problem

The classic scenario: class D inherits from both B and C, and both B and C themselves inherit from a common base A. Without intervention, D ends up with two separate copies of A's data — one via each path — genuinely ambiguous which copy a reference to an inherited A member refers to, producing a real compile error unless explicitly disambiguated.

A Worked Example

virtual Inheritance — The Fix

With both paths declared virtual, Duck gets exactly one shared Animal sub-object, resolved correctly. Under the hood, a hidden pointer/offset table tracks the shared base's actual location — genuinely comparable in spirit to cpp1-7's own vtable: hidden compiler machinery solving an ambiguity problem.

Why This Is Genuinely Complex and Often Avoided

Honestly: multiple inheritance combined with virtual inheritance is widely considered one of C++'s more error-prone, rarely-actually-needed corners. Most style guides recommend avoiding multiple inheritance of implementation entirely, reserving it for multiple inheritance of pure interfaces — abstract classes containing only pure virtual functions (cpp1-7's own = 0 syntax) — which sidesteps the diamond problem entirely, since there's no actual data to duplicate.

Contrasted With Rust's Trait-Based Composition

Rust deliberately has no multiple inheritance of structs at all. A struct can implement any number of traits, and traits can have default method implementations — but a struct never inherits data from multiple sources the way a C++ class can. This sidesteps the diamond problem structurally, by design, rather than needing a virtual-inheritance fix bolted on afterward. Rust's own answer to "I need behavior from multiple sources" is composition and multiple trait implementation, not multiple inheritance of state.

Coding Challenges

cpp2-1 deferred two things: the deeply confusing pre-C++20 template error, and full template depth. This chapter delivers both.

Template Specialization

A different implementation of a template for one specific type.

A real, well-known example: std::vector<bool> has its own famous specialization, bit-packing elements instead of storing full bytes — a genuinely different implementation from every other std::vector<T>.

Partial Specialization

Specializing for a category of types rather than one exact type — a real, useful middle ground.

Variadic Templates

template<typename... Args> accepts an arbitrary number of template arguments.

This is genuinely what powers std::make_unique — used unexplained since cpp2-4 — and similar "forward any number of constructor arguments" functions throughout the STL.

The Confusing Error, Resolved — C++20 Concepts

cpp2-1's own deferred promise: concepts let a template constrain what operations T must support, directly in the template's own declaration.

This moves the error from deep inside the template's own instantiated body to a clear, readable message at the call site itself, naming exactly which requirement wasn't met — a genuine, real quality-of-life improvement.

Contrasted With Rust's Own Trait Bounds

Rust's fn sum<T: Add>(a: T, b: T) -> T has always worked this way, since Rust's very first stable release. Trait bounds constraining a generic parameter aren't a recent addition to Rust the way concepts are to C++ (added in C++20, decades after templates themselves) — another point where Rust simply had, by default and from day one, a discipline C++ has only recently, and optionally, caught up to.

Coding Challenges

cpp1-5 and cpp2-8 both previewed the Rule of Five. This chapter is the full mechanical depth — exactly which declaration suppresses which auto-generation.

The Five Special Member Functions, Named Precisely

• Destructor — ~T()
• Copy constructor — T(const T&)
• Copy assignment — T& operator=(const T&)
• Move constructor — T(T&&)
• Move assignment — T& operator=(T&&)

What the Compiler Generates by Default

If none are declared, the compiler generates all five automatically — each doing the "obvious" member-wise thing. This default is genuinely correct for classes made entirely of other well-behaved types. This is the Rule of Zero (cpp2-8), explained mechanically: it works precisely because the compiler-generated defaults are already correct when every member is itself well-behaved.

The Suppression Rules — When Declaring One Function Silently Deletes Others

The real mechanical depth. Declaring a destructor suppresses automatic generation of the move constructor and move assignment entirely — not a bad default, simply not generated at all. Declaring any of copy constructor, copy assignment, move constructor, or move assignment suppresses both move operations from being auto-generated.

A Real Table — What Suppresses What

= default and = delete

Modern C++11 syntax to be explicit about intent, rather than relying on implicit suppression rules.

cpp2-4's own unique_ptr uses exactly = delete internally on its own copy constructor — not magic, simply this syntax.

Rust's Approach Contrasted

Rust has no equivalent implicit-generation-with-suppression-rules system at all. Copy/Clone must be explicitly derived or implemented — #[derive(Clone, Copy)] — and move is simply the default for every type unless it opts into Copy. No five-function dance, no suppression table to memorize. A genuinely simpler, more explicit design, deliberately trading C++'s flexibility for predictability.

Coding Challenges

c3-3 built a race condition with raw pthreads. This chapter shows modern C++'s own equivalents — genuinely nicer to use, but not a different safety story.

std::thread

A higher-level replacement for pthread_create/pthread_join — but with a real, important gotcha: a std::thread still joinable when its destructor runs calls std::terminate. It does not automatically join or detach the way an RAII-styled course might suggest; .join() or .detach() must be called explicitly before destruction.

A Worked Example — Revisiting c3-3's Race Condition

The exact same race — the higher-level wrapper changes nothing about the underlying problem, only the syntax used to create the threads.

std::mutex and std::lock_guard

std::mutex is the same concept as c3-3's own pthread_mutex_t. std::lock_guard<std::mutex> is a genuine RAII wrapper around locking — the direct fix to c3-3's own "forgotten unlock deadlocks" warning. Its destructor unlocks automatically, on any exit path, including an exception — exactly cpp2-6's own exception-safety mechanism, applied specifically to locking.

std::atomic

A genuinely different, lower-overhead alternative for simple shared counters and flags specifically.

Resolves c3-3's own race condition with no lock/unlock pairing whatsoever — a real, meaningful alternative worth knowing for exactly this narrow case.

Contrasted With Rust's Send and Sync, Revisited

std::mutex/std::lock_guard are a genuine ergonomic improvement over c3-3's raw pthread_mutex_t — automatic unlocking via RAII, no more forgotten-unlock deadlocks. But the same fundamental gap from c3-3 remains: nothing in C++'s type system ties a std::mutex to the specific data it protects, and nothing prevents accessing that data without holding the lock at all. Rust's Mutex<T> — wrapping the data itself, checked by the Send/Sync marker traits at compile time — is still the genuinely stronger guarantee. lock_guard is a real ergonomic win, not a safety win at the type-system level.

Coding Challenges

This chapter doesn't re-derive c3-4's own UB deep dive — everything there still applies, unchanged. This is only what's genuinely new to C++ specifically.

Everything From c3-4 Still Applies

Signed overflow, out-of-bounds access, dangling pointers, use-after-free, double-free, strict aliasing, excessive shifts, data races — every category c3-4 catalogued applies unchanged, since C++ inherits C's entire UB model at the language-core level.

Object Slicing

A genuinely new-to-C++ trap: assigning a derived-class object to a base-class object by value — not through a pointer or reference — "slices off" the derived part entirely, leaving only the base portion. Not technically undefined behavior in the strict sense (copying just the base part is well-defined), but almost always a serious logic bug, since cpp1-7's own virtual dispatch is lost entirely.

This is exactly what cpp2-6's own "catch by reference to avoid slicing" tip was pointing toward — now fully explained.

Pure Virtual Function Called From a Constructor

A genuinely real, subtle trap: calling a virtual function from a base class's own constructor does not dispatch to a derived override, even if the object being constructed is ultimately a derived type. Calling a pure virtual function this way is genuinely undefined behavior, not merely surprising.

Why Construction Order Causes This

During a base class's own constructor, the object's hidden vtable pointer is set to point at the base class's vtable — not the derived one. It's updated to point at successively more-derived vtables as each level of construction completes, finishing only once the most-derived constructor runs. Calling a virtual function mid-construction sees whatever vtable is currently set, never the final one.

Uninitialized Member Variables

C++ class members of built-in types (int, pointers, etc.) are not automatically zero-initialized unless explicitly done so in the constructor — a real, common gotcha, especially coming from a language with different defaults. Rust simply doesn't allow reading an uninitialized variable at all — a compile error, closing this exact class of bug structurally.

Coding Challenges

Twenty-two chapters, one piece at a time. This closing chapter builds a small shape inventory — polymorphic shapes, RAII, templates, smart pointers, exceptions, and STL algorithms combined into one working, modern C++ program.

The Project — A Shape Inventory

The Shape Hierarchy

cpp1-4/cpp1-5/cpp1-7: a Shape base class with virtual area() and name(), derived classes validating their own input in the constructor and throwing on invalid data (cpp2-6).

Exception Safety in the Constructors

Circle(-5.0) throws before construction ever completes — a real, direct application of cpp2-6's own constructor-exception material. No RAII resource is ever left half-acquired.

A Generic Repository<T> Template

cpp2-1's own templates, applied for real — a small, genuinely reusable class template, not shape-specific at all.

Ownership via unique_ptr — No Slicing, Ever

Shapes are never stored or passed by value — only via unique_ptr<Shape>, deliberately avoiding cpp3-5's own object-slicing trap by construction. add() takes ownership via std::move, exactly cpp2-4's and cpp2-5's own material applied together.

Sorting With a Lambda

cpp2-3's std::sort plus cpp2-7's own lambda syntax, comparing shapes by area through their owning unique_ptrs.

const-Correctness Throughout

cpp2-8's own discipline, applied everywhere: area()/name() are const; Repository's own size()/operator[] are const-correct too — nothing in this project mutates state it doesn't need to.

Where Each Piece Came From

What's Still Out of Scope, Honestly

No multiple inheritance was needed — cpp3-1's own material simply wasn't necessary here, a single hierarchy sufficed, itself a realistic outcome. No concurrency (cpp3-4) — this is a single-threaded tool. No hand-written Rule of Five anywhere — the entire project follows the Rule of Zero throughout, a deliberate demonstration that modern C++ rarely needs it. C++20 concepts (cpp3-2) weren't used either, kept to plain templates for broader compiler compatibility.

Closing the Course & Track

From cpp1-1's compile model to a real, polymorphic, exception-safe, template-based, RAII-everywhere program — every chapter added one piece of real capability C never had, while this course's own repeated Rust comparisons kept one honest question in view: what does the language enforce, versus what does it merely make possible? The genuine convergence points along the way — RAII/Drop, monomorphization, unique_ptr/Box, shared_ptr/Rc, lambdas/closures — show two languages solving similar problems from different starting philosophies. That comparison, sustained across 44 chapters spanning both tracks, is the actual lesson.

Coding Challenges