Modern C++

#include <memory>

void useIt() {
    std::unique_ptr<int> ptr = std::make_unique<int>(42);
    std::cout << *ptr;   // dereferences just like a raw pointer (Phase 4)
}   // automatically deleted here — no manual delete needed, ever

std::make_unique<int>(42) creates the memory AND wraps it in a unique_ptr in one step — the recommended way to create one. You use it almost exactly like a raw pointer (*ptr still dereferences it, per Phase 4 Module 2), but you never call delete yourself — the wrapper's destructor does it for you automatically, applying last module's RAII directly.

std::unique_ptr<int> a = std::make_unique<int>(42);
std::unique_ptr<int> b = a;   // COMPILER ERROR — unique_ptr can't be copied

A unique_ptr genuinely enforces single ownership — the compiler refuses to let two unique_ptrs point to the same memory, preventing exactly the kind of accidental double-delete or confusion that raw pointers made easy to cause by mistake.

std::unique_ptr<int> a = std::make_unique<int>(42);
std::unique_ptr<int> b = std::move(a);   // ownership transfers to b; a is now empty

std::move lets ownership genuinely TRANSFER from one unique_ptr to another — a becomes empty (safely, not dangling), and b now owns the memory. Module 6 covers exactly what std::move is really doing.

std::shared_ptr<int> a = std::make_shared<int>(42);
std::shared_ptr<int> b = a;   // legal! both a and b now share ownership

std::cout << a.use_count();   // prints 2 — two owners currently exist

Unlike Module 2's unique_ptr, a shared_ptr CAN be copied — internally, it keeps a running count of how many shared_ptrs currently point to the same memory. The underlying memory is only actually deleted once that count reaches zero — meaning every single owner has gone out of scope or been reset.

Imagine object A holds a shared_ptr to object B, and object B holds a shared_ptr right back to object A. Each one keeps the other's reference count above zero — FOREVER — even if nothing else in the program references either of them anymore. Neither ever actually gets deleted. This is called a reference cycle, and it's a genuine, real-world memory leak that shared_ptr alone cannot solve.

std::shared_ptr<int> shared = std::make_shared<int>(42);
std::weak_ptr<int> weak = shared;   // observes, but does NOT count as an owner

std::cout << shared.use_count();   // still 1 — weak_ptr didn't increase it

A weak_ptr can observe a shared_ptr's data without counting toward Module 3's reference count at all — breaking the cycle, since neither object's count is artificially kept alive by the other anymore.

if (auto locked = weak.lock()) {   // returns a real shared_ptr, or empty if already deleted
    std::cout << *locked;
} else {
    std::cout << "The data no longer exists.";
}

Since a weak_ptr doesn't keep its data alive, the data it points to might already be gone by the time you try to use it. .lock() safely checks: it returns a real, usable shared_ptr if the data still exists, or an empty one if it's already been deleted — directly connecting back to Phase 4 Module 9's null-checking discipline, applied here to a modern C++ tool.

Imagine a class holding a huge amount of data (like a large std::vector). Before move semantics, returning such an object from a function, or assigning it to a new variable, meant fully COPYING all that data — genuinely wasteful when the original object was about to be discarded anyway.

std::vector<int> original = {1, 2, 3, 4, 5};
std::vector<int> moved = std::move(original);
// moved now owns the data. original is left in a valid but empty state.
// No copying of the actual 1,2,3,4,5 data occurred — just a transfer of ownership.

Moving transfers ownership of an object's internal resources directly, instead of duplicating them — genuinely similar in spirit to Module 2's unique_ptr ownership transfer, just applied to any type that supports it, not only smart pointers.

int& lref = someVariable;       // Phase 3's regular (lvalue) reference — refers to an existing, named variable
int&& rref = 42;              // an rvalue reference — refers to a temporary value

&& marks an rvalue reference — a reference specifically to a temporary value (something without a lasting name, like a literal or a function's return value) that's about to be discarded anyway. This is exactly the signal that lets a type's move constructor know "it's safe to steal this data — nothing else needs it."

MyClass(MyClass&& other) {
    data = other.data;      // steal the pointer/resource directly
    other.data = nullptr;  // leave the source safely empty (Module 5's "valid but unspecified")
}

A class's move constructor takes an rvalue reference and transfers ownership directly — this is the actual mechanism behind everything Module 5 described conceptually. You won't often need to write these by hand as a beginner (many classes get one generated automatically), but recognizing this pattern demystifies what std::move genuinely triggers.

int score = 85;               // explicit type
auto score2 = 85;             // auto — compiler infers "int" from the value 85

std::map<std::string, int>::iterator it = myMap.begin();   // long, genuinely tedious
auto it2 = myMap.begin();   // identical result, far more readable

auto tells the compiler "figure out this variable's type from what I'm assigning to it." It doesn't make C++ dynamically typed — the type is still fixed and checked at compile time, exactly like always; auto is purely a convenience for not TYPING it out yourself, especially for genuinely long, awkward types like Phase 7's iterators.

• Long, awkward type names — like Phase 7's iterator types, or complex template types you'll meet in Phase 9.
• Lambda types (Phase 7 Module 8) — a lambda's actual type is something you genuinely cannot write out by hand at all.
• When the type is already completely obvious from the right-hand side, like auto name = std::string("Alex");

std::pair<std::string, int> person = {"Alex", 25};

// The old way (Phase 7 Module 9):
std::string name = person.first;
int age = person.second;

// Structured bindings — one line, same result:
auto [name2, age2] = person;
std::cout << name2 << " is " << age2;

auto [name2, age2] = person; unpacks person's .first and .second directly into two clearly, individually named variables — genuinely more readable than repeated .first/.second access, especially in code that uses the values multiple times.

// Phase 7 Module 8's style:
for (const auto& entry : ages) {
    std::cout << entry.first << ": " << entry.second << std::endl;
}

// With structured bindings — genuinely clearer:
for (const auto& [name, age] : ages) {
    std::cout << name << ": " << age << std::endl;
}

This directly improves on Phase 7 Module 8's map-iteration pattern — name and age read far more clearly than entry.first and entry.second, especially once the loop body gets longer than one line.

Manage a small collection of dynamically-created objects using std::vector<std::unique_ptr<T>> — genuinely no raw new/delete pairs to manually track anywhere in the code.

• std::vector<std::unique_ptr<Task>> combines Phase 7's vector with this phase's unique_ptr — a genuinely common, idiomatic modern C++ pattern for managing a dynamic collection of owned objects.
• std::make_unique (Module 2) creates each Task — no bare new anywhere in this program.
• When tasks itself goes out of scope at the end of main(), EVERY unique_ptr inside it is destroyed, which in turn destroys every Task — a complete, automatic cleanup chain, applying Module 1's RAII at every level.
• Compare this directly to Phase 4's capstone: zero manual delete calls, zero risk of a forgotten one causing a leak.