Sources and References

Stroustrup, Bjarne — A Tour of C++, 3rd ed. (2022). Addison-Wesley. Primary narrative source for C++20 features.

Meyers, Scott — Effective Modern C++ (2014). O’Reilly. Canonical reference for C++11/14 idioms; items cited by number.

Williams, Anthony — C++ Concurrency in Action, 2nd ed. (2019). Manning. Primary source for Subpart C (Concurrency).

Sutter, Herb — Exceptional C++ and More Exceptional C++ (1999, 2001). Addison-Wesley. Advanced idioms: pimpl, type erasure, SFINAE.

Josuttis, Nicolai — The C++ Standard Library, 2nd ed. (2012). Addison-Wesley. Standard library deep-dives.

Alexandrescu, Andrei — Modern C++ Design (2001). Addison-Wesley. Policy-based design (Chapter 59).

cppreference.com — Online reference; all API signatures and constraints verified here.

Problem 35: I Want a Maybe Value

Back in Problem 9 we confronted the same question that haunts every API designer: what should a function return when it has no meaningful answer? We ruled out sentinel integers — there is no magic int that universally means “absent” — and settled on exceptions as the right tool. But exceptions carry a cost and a connotation: they signal something went wrong. Sometimes, though, a missing value is perfectly normal. A configuration file may or may not define a timeout. A map lookup may or may not find a key. A command-line parser may or may not see a particular flag. None of these is an error; each is just a value that might not be there.

We need a type that honestly says so.

The Problem with Sentinels

Suppose we write a function that parses an integer from a string:

int parse_int(const std::string &s) {
    // ...
}

What should parse_int("abc") return? Returning -1 fails immediately: -1 is a valid integer. Returning std::numeric_limits<int>::min() fails for the same reason. There is no integer value we can reserve as an “absence” marker.

The pair approach. We can widen the return type:

std::pair<bool, int> parse_int(const std::string &s) {
    try {
        return {true, std::stoi(s)};
    } catch (...) {
        return {false, 0};
    }
}

The caller must check the bool before using the int:

auto [ok, val] = parse_int("42");
if (ok) std::cout << val;

This works, but nothing in the type system forces the caller to check ok before reading val. If they forget, they silently use a garbage 0. The types lie: the int in the pair appears to always exist, even when it does not.

std::optional: The Type-Safe Maybe

C++17 introduces std::optional<T>, a type that either holds a value of type T or holds nothing. “Nothing” is spelled std::nullopt and has its own distinct type, std::nullopt_t, so it can never be confused with a real T.

#include <optional>

std::optional<int> parse_int(const std::string &s) {
    try {
        return std::stoi(s);   // wraps int in optional automatically
    } catch (...) {
        return std::nullopt;   // explicitly empty
    }
}

The caller now cannot accidentally use the value without checking:

auto result = parse_int("42");
if (result) {               // operator bool: true iff has value
    std::cout << *result;   // dereference to get the int
}
int val = result.value_or(0);  // 0 if absent

Constructing and Accessing an optional

std::optional<int> empty;           // default: no value
std::optional<int> opt{42};         // has value 42
auto opt2 = std::make_optional(42); // same; factory deduces T

opt = 7;               // reassign to new value
opt = std::nullopt;    // clear it
opt.reset();           // same as above

The four ways to retrieve the value:

std::optional<int> opt{42};

opt.has_value();    // true; equivalent to bool(opt)

*opt;               // 42; like dereferencing a pointer -- UB if empty
opt.value();        // 42; throws std::bad_optional_access if empty
opt.value_or(-1);   // 42; returns -1 (the default) if empty
opt->some_method(); // arrow operator, like a pointer; UB if empty

Note. operator* and operator-> follow pointer semantics: they give direct access but do not check. They are the right choice inside an if (opt) guard. Outside such a guard, prefer value() so an accidental empty dereference throws an exception rather than producing undefined behaviour.

Worked Example: A Configuration Reader

using Config = std::unordered_map<std::string, std::string>;

std::optional<int> get_int(const Config &cfg, const std::string &key) {
    auto it = cfg.find(key);
    if (it == cfg.end()) return std::nullopt;  // key absent
    return parse_int(it->second);              // may also be nullopt
}

The caller chains the two checks naturally:

Config cfg = {{"timeout", "5"}, {"retries", "bad"}};

if (auto t = get_int(cfg, "timeout")) {
    set_timeout(*t);
}
if (auto r = get_int(cfg, "retries")) {
    set_retries(*r);    // "bad" fails parse_int; this branch not taken
}

The optional propagates absence: get_int is absent either because the key is missing or because the value is not a valid integer, and the caller handles both cases with one if check.

Aside (CS 146 connection: Haskell’s Maybe and Racket’s false). In CS 146 you met Maybe in Haskell: Maybe Int is either Nothing or Just 42. std::optional is exactly the same algebraic type dressed in C++ syntax. The analogy extends to the accessor names: Haskell’s fromMaybe defaultVal maybeVal is opt.value_or(defaultVal). In Racket, the idiom is to return #f for “absent” and a value otherwise — a dynamically typed convention that the type system cannot enforce. optional makes the same contract statically checkable: the type std::optional<int> cannot be implicitly used as an int, so forgetting the check is a compile error, not a runtime surprise.

Monadic Operations (C++23)

C++23 adds three methods that let you chain optional-producing operations without explicit if checks. They mirror the >>= combinator from Haskell’s Maybe monad.

// C++23
auto timeout_ms =
    get_int(cfg, "timeout")
    .transform([](int secs) { return secs * 1000; })  // scale if present
    .value_or(5000);                                   // default 5 s

Each step is evaluated only if the previous step produced a value. The distinction between and_then and transform mirrors flatMap vs map in functional programming: transform applies a function that returns a plain value; and_then applies a function that itself returns an optional, for use when that sub-step can also fail.

When Not to Use optional

std::optional<T> stores its value inline — there is no heap allocation. The size is roughly sizeof(T) + 1 (plus alignment padding). This makes it cheap for small types like int or double.

Two situations where optional is the wrong tool:

1. Large types. std::optional<HugeMatrix> reserves the full HugeMatrix storage on the stack even when the optional is empty. Consider std::unique_ptr<HugeMatrix> instead — a null pointer costs only sizeof(void*).

2. Signalling genuine errors. If a function can fail for a reason the caller should act on — a network timeout, a permissions violation, a malformed file — the absence of a value should carry why it is absent. C++23’s std::expected<T, E> (Chapter 37) does exactly that: it holds either a value of type T or an error of type E. optional carries only the absence; expected carries a diagnosis.

Note. Prefer std::optional over nullable raw pointers for “maybe a value” semantics in value types. A T* that means “optionally a T” has a second meaning: “a T owned elsewhere”. Those two ideas are better kept separate. Use optional<T> when you own the potential value; use raw or smart pointers when the ownership question is the point.

Problem 36: Sum Types Without Inheritance

Problem 18 gave us heterogeneous data through inheritance. Store a vector<unique_ptr<Book>>, use virtual dispatch, and each element behaves as its true type at runtime. It works. But it costs: every object carries a hidden vptr, every element lives on the heap, every call to a virtual method goes through an indirection. Worse, to add a new operation over the hierarchy you must touch every class — or reach for dynamic_cast (Problem 22).

Sometimes the set of alternatives is closed and known at compile time. We do not want a vtable. We do not want heap allocation. We want value semantics and exhaustive case analysis that the compiler can enforce.

C’s Approach: Tagged Union

C programmers have always had heterogeneous data. The idiom is a struct that pairs an enum tag with a union of the possible payloads:

enum MediaKind { SONG, PODCAST, AUDIOBOOK };

struct Media {
    MediaKind kind;
    union {
        Song      song;
        Podcast   podcast;
        Audiobook book;
    };
};

Media m;
m.kind = SONG;
m.song = makeSong(/*...*/);

// Later:
switch (m.kind) {
    case SONG:      playSong(m.song);       break;
    case PODCAST:   playPodcast(m.podcast); break;
    case AUDIOBOOK: playBook(m.book);       break;
}

The problems are familiar. Nothing stops you from writing m.podcast when m.kind == SONG: the union does not track which member is active. If you add a new MediaKind to the enum, every switch in the codebase silently becomes incomplete. And the union cannot hold types with non-trivial constructors or destructors without heroic manual management.

std::variant: The Type-Safe Tagged Union

C++17 introduces std::variant<T1, T2, ...>, which holds exactly one value from the listed alternatives at a time. The tag is implicit and always consistent. The alternatives may have constructors and destructors; the variant manages their lifetimes automatically.

#include <variant>

using BookVar = std::variant<Text, Comic, Book>;

BookVar v = Comic{"Watchmen", "Moore", 400, "Rorschach"};

The variant stores the value inline — no heap allocation. Its size is approximately max(sizeof(T1), sizeof(T2), ...) plus the tag.

Inspecting a variant

Which alternative is active?

v.index();                          // 1 -- Comic is the second alternative
std::holds_alternative<Comic>(v);   // true
std::holds_alternative<Book>(v);    // false

Extracting the value.

// By type -- throws std::bad_variant_access if wrong alternative active:
Comic &c = std::get<Comic>(v);

// By index -- same behaviour:
Comic &c2 = std::get<1>(v);

// Non-throwing: returns nullptr if wrong alternative:
Comic *cp = std::get_if<Comic>(&v);   // takes a pointer to the variant
if (cp) { /* safe to use cp */ }

Note. std::get<T> and std::get_if<T> are free function templates, not member functions. The template argument is the type (or zero-based index) you want to extract.

std::visit: Exhaustive Case Analysis

Calling std::get<T> by hand is error-prone for the same reason the C switch was: you must remember to handle every alternative. The right tool is std::visit, which calls a visitor — any callable — with the currently active value.

std::visit([](auto &val) {
    std::cout << val.getTitle() << "\n";
}, v);

The generic lambda receives the active alternative as its argument. If all alternatives share a common interface, a single generic lambda is all you need.

The Overload Trick

When alternatives require different handling, define a visitor with one overload per type. C++ has no built-in “overloaded lambda” syntax, but a small helper makes it easy:

// Define once, reuse everywhere:
template<typename... Ts>
struct overloaded : Ts... { using Ts::operator()...; };

// C++17 deduction guide (lets you write overloaded{f, g} without <...>):
template<typename... Ts> overloaded(Ts...) -> overloaded<Ts...>;

std::visit(overloaded{
    [](const Text  &t) { std::cout << "Text: "  << t.getTopic() << "\n"; },
    [](const Comic &c) { std::cout << "Comic: " << c.getHero()  << "\n"; },
    [](const Book  &b) { std::cout << "Book\n"; }
}, v);

If you forget to handle one of the alternatives, the code will not compile. The compiler enforces exhaustiveness — exactly what the C switch could not do.

Aside (CS 146 connection: algebraic data types and pattern matching). In CS 146 you saw Haskell’s algebraic data types:

data Shape = Circle Double | Rect Double Double

area :: Shape -> Double
area (Circle r) = pi * r * r
area (Rect w h) = w * h

Shape is exactly a sum type: a value is either a Circle carrying a radius or a Rect carrying a width and height. Pattern matching is exhaustive by construction; the compiler warns if you miss a case.

std::variant is C++’s version of the same idea. std::visit corresponds to pattern matching. The overloaded helper corresponds to a function with multiple equations, one per constructor. Haskell’s Either a b (either Left a or Right b) maps to std::variant<A, B>.

Worked Example: A JSON Value

JSON has exactly six value types: null, boolean, number, string, array, and object. That is a closed, compile-time-known set — a perfect fit for variant.

#include <variant>
#include <string>
#include <vector>
#include <map>
#include <memory>

struct JsonNull {};

struct JsonValue;  // forward declaration needed for the recursive types

using JsonArray  = std::vector<std::shared_ptr<JsonValue>>;
using JsonObject = std::map<std::string, std::shared_ptr<JsonValue>>;

struct JsonValue {
    std::variant<JsonNull, bool, double,
                 std::string, JsonArray, JsonObject> data;
};

A pretty-printer becomes a single std::visit:

void print(const JsonValue &jv) {
    std::visit(overloaded{
        [](JsonNull)             { std::cout << "null"; },
        [](bool b)               { std::cout << (b ? "true" : "false"); },
        [](double d)             { std::cout << d; },
        [](const std::string &s) { std::cout << '"' << s << '"'; },
        [](const JsonArray &arr) {
            std::cout << "[";
            for (auto &el : arr) { print(*el); std::cout << ","; }
            std::cout << "]";
        },
        [](const JsonObject &obj) {
            std::cout << "{";
            for (auto &[k, v] : obj) {
                std::cout << '"' << k << "\":";
                print(*v);
                std::cout << ",";
            }
            std::cout << "}";
        }
    }, jv.data);
}

Adding a new operation (a JSON serialiser, a validator) means writing one more std::visit call — no touching the JsonValue struct. Adding a new alternative (say, a special JsonInt) means updating the variant alias and recompiling; the compiler will flag every visit that does not handle the new case.

Note. Variant vs. inheritance: a decision guide. Use std::variant when the set of alternatives is closed (you control it and it does not grow at runtime), when you want value semantics (stack allocation, copyable, no heap), or when you need exhaustive case analysis enforced at compile time. Use inheritance and virtual dispatch when the set of types is open (third-party code may add new subclasses), when objects have independent lifetimes managed through pointers, or when the polymorphic interface is the stable part and new operations are rare. The two tools are complementary, not competing.

Problem 37: Errors Without Exceptions

Problem 35’s std::optional<T> tells the caller that a value might not be there. That is enough when absence is normal: a config key is missing, a map lookup finds nothing. But sometimes the caller needs to know why the value is absent. A network request failed — was it a timeout, a permissions error, or a malformed URL? We have been throwing exceptions for this, but exceptions have costs and connotations.

Back in Problem 9 we reached for exceptions as the right tool for “something went wrong.” Problem 15 reminded us of the exception-safety obligations that entails. But exceptions interrupt normal control flow, carry overhead from stack-unwinding infrastructure, and in some environments (embedded systems, certain real-time kernels) they are disabled entirely.

The C Approach: Error Codes

C programmers handle fallible operations with return codes:

// Returns 0 on success, errno value on failure.
int read_file(const char *path, char *buf, size_t *n);

// Caller:
char buf[4096]; size_t n;
int err = read_file("data.txt", buf, &n);
if (err != 0) {
    fprintf(stderr, "error: %s\n", strerror(err));
    return err;
}

The problems are well known. The return value is overloaded: it carries both the success result and the error code, but not at the same time. Nothing in the type system forces the caller to check for an error before using the result. Errno is a global, so it is not thread-safe. And the successful value must be returned through an output parameter, which inverts the natural reading order.

std::expected: The Type-Safe Result

C++23 introduces std::expected<T, E> (paper P0323). A value of this type holds either a T (the expected, successful result) or an E (the unexpected error). The type is explicit; the caller cannot use a T without first checking whether the result is an error.

#include <expected>   // C++23
#include <system_error>
#include <string>
#include <fstream>

std::expected<std::string, std::error_code>
read_file(const std::string &path) {
    std::ifstream f{path};
    if (!f) return std::unexpected{
        std::make_error_code(std::errc::no_such_file_or_directory)};
    return std::string{std::istreambuf_iterator<char>{f}, {}};
}

Notice that returning a T directly constructs the success case. Returning std::unexpected{err} constructs the error case. std::unexpected is a thin wrapper that distinguishes an error value from a success value when they might otherwise have the same type.

Constructing and Accessing

// Constructing:
std::expected<int, std::string> ok  = 42;
std::expected<int, std::string> err = std::unexpected{"oops"};

// Checking:
ok.has_value();   // true
bool(ok);         // same -- operator bool

// Extracting the value (UB or throw if in error state):
int v  = *ok;             // like optional: UB if error
int v2 = ok.value();      // throws std::bad_expected_access if error
int v3 = ok.value_or(0);  // returns 0 if error

// Extracting the error:
std::string e = err.error();  // UB if in value state

Look familiar? The interface is deliberately parallel to std::optional: has_value, operator bool, value, value_or, operator*. Once you know optional you already know most of expected.

Note. std::bad_expected_access<E> is the exception thrown by value() when the expected holds an error. It carries the error value so the handler can inspect it.

Monadic Operations

Like std::optional (Problem 35), C++23’s expected supports and_then, transform, and or_else for chaining fallible operations without explicit if checks.

Worked Example: A File-Reading Pipeline

Suppose we want to read a configuration file, extract a particular line, and parse an integer from it. Any step can fail.

using Result = std::expected<std::string, std::error_code>;

Result read_line(const std::string &path, int n);
std::expected<int, std::error_code> parse_int(const std::string &s);

// Chain them without a single explicit if:
auto timeout =
    read_line("config.txt", 3)
    .and_then(parse_int)
    .transform([](int secs) { return secs * 1000; })
    .value_or(5000);   // default if any step failed

Each step runs only if the previous step succeeded. If read_line fails, the and_then and transform are skipped and the error propagates unchanged to value_or, which supplies the fallback.

Aside (CS 245 connection: preconditions, postconditions, and partial functions). In CS 245 you wrote Hoare triples: {P} cmd {Q}, asserting that if precondition P holds before statement S executes, postcondition Q holds afterwards.

A function that can fail is a partial function: it has a postcondition but only under certain preconditions. The traditional C approach — set a global error flag, return a sentinel — is equivalent to saying the function always terminates with Q, but Q includes a hidden “or the error flag was set” disjunct that callers routinely ignore.

std::expected<T, E> makes the disjunction explicit in the type. The postcondition is: either the return value is a T satisfying the happy-path postcondition, or the return value is an E describing why the preconditions could not be met. Hoare logic has a name for this: a total correctness specification with a distinguished failure mode.

When to Use expected vs. Exceptions vs. optional

• Use std::optional<T> when absence is normal and uninformative: a map lookup, an optional config value. There is nothing to explain.

• Use std::expected<T, E> when failure is part of normal control flow but the caller needs to know why: parsing user input, I/O that routinely encounters missing files or permission errors, library APIs that must work without exceptions enabled.

• Use exceptions for truly exceptional conditions: programming errors, resource exhaustion, situations the caller cannot reasonably recover from locally. Exceptions propagate automatically; expected must be explicitly threaded through every call site.

Note. std::expected is a C++23 feature. At the time of writing, GCC 12+, Clang 16+, and MSVC 19.36+ provide implementations under <expected>. The design is based on proposal P0323 by Vicente Botet and JF Bastien, which drew heavily on boost::outcome and Rust’s Result<T, E>. Rust programmers will find the monadic API immediately familiar.

Choosing the Error Type

The error type E in std::expected<T, E> is up to you. There are several common choices:

• std::error_code — the standard type from <system_error>, carrying an integer code plus a category (std::system_category(), std::generic_category(), etc.). Good for I/O and OS errors. Composable across library boundaries because categories are extensible.

• A plain enum class — simple, fast, zero overhead. The right choice when the set of failure modes is small and fixed.

  enum class ParseError { empty_input, invalid_char, overflow };

  std::expected<int, ParseError> parse_int(std::string_view s);

• std::string — carries a human-readable message. Convenient but expensive (heap allocation). Prefer error_code plus a message function for library code.

• A std::variant of error types — when a function can fail in structurally different ways that the caller will handle differently. This combines the ideas from Problem 36 and this one.

With exceptions you get automatic propagation: an uncaught exception unwinds the stack until a handler is found. With expected you propagate manually. The idiom is to check and re-wrap:

using Err = std::error_code;

std::expected<Config, Err> load_config(const std::string &path) {
    auto text = read_file(path);        // returns expected<string, Err>
    if (!text) return std::unexpected{text.error()};  // propagate

    auto cfg = parse_config(*text);     // returns expected<Config, Err>
    if (!cfg) return std::unexpected{cfg.error()};    // propagate

    return *cfg;
}

The manual check is more verbose than exceptions, but it is also more explicit: every call site where a failure can originate is visible in the code. The monadic and_then from the previous section eliminates the boilerplate when errors pass through unchanged.

Problem 38: Compile-Time If

Back in Problem 24 we dispatched at compile time by overloading on iterator category tags. The technique works: the compiler sees the tag type, selects the right overload, and the wrong branch is never instantiated. But it is verbose. Every compile-time branch requires a separately named helper function and an explicit traits query. Read the code a month later and the intent is buried under machinery.

There is a simpler way.

The Old Way: Tag Dispatch and SFINAE

Recall the advance example from Problem 24. We wrote three overloads of doAdvance, one for each iterator category, and dispatched by constructing a tag object:

template<typename Iter>
Iter advance(Iter it, ptrdiff_t n) {
    return doAdvance(it, n,
        typename iterator_traits<Iter>::iterator_category{});
}

Alternatively, we might have tried SFINAE — Substitution Failure Is Not An Error — where we write enable conditions on template parameters to selectively disable overloads. That is even harder to read.

Both approaches share a flaw: they scatter the logic for one operation across multiple function templates. What we really want is to write the alternatives side-by-side, in one function body.

if constexpr

C++17 introduces if constexpr, which evaluates its condition at compile time. The discarded branch is not instantiated. It just needs to parse.

#include <type_traits>

template<typename T>
void serialize(const T &val) {
    if constexpr (std::is_integral_v<T>) {
        std::cout << "(int) " << val;
    } else if constexpr (std::is_floating_point_v<T>) {
        std::cout << "(float) " << val;
    } else {
        std::cout << "(other) " << val.toString();
    }
}

When T is int, the compiler instantiates only the first branch. The val.toString() in the third branch is never compiled — so it does not matter whether int has a toString member.

When T is std::string, the compiler instantiates only the third branch. std::is_integral_v<std::string> is false, so the first branch is discarded.

Note. The discarded branch must still be syntactically valid C++. The compiler parses it and checks basic syntax. What it does not do is instantiate the branch or check that its names are valid for the concrete type T. The rule: the discarded branch must parse, but need not type-check for the given T.

The Critical Constraint: Must Depend on a Template Parameter

if constexpr is only meaningful inside a template. The condition must depend on a template parameter; otherwise the compiler could simply evaluate it and warn about unreachable code.

// This is fine -- condition depends on T:
template<typename T>
void f(T x) {
    if constexpr (sizeof(T) > 4) { /* large type path */ }
    else                          { /* small type path */ }
}

// This is NOT if constexpr's job -- condition is a runtime value:
void g(bool flag) {
    if constexpr (flag) { }  // error: flag is not a constant expression
}

Comparison with #ifdef

#ifdef also selects code at compile time, but it is a preprocessor tool: it knows nothing about types, templates, or scopes.

// #ifdef: coarse, textual, not type-aware
#ifdef PLATFORM_64
    using size_type = uint64_t;
#else
    using size_type = uint32_t;
#endif

// if constexpr: fine-grained, inside templates, type-aware
template<typename T>
auto make_buffer() {
    if constexpr (sizeof(T) <= 8) {
        return SmallBuffer<T>{};
    } else {
        return LargeBuffer<T>{};
    }
}

if constexpr respects scoping, participates in type-checking of the taken branch, and interacts correctly with auto return type deduction. #ifdef does none of these things.

Aside (CS 146 connection: conditional at the type level). In a typed functional language like Haskell or ML, type-directed dispatch happens through type classes (Haskell) or modules (ML): different instances of a class provide different behaviour for different types. The selection happens at compile time, not runtime.

In Racket, cond and match are ordinary runtime conditionals — Racket is dynamically typed so there is no compile-time type to inspect.

if constexpr occupies the middle ground: it is a runtime if in syntax and scoping, but its condition is evaluated at compile time using the type system. It is as close as C++ gets to Haskell-style compile-time pattern matching on type properties.

Worked Example: to_string

Suppose we want a generic to_string that handles arithmetic types with std::to_string and everything else by calling a member str() method:

#include <string>
#include <type_traits>

template<typename T>
std::string to_string(const T &val) {
    if constexpr (std::is_arithmetic_v<T>) {
        return std::to_string(val);  // works for int, float, etc.
    } else {
        return val.str();            // user-defined types supply str()
    }
}

Without if constexpr we would need two overloads separated by enable_if conditions — messy boilerplate just to say “pick one of two implementations based on a type property.”

if constexpr also replaces base-case specialisations in recursive templates. A classic example: printing a parameter pack.

template<typename Head, typename... Tail>
void print_all(Head h, Tail... tail) {
    std::cout << h;
    if constexpr (sizeof...(tail) > 0) {
        std::cout << ", ";
        print_all(tail...);
    }
    // No separate base-case specialisation needed.
}

When the pack is empty, sizeof...(tail) == 0 and the recursive call is in the discarded branch, so it is never instantiated. Previously you would need a separate print_all() overload for zero arguments.

A Note on consteval and constexpr Functions

if constexpr selects branches at compile time. A related but distinct feature is constexpr functions: functions that may be evaluated at compile time (when their arguments are compile-time constants) and at runtime otherwise. C++20 adds consteval for functions that must be evaluated at compile time.

The relationship:

• constexpr function: compile-time if possible, runtime otherwise.
• consteval function: compile-time only; calling it with a runtime argument is an error.
• if constexpr: selects a branch at compile time inside a template.

They are complementary. A constexpr function can contain an if constexpr; an if constexpr condition often calls constexpr predicates from <type_traits>.

Problem 39: Unpack My Tuple

std::pair<T1, T2> gives us two heterogeneous values in one object. Problem 17 used it constantly — std::map stores key-value pairs, std::minmax returns a pair of iterators. But what about three values? Or four? Writing nested pairs (pair<int, pair<string, bool>>) is possible but unreadable. Enter std::tuple.

std::tuple: N Heterogeneous Values

std::tuple<T1, T2, ..., TN> generalises pair to an arbitrary number of elements. The types need not be related.

#include <tuple>
#include <string>

// Explicit construction:
std::tuple<int, std::string, double> t{42, "hello", 3.14};

// Factory (deduces types):
auto t2 = std::make_tuple(42, std::string{"hello"}, 3.14);

Accessing Elements

Elements are accessed by index or by type using the free function template std::get:

std::get<0>(t);    // 42      (int)
std::get<1>(t);    // "hello" (std::string)
std::get<2>(t);    // 3.14    (double)

// By type -- only unambiguous if the type appears exactly once:
std::get<std::string>(t);  // "hello"

std::tuple_size<decltype(t)>::value gives the number of elements; std::tuple_element<0, decltype(t)>::type gives the type of element 0. These are the machinery that std::get relies on internally.

std::tie: Unpacking into Existing Variables

Before C++17, the standard way to unpack a tuple into named variables was std::tie:

int    n;
std::string s;
double d;

std::tie(n, s, d) = t;   // n=42, s="hello", d=3.14

// Ignore fields you don't need:
std::tie(n, std::ignore, d) = t;

std::tie creates a tuple of references to its arguments. Assigning a tuple to it copies each element into the referenced variable.

Structured Bindings (C++17)

C++17 introduces a much cleaner syntax for unpacking. It works on tuples, pairs, structs, and arrays.

auto [n, s, d] = t;    // n is int, s is std::string, d is double

The types are deduced; you just name the pieces. This is the same auto [ok, val] syntax from Problem 35’s pair example — now generalised to any fixed-size heterogeneous aggregate.

Structured Bindings on Pairs and Maps

Problem 17 showed that iterating over a std::map is clunky because each element is a std::pair<const Key, Value>:

std::map<std::string, int> scores{{"Alice", 90}, {"Bob", 85}};

// Pre-C++17: verbose
for (auto &kv : scores) {
    std::cout << kv.first << ": " << kv.second << "\n";
}

// C++17 structured binding: clear and natural
for (auto &[name, score] : scores) {
    std::cout << name << ": " << score << "\n";
}

Structured Bindings on Plain Structs

Structured bindings work on any aggregate (a struct with no user-provided constructor, no virtual functions, and no private members), binding the variables to the fields in declaration order:

struct Point { int x; int y; };
Point p{3, 4};

auto [x, y] = p;   // x == 3, y == 4

For non-aggregate types, structured bindings require a get<N> specialisation and std::tuple_size / std::tuple_element traits — the same protocol that std::pair and std::tuple already satisfy.

Aside (CS 146 connection: tuples and pattern matching). Haskell and Racket both have tuples. In Haskell, (Int, String, Double) is the type of a 3-tuple; let (n, s, d) = t is the idiom for unpacking it.

In Racket, (match t [(list n s d) ...]) is the pattern-match equivalent. These are all the same idea: name the pieces of a compound value at the use site without first defining a dedicated record type.

Structured bindings in C++17 bring the same convenience to statically typed C++ code. The compiler deduces the types; you just give the pieces names that make the code readable.

std::apply: Unpack as Function Arguments

Sometimes you want to pass a tuple’s elements as separate arguments to a function. std::apply does this:

#include <tuple>
#include <functional>

auto add = [](int a, int b, int c) { return a + b + c; };

auto args = std::make_tuple(1, 2, 3);
int result = std::apply(add, args);   // same as add(1, 2, 3): result == 6

std::apply is useful when you build argument lists dynamically and then call a function with them — a pattern that appears in generic dispatchers, test frameworks, and serialisation libraries.

Worked Example: Multiple Return Values

A common use of tuple is returning multiple values from a function without defining a dedicated struct.

// Returns {mean, variance, count} -- all computed in one pass.
std::tuple<double, double, int>
stats(const std::vector<double> &data) {
    if (data.empty()) return {0.0, 0.0, 0};
    double sum = 0, sum2 = 0;
    for (double x : data) { sum += x; sum2 += x * x; }
    int n = static_cast<int>(data.size());
    double mean = sum / n;
    double var  = sum2 / n - mean * mean;
    return {mean, var, n};
}

// Caller unpacks with a structured binding:
auto [mean, var, n] = stats(data);
std::cout << "mean=" << mean << " var=" << var << " n=" << n << "\n";

Note. Prefer a named struct over a tuple when the fields have semantic meaning that a reader should not have to deduce from position. tuple<double, double, int> says nothing about which double is the mean and which is the variance. A struct named Stats with fields mean, var, and count is self-documenting. The tuple approach is convenient for short-lived, internal helper functions where names would be over-engineering; it becomes a liability when the type crosses API boundaries.

Tuple Comparison and Structured Binding References

Tuples support lexicographic comparison with ==, <, and the rest, provided the element types do. This makes them immediately usable in sorted containers and with algorithms that require ordering.

auto a = std::make_tuple(1, "abc", 3.0);
auto b = std::make_tuple(1, "abd", 3.0);

a < b;   // true: compares element by element; first difference is "abc" < "abd"
a == b;  // false

Structured bindings introduce names, not copies, by default when the right-hand side is an lvalue. Using auto & gives you references; auto gives copies.

std::tuple<int, std::string> t{42, "hi"};

auto  [a, b] = t;   // a and b are copies; modifying a does not change t
auto &[c, d] = t;   // c and d are references; modifying c changes t
const auto &[e, f] = t;  // read-only references

The reference form is especially important in the range-for over a std::map: writing for (auto [k, v] : m) copies every key-value pair. Writing for (const auto &[k, v] : m) avoids the copies.

A classic use of tuple comparison: sort records by a composite key without writing a custom comparator.

struct Student { std::string name; int grade; double gpa; };

std::vector<Student> students = { /* ... */ };

// Sort by (grade descending, gpa descending, name ascending):
std::sort(students.begin(), students.end(), [](const Student &a, const Student &b) {
    return std::make_tuple(-a.grade, -a.gpa, a.name)
         < std::make_tuple(-b.grade, -b.gpa, b.name);
});

Negating the numeric fields reverses their ordering. The tuple comparison handles the tie-breaking automatically, left to right. No custom comparator logic to write or debug.

Problem 40: Constraining Templates

Templates accept any type that satisfies the operations the code uses. That flexibility is their strength, but it has a sharp edge. Instantiate std::sort on a type that has no operator< and the compiler produces a wall of error messages deep inside the standard library implementation — none of which mention the actual mistake at the call site. Problem 24 gave us tag dispatch as one solution. Problem 25 mentioned SFINAE as another. Both work, but both are verbose and hard to read. C++20 gives us a better one: concepts.

The Problem: Opaque Template Errors

struct NoCmp { int x; };   // no operator<

std::vector<NoCmp> v = { {3}, {1}, {2} };
std::sort(v.begin(), v.end());   // a screenful of errors

The errors name internal helper types and lambdas deep in the <algorithm> header. The user’s mistake — providing an incomparable type — is nowhere in the message.

A concept is a compile-time predicate on types. Attaching one to a template parameter produces a clean diagnostic at the call site when the constraint is not satisfied.

Writing a Concept

#include <concepts>

template<typename T>
concept Comparable = requires(T a, T b) {
    { a < b } -> std::convertible_to<bool>;
};

Read this as: T satisfies Comparable if, given two const T values a and b, the expression a < b is well-formed and its result is convertible to bool.

requires Expressions

The body of a requires expression is a list of requirements. There are four kinds:

template<typename T>
concept Printable = requires(T x, std::ostream &os) {
    // Simple requirement: expression must be well-formed:
    os << x;

    // Type requirement: T must have a nested type:
    typename T::value_type;

    // Compound requirement: well-formed AND result satisfies a concept:
    { x.size() } -> std::convertible_to<std::size_t>;

    // Nested requirement: a further concept must hold:
    requires std::copyable<T>;
};

Using Concepts

There are three syntactic styles. All are equivalent; choose the one that reads most clearly for your context.

As a template parameter constraint.

template<Comparable T>
T max(T a, T b) { return a < b ? b : a; }

With a requires clause.

template<typename T>
    requires Comparable<T>
T max(T a, T b) { return a < b ? b : a; }

Abbreviated function template (C++20).

// 'auto' makes it a template; 'Comparable auto' constrains it:
Comparable auto max(Comparable auto a, Comparable auto b) {
    return a < b ? b : a;
}

The abbreviated form is the most concise. The requires-clause form is most flexible: its condition can be an arbitrary boolean expression, not just a single concept name.

Standard Library Concepts

C++20’s <concepts> header provides a rich library of built-in concepts:

std::same_as<T, U>       // T and U are the same type
std::derived_from<T, B>  // T is derived from B
std::convertible_to<T,U> // T is implicitly convertible to U
std::integral<T>         // T is an integral type
std::floating_point<T>   // T is a floating-point type
std::copyable<T>         // T can be copy-constructed and copy-assigned
std::movable<T>          // T can be move-constructed and move-assigned
std::equality_comparable<T>  // T has operator==
std::totally_ordered<T>      // T has all six comparison operators
std::invocable<F, Args...>   // F is callable with Args...

The <iterator> header adds iterator concepts: std::input_iterator, std::random_access_iterator, std::sentinel_for, and so on.

How Concepts Replace SFINAE

The old SFINAE way to write a constrained max (using std::enable_if):

template<typename T,
         typename = std::enable_if_t<
             std::is_same_v<
                 decltype(std::declval<T>() < std::declval<T>()),
                 bool>>>
T max(T a, T b) { return a < b ? b : a; }

The concept version:

template<Comparable T>
T max(T a, T b) { return a < b ? b : a; }

Same semantics. Dramatically better error messages. And the intent is explicit in the code.

Aside (CS 246 / Problem 24 connection: tag dispatch was a hand-rolled concept). Problem 24’s iterator tags were C++’s original compile-time dispatch mechanism. Each tag (random_access_iterator_tag, etc.) is essentially a hand-written concept: a type-level predicate that classifies iterator types. The overloaded doAdvance functions are hand-written concept-driven dispatch.

Concepts subsume all of this. The standard library’s iterator concepts (std::random_access_iterator, std::bidirectional_iterator, …) now express these distinctions directly, and the advance algorithm can be written with a requires clause or constrained overloads instead of tag objects.

Worked Example: Constrained max

#include <concepts>

template<typename T>
concept LessThanComparable = requires(T a, T b) {
    { a < b } -> std::convertible_to<bool>;
};

template<LessThanComparable T>
const T &max(const T &a, const T &b) { return a < b ? b : a; }

struct NoCmp { int x; };

int main() {
    max(3, 5);          // OK: int satisfies LessThanComparable
    max(NoCmp{}, NoCmp{});  // error: NoCmp does not satisfy LessThanComparable
    // Error message names the concept -- clear and helpful.
}

Note. Concepts are about what a type must do, not what it is. std::integral<T> checks whether T is an integral type by querying a type trait. Comparable<T> checks whether T supports < — it would be satisfied by any user-defined type that provides the operator, regardless of its inheritance hierarchy. This is duck typing made explicit and statically verified: if it supports <, it satisfies Comparable.

Problem 41: Lazy Pipelines

Problem 17 gave us std::transform, std::copy_if, std::accumulate, and friends. They work. But chaining them is painful. Each step allocates a new intermediate container. Each step requires an output iterator. Composing three transformations means three temporary vectors, three passes over the data, and three iterator pairs to manage.

C++20 introduces the ranges library, which solves all of these problems at once.

The Pain of Chaining Algorithms

Suppose we want the squares of all even numbers in a vector.

std::vector<int> v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

// Step 1: filter evens -- allocates a new vector
std::vector<int> evens;
std::copy_if(v.begin(), v.end(), std::back_inserter(evens),
             [](int n) { return n % 2 == 0; });

// Step 2: square them -- allocates another new vector
std::vector<int> squares;
std::transform(evens.begin(), evens.end(), std::back_inserter(squares),
               [](int n) { return n * n; });

// squares == {4, 16, 36, 64, 100}

Two temporary vectors, two passes, lots of boilerplate. With ten steps the code would be unreadable.

Views: Lazy Adapters

C++20’s std::views (also accessible as std::ranges::views) provides lazy range adapters. A view does not compute anything when constructed. It wraps the underlying range and produces elements on demand, one at a time, as you iterate. No intermediate containers. No extra passes.

#include <ranges>
#include <vector>
#include <iostream>

std::vector<int> v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

auto result = v
    | std::views::filter([](int n) { return n % 2 == 0; })
    | std::views::transform([](int n) { return n * n; });

for (int x : result) {
    std::cout << x << " ";   // 4 16 36 64 100
}

The | pipe operator composes views left-to-right. result is not a vector — it is a lightweight view object that remembers the composition. Elements are produced lazily as the range-for loop advances.

The View Vocabulary

The standard library ships a rich set of views. Here are the most common:

views::filter(pred)       // yield only elements satisfying pred
views::transform(fn)      // apply fn to each element
views::take(n)            // yield at most n elements
views::drop(n)            // skip first n elements
views::reverse            // iterate backwards (requires bidirectional range)
views::iota(a, b)         // generates a, a+1, ..., b-1 on demand
views::iota(a)            // infinite sequence a, a+1, a+2, ...
views::keys               // from a range of pairs, yield only the keys
views::values             // from a range of pairs, yield only the values
views::enumerate          // (C++23) yield {index, element} pairs
views::zip(r1, r2)        // (C++23) yield pairs of elements side-by-side

views::iota is particularly powerful because it generates a range without an underlying container at all:

// Print the first 5 squares, no vector needed:
for (int x : std::views::iota(1, 6)
             | std::views::transform([](int n){ return n * n; })) {
    std::cout << x << " ";   // 1 4 9 16 25
}

Ranges Algorithms

The <algorithm> header gains a parallel set of algorithms in the std::ranges:: namespace. These take a range directly instead of a pair of begin/end iterators.

std::vector<int> v = {3, 1, 4, 1, 5, 9, 2, 6};

std::ranges::sort(v);              // sort in-place

auto it = std::ranges::find(v, 5); // returns iterator, not bool

std::ranges::copy(v, std::ostream_iterator<int>{std::cout, " "});

The range overloads are strictly more convenient: one argument instead of two, and they work directly with views.

// Sort only the even elements (copy to a temp view, sort that):
auto evens = v | std::views::filter([](int n){ return n % 2 == 0; });
// Note: filter view is not sortable directly (not a common range).
// For in-place work on views, use ranges::for_each or materialize first.
std::ranges::for_each(evens, [](int x){ std::cout << x << " "; });

Materialising a View

A view is not a container. To store the results in a vector, you must materialise the view. In C++23, std::ranges::to does this cleanly:

// C++23:
auto squares_of_evens = v
    | std::views::filter([](int n){ return n % 2 == 0; })
    | std::views::transform([](int n){ return n * n; })
    | std::ranges::to<std::vector>();

// C++20 workaround (no std::ranges::to yet):
std::vector<int> out;
for (int x : result) out.push_back(x);

Aside (CS 146 connection: lazy evaluation and infinite lists). In Haskell, all evaluation is lazy by default. [1..] is an infinite list of integers; take 5 (map (*2) [1..]) produces [2,4,6,8,10] without ever generating the full infinite list. The pipeline is evaluated only as far as take demands.

std::views::iota(1) is an infinite range. Composing it with views::take(5) is the exact C++ equivalent of take 5 [1..]. Nothing is computed until the for-loop (or a materialising algorithm) demands elements.

This is lazy evaluation in a normally eager language. Ranges bring it to C++ in a controlled, opt-in way, restricted to sequence processing rather than applied globally.

Worked Example: Top 5 Words by Length

Take a string of words, find the five longest, and print them in order of length.

#include <ranges>
#include <algorithm>
#include <string>
#include <vector>
#include <iostream>
#include <sstream>

int main() {
    std::string sentence = "the quick brown fox jumps over a lazy dog";
    std::istringstream iss{sentence};
    std::vector<std::string> words{
        std::istream_iterator<std::string>{iss}, {}};

    // Sort words longest-first:
    std::ranges::sort(words, [](auto &a, auto &b){
        return a.size() > b.size();
    });

    // Take the top 5 and print them:
    for (auto &w : words | std::views::take(5)) {
        std::cout << w << " (" << w.size() << ")\n";
    }
    // Output: jumps(5) quick(5) brown(5) over(4) lazy(4)
}

No temporary containers for the top-5 step. views::take(5) wraps the sorted vector lazily; the range-for loop reads the first five elements and stops.

Note. The ranges library decouples iterators from sentinels. In the classic STL, begin() and end() must have the same type. In ranges, the sentinel (end marker) may have a different type than the iterator, as long as they can be compared with !=. This enables ranges over null-terminated C strings (where the sentinel is a comparison against '\0') and other non-symmetric iteration patterns that the old model could not express cleanly. The concepts std::ranges::range and std::sentinel_for formalise this — we met concept syntax in Problem 40.

Problem 42: Non-Owning Views

Back in Problem 3 we built a resizable array from scratch, and we already knew how C passes arrays around: a pointer to the first element plus a separate size_t for the length. Every function that needed to look at a contiguous sequence had to accept two parameters and trust the caller to pass a matching pair. Get it wrong — pass the wrong length, forget to subtract one, slice the wrong half — and you get undefined behaviour with no compiler warning. Strings were even worse: a const char* carries no length at all, so every substring operation either allocates a fresh copy or resorts to pointer arithmetic.

There is a better way. C++17 gives us two types that bundle the pointer and the length together, add a rich interface on top, and crucially do so without owning the underlying data.

The Ownership Distinction

Problem 14 drew a sharp line between owning and non-owning handles to memory. A std::unique_ptr<T> owns its pointee: when the smart pointer dies, the object dies with it. A raw pointer T* may or may not own what it points to — the type gives you no clue.

C++17 introduces two unambiguously non-owning types:

std::string_view

std::string_view (from <string_view>) represents a window into some existing character data. It stores just two things: a pointer to the first character and a length. It is always cheap to copy.

Construction

#include <string_view>

// From a string literal -- no allocation
std::string_view sv1 = "hello, world";

// From a std::string -- sv2 points into s's buffer
std::string s = "hello, world";
std::string_view sv2 = s;

// From a pointer + length -- useful for buffers
const char *buf = "hello, world";
std::string_view sv3{buf, 5};   // "hello"

All three constructions are O(1): no characters are copied.

Operations

string_view supports almost every read-only operation you expect from std::string: size(), empty(), operator[], front(), back(), find(), rfind(), starts_with() (C++20), ends_with() (C++20), and range-based for. The two operations most worth highlighting are substr and remove_prefix:

std::string_view sv = "2024-01-15";

// substr returns another view -- still no allocation
std::string_view year  = sv.substr(0, 4);   // "2024"
std::string_view month = sv.substr(5, 2);   // "01"

// remove_prefix / remove_suffix adjust the view in place
sv.remove_prefix(5);   // sv is now "01-15"
sv.remove_suffix(3);   // sv is now "01"

Compare this with std::string::substr, which heap-allocates a brand-new string every time. string_view::substr just adjusts the pointer and length. No allocation, no copy.

The Golden Rule

Note. The underlying data must outlive the view. A string_view is a pointer into memory it does not own. If that memory is freed or moved — if a std::string is destroyed, or resized, or moved to a new allocation — the view becomes a dangling pointer.

std::string_view danger() {
    std::string s = "temporary";
    return s;     // s is destroyed here; caller gets a dangling view -- UB
}

Never return a string_view that refers to a local variable. Never store a string_view as a class data member unless you can prove the string it refers to outlives the object containing the view.

string_view as a Parameter Type

The most important use of string_view is as a function parameter. Before C++17, a function that just read a string had to choose between:

void f(const std::string &s);  // forces allocation if caller passes a literal
void f(const char *s);         // no length; no std::string interface

Neither is ideal. string_view accepts both:

void f(std::string_view sv);   // accepts literals, strings, substrings

f("hello");              // no allocation -- literal becomes a string_view
f(some_std_string);      // points into the string's buffer; no copy
f(sv.substr(0, 5));      // another view; still no allocation

It works. One parameter type, all callers, no heap traffic.

std::span

std::span<T> (from <span>, standardized in C++20 but available in C++17-era toolchains via <gsl/span> or library headers) does for contiguous sequences of arbitrary type what string_view does for characters. It stores a pointer and a length. It does not own the data.

Fixed-size vs Dynamic Extent

span comes in two flavours:

// Dynamic extent: length not known at compile time
std::span<int> s1;

// Fixed extent: length baked into the type
std::span<int, 5> s2;

The fixed-extent form span<T, N> is a zero-overhead wrapper: the compiler knows the size at compile time and can optimize loops and bounds checks accordingly, without storing the length at runtime. The dynamic-extent form span<T> is the more commonly useful one.

Construction

int arr[5] = {1, 2, 3, 4, 5};
std::vector<int> v = {10, 20, 30};

std::span<int>    s1{arr};           // from C array
std::span<int>    s2{v};             // from vector
std::span<int, 5> s3{arr};          // fixed-extent from C array
std::span<int>    s4{arr + 1, 3};   // pointer + length: {2, 3, 4}

Like string_view, all constructions are O(1).

Subspans

std::span<int> s{v};

auto first3 = s.first(3);        // first 3 elements
auto last2  = s.last(2);         // last 2 elements
auto middle = s.subspan(1, 2);   // starting at index 1, length 2

Each returns a new span into the same underlying storage. No copying.

Replacing Pointer+Length Parameters

The old C style:

// Two parameters that must stay synchronized -- easy to mismatch
void process(const int *data, size_t len);

The C++ view style:

// Single parameter; accepts arrays, vectors, sub-ranges, all of it
void process(std::span<const int> data) {
    for (int x : data) { /* ... */ }
}

int arr[10] = {};
std::vector<int> v(20);
process(arr);                // OK
process(v);                  // OK
process({v.data(), 5});      // first 5 elements of v

The size is carried along automatically. The mismatch bug is gone.

Aside (Rust connection: borrows and slices). Rust formalizes views at the language level. A Rust string slice &str is exactly a string_view: a fat pointer (data address plus length) that borrows its data from some owner. Rust’s slice type &[T] is exactly a span<T>. The difference is that Rust’s borrow checker enforces the golden rule at compile time: a slice cannot outlive the owner it borrows from. C++ has no such static enforcement — the rule is a programmer responsibility, not a language guarantee. Rust’s approach eliminates the class of dangling-view bugs at the cost of learning the borrow checker; C++’s approach gives you the performance without the restriction.

Worked Example: Pattern Search in a Byte Buffer

Suppose we write a function that searches for a short byte pattern inside a larger buffer. With the old interface:

// Old style: four parameters, two pairs to keep in sync
bool contains(const uint8_t *buf, size_t buf_len,
              const uint8_t *pat, size_t pat_len);

With span:

#include <span>
#include <algorithm>
#include <cstdint>

bool contains(std::span<const uint8_t> buf,
              std::span<const uint8_t> pat) {
    if (pat.size() > buf.size()) return false;
    for (size_t i = 0; i + pat.size() <= buf.size(); ++i) {
        if (std::equal(pat.begin(), pat.end(),
                       buf.begin() + i))
            return true;
    }
    return false;
}

Two parameters. The sizes are always synchronized because they are part of the type. Any contiguous range — a C array, a std::vector, a section of a memory-mapped file — can be passed without modification.

Note the use of span<const uint8_t> rather than span<uint8_t>. The const here is on the element type, not the span itself. A span<const T> is a read-only view: the elements cannot be modified through it. A span<T> is a read-write view.

A span<T> implicitly converts to span<const T> (just as T* converts to const T*). The reverse does not compile. Use span<const T> for input parameters, span<T> only when the function needs to write back into the caller’s buffer.

Note. Never store a span or string_view as a class data member unless you have ironclad proof that the referred-to data outlives every instance of the class. In practice that means the referred-to data should be static or live in a scope that strictly encloses every instance. When in doubt, store a std::string or std::vector instead — they own their data and the lifetime question dissolves.

Problem 43: A Real Date Library

For most of this course, “time” meant “performance.” Back in Problem 1 we used clocks briefly, timing how long operations took. But <chrono> is much more than a stopwatch. It contains a carefully designed system of types for durations, time points, and clocks — a system that prevents the classic bugs of mixing seconds with milliseconds or subtracting timestamps from different clocks. C++20 extends it further with calendar types that let you write actual dates. The full picture deserves proper coverage.

The Core Idea: Types Prevent Bugs

The classic duration bug in C:

// Old C style -- no idea what units any of these are
long timeout   = 5;      // seconds? milliseconds?
long heartbeat = 200;    // milliseconds? microseconds?
if (elapsed > timeout + heartbeat) { /* ... */ }  // silent unit mismatch

<chrono> makes the units part of the type. Adding a std::chrono::seconds to a std::chrono::milliseconds compiles and gives the right answer. Adding a steady_clock::time_point to a system_clock::time_point does not compile. The type system catches the bug before the program runs.

Duration Types

A std::chrono::duration<Rep, Period> represents a span of time. Rep is the numeric representation (usually long long) and Period is a std::ratio that relates the tick to a second. You almost never write this by hand. The standard library provides all the common specializations:

#include <chrono>
using namespace std::chrono;

nanoseconds  ns{1};      // 1 nanosecond
microseconds us{1};      // 1 microsecond
milliseconds ms{200};    // 200 milliseconds
seconds      s{5};       // 5 seconds
minutes      m{2};       // 2 minutes
hours        h{1};       // 1 hour

Duration Arithmetic

Durations support the arithmetic you expect, with automatic unit promotion:

seconds s{5};
milliseconds ms{200};

auto total = s + ms;   // total has type milliseconds, value 5200
auto diff  = s - ms;   // milliseconds{4800}
auto triple = s * 3;   // seconds{15}

s += minutes{1};       // s is now seconds{65}

Converting to a coarser unit requires an explicit duration_cast — the compiler will not silently lose precision:

milliseconds ms{5200};
seconds s = duration_cast<seconds>(ms);   // s{5}: truncates toward zero
// seconds s = ms;   // ERROR: narrowing conversion not allowed implicitly

User-Defined Literals

C++14 adds duration literals so you can write durations inline without constructing types explicitly:

using namespace std::chrono_literals;

auto timeout   = 5s;     // std::chrono::seconds{5}
auto heartbeat = 200ms;  // std::chrono::milliseconds{200}
auto delay     = 1h + 30min;  // std::chrono::minutes{90}

auto sleep_for = 50us;   // microseconds
auto precision = 10ns;   // nanoseconds

The using namespace std::chrono_literals is necessary to bring the literal suffixes into scope. They live in their own sub-namespace precisely so you can import them without pulling in the entire std::chrono namespace.

Clock Types

A clock provides a now() function that returns a time point, and a period that tells you the resolution. C++ provides three:

Time Points

clock::now() returns a time_point<clock>. Time points can be subtracted to get a duration:

auto t1 = std::chrono::steady_clock::now();
auto t2 = std::chrono::steady_clock::now();
auto elapsed = t2 - t1;   // type: steady_clock::duration

Subtracting two time points from different clocks does not compile. That is the whole point.

time_since_epoch() gives the duration between the clock’s epoch (an implementation-defined point in time, typically 1970-01-01 for system_clock) and the time point:

auto now     = std::chrono::system_clock::now();
auto epoch_s = duration_cast<seconds>(now.time_since_epoch());
// epoch_s.count() is the Unix timestamp

Measuring Elapsed Time

The canonical timing pattern:

#include <chrono>
#include <iostream>
using namespace std::chrono;

auto t0 = steady_clock::now();

do_work();

auto elapsed = duration_cast<milliseconds>(steady_clock::now() - t0);
std::cout << "Elapsed: " << elapsed.count() << " ms\n";

.count() extracts the raw numeric value in the duration’s units. It is the only place where you cross the boundary from the type-safe world back to a plain integer.

Note. Use steady_clock for measuring elapsed time. It is monotonic: it advances at a constant rate and never jumps. system_clock is the wrong tool here because it can be adjusted mid-measurement by the operating system (NTP sync, daylight saving, etc.).

A Timer RAII Class

Problem 14 showed that any resource that needs cleanup belongs in an RAII wrapper. Time measurement is no different: the “resource” is the start time, and the “cleanup” is logging the elapsed duration.

#include <chrono>
#include <iostream>
#include <string>
using namespace std::chrono;

class Timer {
    std::string   label_;
    steady_clock::time_point start_;
public:
    explicit Timer(std::string label)
        : label_{std::move(label)}, start_{steady_clock::now()} {}

    ~Timer() {
        auto ms = duration_cast<milliseconds>(
            steady_clock::now() - start_).count();
        std::cout << label_ << ": " << ms << " ms\n";
    }
};

Usage:

void expensive_function() {
    Timer t{"expensive_function"};
    // ... work happens here ...
}   // Timer destructor fires: "expensive_function: 47 ms"

No matter how expensive_function exits — normal return, exception, early return from a nested scope — the timer logs.

C++20 Calendar Types

C++20 adds calendar and time-zone support. The key new types are year_month_day, sys_days, and year_month_day_last.

#include <chrono>
using namespace std::chrono;

// Constructing a date: year/month/day syntax
year_month_day d1 = 2024y / January / 15;
year_month_day d2 = 2024y / 1 / 15;    // same date

// Querying
int y = static_cast<int>(d1.year());   // 2024
unsigned m = static_cast<unsigned>(d1.month());  // 1
unsigned day = static_cast<unsigned>(d1.day());  // 15

// Is it a valid date?
d1.ok();    // true; would be false for 2024/February/30

sys_days converts a year_month_day to a time_point that can be used with system_clock. The bridge goes the other way too:

// time_point -> calendar date
auto today = floor<days>(system_clock::now());  // truncate to whole day
year_month_day ymd{today};
std::cout << ymd.year() << "-" << ymd.month() << "-" << ymd.day() << "\n";

// calendar date -> time_point (for arithmetic with durations)
sys_days target = 2024y / December / 25;
auto days_away  = target - today;
std::cout << days_away.count() << " days until Christmas\n";

The Last Day of the Month

A classic calendar calculation:

year_month_day last_day_of_jan = 2024y / January / last;
// last_day_of_jan.day() == 31

year_month_day last_day_of_feb = 2024y / February / last;
// 2024 is a leap year; last_day_of_feb.day() == 29

The standard library handles leap years and varying month lengths for you.

Aside (CS 343 connection: timed waits). In CS 343 you will use std::this_thread::sleep_for() to pause a thread for a specified duration. It accepts a chrono duration directly:

#include <thread>
#include <chrono>
using namespace std::chrono_literals;

std::this_thread::sleep_for(100ms);   // sleep for 100 milliseconds
std::this_thread::sleep_until(
    std::chrono::steady_clock::now() + 1s);  // sleep until 1 s from now

The type safety extends into threading: you cannot accidentally pass a plain integer where a duration is expected, and the units are explicit in the code.

Note. For wall-clock time (“what time is it right now?”) use system_clock. For measuring elapsed real time (“how long did this take?”) use steady_clock. The two purposes are different and deserve different clocks. high_resolution_clock is a shorthand for whichever of the two has finer resolution on the current platform; it is fine for quick experiments but says nothing about monotonicity.

Problem 44: A Real Filesystem API

Problem 1 opened files with std::ifstream and std::ofstream. That covers reading and writing the contents of files. But what about the world around those files? Creating directories. Listing what is in a folder. Checking whether a file exists before trying to open it. Copying, renaming, removing. In Problem 2 we briefly thought about separate compilation and the .cc/.h file structure of a project — all of which assumes you are navigating a directory tree. Doing any of that with portable code used to require calling POSIX functions (opendir, stat, mkdir) or Windows APIs, and writing separate implementations for each platform.

C++17 changes that. <filesystem> is a full, portable API for the directory structure around your files.

std::filesystem::path

Everything in <filesystem> revolves around std::filesystem::path. A path represents a location in the filesystem: it might name an existing file, a directory, or something that does not exist yet. It knows nothing about permissions or contents; it is just a name.

#include <filesystem>
namespace fs = std::filesystem;

fs::path p1 = "/usr/local/include";   // absolute path (POSIX)
fs::path p2 = "src/main.cc";          // relative path
fs::path p3 = "C:\\Users\\Alice";     // Windows path also works

Composing Paths

The / operator appends a component:

fs::path base = "/home/alice";
fs::path full = base / "projects" / "myapp" / "src";
// full == "/home/alice/projects/myapp/src"

Look familiar? It is operator overloading to make path manipulation read like shell notation.

Decomposing Paths

fs::path p = "/home/alice/report.pdf";

p.filename();      // "report.pdf"
p.stem();          // "report"
p.extension();     // ".pdf"
p.parent_path();   // "/home/alice"
p.root_path();     // "/"
p.is_absolute();   // true

p.string();        // native string representation

These all return path objects (except string(), which returns std::string, and the boolean queries).

Querying the Filesystem

fs::path p = "/home/alice/data.csv";

fs::exists(p);             // does anything at this path exist?
fs::is_regular_file(p);    // is it a regular file?
fs::is_directory(p);       // is it a directory?
fs::is_symlink(p);         // is it a symbolic link?

fs::file_size(p);          // size in bytes (throws if not a regular file)
fs::last_write_time(p);    // returns a filesystem::file_time_type

All of these query the filesystem on every call — they are not cached. If you need to make multiple queries about the same file, it is more efficient to use a fs::directory_entry, which caches the stat results.

Iterating a Directory

Flat Iteration

std::filesystem::directory_iterator yields one directory_entry for each item directly inside a directory (not recursively):

for (const fs::directory_entry &entry : fs::directory_iterator{"."}) {
    std::cout << entry.path().filename() << "\n";
}

The order is unspecified. Use std::sort on the paths if you need them in alphabetical order.

Recursive Iteration

std::filesystem::recursive_directory_iterator walks the entire subtree:

for (const fs::directory_entry &entry :
         fs::recursive_directory_iterator{"."}) {
    if (entry.is_regular_file()) {
        std::cout << entry.path() << "\n";
    }
}

Creating and Removing

fs::create_directory("output");           // create one directory
fs::create_directories("a/b/c");          // create whole path, like mkdir -p

fs::remove("output/old.txt");             // remove a single file
fs::remove_all("output");                 // remove directory and all contents

fs::rename("old_name.txt", "new_name.txt");  // rename or move

fs::copy("src.txt", "dst.txt");              // copy a file
fs::copy("src_dir", "dst_dir",
         fs::copy_options::recursive);       // copy directory tree

Error Handling: Two Forms

Most <filesystem> functions have two overloads. The default throws std::filesystem::filesystem_error on failure. An overload that takes an std::error_code& stores the error instead of throwing:

// Throwing form: use when failure is unexpected
fs::file_size("/etc/passwd");   // throws filesystem_error if it fails

// Non-throwing form: use when failure is routine
std::error_code ec;
auto sz = fs::file_size("/etc/passwd", ec);
if (ec) {
    std::cerr << "Error: " << ec.message() << "\n";
}

The non-throwing form is useful in performance-sensitive loops or when you expect certain failures (a file that might or might not exist).

Aside (CS 246 / CS 136 connection: POSIX underpinnings). Under the hood, <filesystem> on Linux is implemented using the same POSIX calls you saw in CS 136: stat(2), opendir(3)/readdir(3), mkdir(2), rename(2), and unlink(2). On Windows it uses GetFileAttributes, FindFirstFile, CreateDirectory, etc. The <filesystem> API gives you a single interface that compiles and behaves consistently on both. If you ever need a capability it does not expose — file locking, extended attributes, device numbers — you still have to drop down to the platform API.

Worked Example: Total Size of Source Files

A function that recursively totals the size of all .cpp files in a directory tree:

#include <filesystem>
#include <iostream>
namespace fs = std::filesystem;

uintmax_t cpp_total_size(const fs::path &root) {
    uintmax_t total = 0;
    std::error_code ec;
    for (const auto &entry :
             fs::recursive_directory_iterator{root, ec}) {
        if (ec) break;   // skip unreadable subtrees
        if (entry.is_regular_file() &&
            entry.path().extension() == ".cpp") {
            total += entry.file_size();
        }
    }
    return total;
}

int main() {
    auto bytes = cpp_total_size(".");
    std::cout << bytes << " bytes in .cpp files\n";
}

Note the use of entry.file_size() rather than fs::file_size(entry.path()). Both give the same result, but the directory_entry version is cheaper because the stat information was fetched during iteration and is already cached.

Combine last_write_time() with <chrono> (Problem 43) to find files modified in the last 24 hours:

auto cutoff = fs::file_time_type::clock::now()
              - std::chrono::hours{24};
for (const auto &entry : fs::recursive_directory_iterator{"."}) {
    if (entry.is_regular_file() &&
        entry.last_write_time() > cutoff) {
        std::cout << entry.path() << "\n";
    }
}

Paths Are Not Files

One subtlety worth internalizing: a fs::path object is just a string with path-manipulation methods. It does not verify that the path names an existing file. You can construct a path to something that does not exist, compose new paths from it, and only then call fs::exists() to check:

fs::path target = "/nonexistent/dir" / "file.txt";
// Constructing the path: always succeeds
// Querying it:
if (!fs::exists(target)) {
    std::cout << "no such file\n";
}

The / operator does not touch the disk. It purely manipulates the string representation of the path, using the platform’s separator character. This matters because constructing a path is cheap and can be done offline from any I/O; the I/O only happens when you call a querying or modifying function.

Canonical Paths

fs::canonical(p) resolves all symbolic links and .. components and returns an absolute path that refers unambiguously to the same filesystem object:

fs::path p = "src/../include/./foo.h";
fs::path c = fs::canonical(p);   // e.g. "/home/alice/include/foo.h"
// c has no ../ or ./ components, and no symlink indirections

fs::weakly_canonical(p) is like canonical but does not require the path to exist: it resolves as much as it can and leaves the rest as-is.

Note. Path comparison is operating-system sensitive. On Windows, filesystem paths are case-insensitive: C:\Users\Alice and C:\USERS\ALICE refer to the same file, but operator== on fs::path does a lexicographic comparison and would consider them different. To test whether two paths refer to the same filesystem object regardless of case or symlinks, use fs::equivalent(p1, p2), which resolves both paths through the OS and compares inodes (on POSIX) or file identifiers (on Windows).

Problem 45: Type-Safe Formatting

Problem 1 taught us std::cout and the stream output model. Stream output is type safe — you cannot accidentally print an integer with a %s format specifier — but it is awkward for anything beyond the simplest output. Aligning a table means calling std::setw, std::left, std::setprecision, and remembering to std::setfill if you want something other than spaces. Worse, many of those settings are sticky: they persist across subsequent output unless you explicitly reset them. You set the flags, print one value, and then spend the next ten minutes wondering why all subsequent output is still left-aligned.

The alternative is printf-style formatting. It is concise and familiar from CS 136. It is also a trap: passing the wrong argument for a format specifier is undefined behaviour, and the compiler is not required to catch it.

C++20 gives us the best of both: std::format.

The reveal: what was wrong before

Here is what a formatted table looked like with stream manipulators before C++20:

#include <iostream>
#include <iomanip>

void old_style(const std::string &name, double val) {
    std::cout << std::left  << std::setw(20) << name
              << std::right << std::setw(10) << std::fixed
              << std::setprecision(2) << val << "\n";
    // Did you remember to reset std::fixed and std::setprecision afterward?
    // The next caller's output will be affected if you didn't.
}

The flags set on std::cout persist across calls. std::fixed and std::setprecision(2) stay in effect until something else changes them. This makes output functions non-composable: calling one function can silently alter the formatting of another.

The Basic Idea

std::format takes a format string with replacement fields (marked by curly braces) and a list of arguments. It returns a std::string:

#include <format>

std::string s = std::format("{} + {} = {}", 1, 2, 3);
// s == "1 + 2 = 3"

Every argument is formatted using its type’s formatter. There is no %d/%s distinction; the type of the argument determines how it is rendered. Passing the wrong number of arguments is a compile error (in most implementations; the standard requires a runtime exception for mismatches that cannot be caught at compile time, but implementations go further).

Format Specifiers

Inside the curly braces you can put a format specification after a colon. The syntax is:

{[index]:[fill][align][sign][#][0][width][.precision][type]}

Most of the fields are optional. Here are the most useful ones:

Width and Alignment

std::format("{:10}", 42);       // "        42"  (right-align, width 10)
std::format("{:<10}", 42);      // "42        "  (left-align, width 10)
std::format("{:^10}", 42);      // "    42    "  (center, width 10)
std::format("{:*^10}", 42);     // "****42****"  (fill with '*', center)
std::format("{:010}", 42);      // "0000000042"  (zero-pad, width 10)

Precision and Floating Point

std::format("{:.3f}", 3.14159);        // "3.142"  (3 decimal places)
std::format("{:>10.3f}", 3.14159);     // "     3.142"  (right-align, width 10)
std::format("{:.6g}", 0.000123456);    // "0.000123456"  (general format)
std::format("{:e}", 12345.678);        // "1.234568e+04"  (scientific)

Integer Bases

std::format("{:d}", 255);    // "255"     (decimal, the default)
std::format("{:x}", 255);    // "ff"      (lowercase hex)
std::format("{:X}", 255);    // "FF"      (uppercase hex)
std::format("{:#x}", 255);   // "0xff"    (hex with 0x prefix)
std::format("{:b}", 255);    // "11111111" (binary)
std::format("{:o}", 255);    // "377"     (octal)

Positional Arguments

Arguments are used in order by default, but you can address them by index:

std::format("{0} {1} {0}", "ab", "cd");   // "ab cd ab"
std::format("{1} {0}", "world", "hello"); // "hello world"

std::print (C++23)

Constructing a std::string and then writing it is sometimes wasteful. C++23 adds std::print and std::println which format and write in a single call:

#include <print>

std::print("Hello, {}!\n", "world");    // no intermediate string
std::println("x = {}", 42);             // println appends '\n' automatically

// Write to a specific stream
std::print(std::cerr, "Error: {}\n", message);

std::print is also guaranteed to be atomic for each call, which means it is safer than interleaving std::cout << calls from multiple threads.

std::format_to

When you need to write into an existing buffer or iterator without creating a temporary string, use std::format_to:

#include <format>
#include <iterator>

std::string buf;
buf.reserve(64);

std::format_to(std::back_inserter(buf), "x = {:>8.3f}", 3.14159);
// buf == "x =    3.142"

std::format_to_n writes at most n characters, avoiding buffer overflows when writing into a fixed-size array.

Custom Formatters

You can teach std::format how to format your own types by specializing std::formatter<T>. The specialization must provide two methods: parse (which reads the format specification) and format (which produces the output):

struct Point { int x, y; };

template<>
struct std::formatter<Point> {
    // parse: read any format spec (we ignore it; just consume it)
    constexpr auto parse(std::format_parse_context &ctx) {
        return ctx.begin();
    }
    // format: produce the output
    auto format(const Point &p, std::format_context &ctx) const {
        return std::format_to(ctx.out(), "({}, {})", p.x, p.y);
    }
};

Point pt{3, 4};
std::string s = std::format("Point: {}", pt);  // "Point: (3, 4)"

Aside (CS 146 connection: format strings across languages). Python’s f-strings (f"{x:.2f}") were a direct inspiration for std::format. Racket’s format procedure (~a, ~s) is similar in spirit but dynamically typed: the format string is not checked against the argument types until runtime. Python’s f-strings resolve the format at compile time (the expression is evaluated, not matched to a spec string), so type errors surface immediately. std::format sits between the two: the format string is a runtime value, but the argument types are checked at compile time (in conforming implementations), giving type safety without requiring interpolation syntax.

A Performance Note

std::format does not use the global locale by default. Numbers always use . as the decimal separator, regardless of the user’s locale setting. This is intentional: locale-sensitive output was one of the least loved aspects of std::cout. To opt into locale formatting, add the L flag:

std::format("{:L}", 1234567.89);    // locale-specific: "1,234,567.89" in en_US
std::format("{}", 1234567.89);      // always:          "1234567.89"

Worked Example: A Table Formatter

A function that prints a two-column table with fixed-width columns:

#include <format>
#include <iostream>
#include <vector>
#include <string>

void print_table(const std::vector<std::pair<std::string,double>> &rows) {
    std::cout << std::format("{:<20} {:>10}\n", "Name", "Value");
    std::cout << std::string(32, '-') << "\n";
    for (const auto &[name, val] : rows) {
        std::cout << std::format("{:<20} {:>10.2f}\n", name, val);
    }
}

Sample output:

Name                      Value
--------------------------------
Alice                     92.50
Bob                       87.33
Carol                    100.00

Compare writing this with stream manipulators. The std::format version states the layout at the call site, is self-resetting (the format string is consumed per-call, not sticky), and reads as a single coherent expression.

Dynamic Width and Precision

Width and precision can themselves come from arguments, using {:{n}} or {:.{n}} syntax where n is the index of the width argument:

int width = 12;
int prec  = 4;
// {:*<{}.{}} means: fill '*', left-align, width from arg, precision from arg
std::format("{:*<{}.{}f}", 3.14159, width, prec);
// "3.1416******"

This is useful when the column widths are not known at compile time — for example, when building a table where the widths are computed by scanning the data first.

A common idiom: measure the longest entry, then format all entries to that width.

std::vector<std::string> names = {"Alice", "Bob", "Christopher"};
size_t col = 0;
for (const auto &n : names) col = std::max(col, n.size());

for (const auto &n : names) {
    std::cout << std::format("{:<{}}", n, col) << "\n";
}
// Alice
// Bob
// Christopher   (all padded to width 11)

Note. std::format was introduced in C++20. Compiler support arrived gradually: GCC 13, Clang 14, and MSVC 19.29 have complete implementations. For earlier compilers the fmtlib library (https://fmt.dev) provides the same interface as a third-party header. Many codebases used fmtlib before C++20 standardized it; the APIs are nearly identical. If you are writing production code that must support older compilers, fmtlib is the right answer today.

Problem 46: Strings That Match

Problem 1 read input line by line with std::getline and character by character with >>. For simple inputs that works. But sometimes input has structure — dates in a log file, email addresses in a CSV, URLs embedded in HTML — and writing a hand-rolled parser for each format is tedious and error-prone. The natural tool for recognising structured text patterns is regular expressions. C++11 adds them to the standard library.

Quick Regex Reference

The ECMAScript dialect used by default supports the following meta-characters:

Constructing a Pattern

std::regex (from <regex>) compiles a pattern string into an internal representation that can be matched against strings:

#include <regex>

std::regex date_re{R"(\d{4}-\d{2}-\d{2})"};         // ISO date: 2024-01-15
std::regex email_re{R"([a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,})"};

Raw string literals (R"(...)") are convenient here because the regex syntax uses many backslashes and the raw form avoids double-escaping.

The default syntax is ECMAScript (the same flavour as JavaScript). Other syntaxes are available as flags:

std::regex re{"^hello$", std::regex::icase};          // case-insensitive
std::regex posix_re{"[[:alpha:]]+", std::regex::awk}; // POSIX ERE syntax

Matching

std::regex_match: Does the Whole String Match?

std::regex_match requires the entire input string to match the pattern. It returns true or false:

std::regex date_re{R"(\d{4}-\d{2}-\d{2})"};

std::regex_match("2024-01-15", date_re);    // true
std::regex_match("2024-1-15",  date_re);    // false -- only one month digit
std::regex_match("prefix 2024-01-15", date_re);  // false -- extra prefix

std::regex_search: Does Any Part Match?

std::regex_search succeeds if the pattern matches anywhere inside the input:

std::string log = "[2024-01-15] Server started on port 8080";
std::regex date_re{R"(\d{4}-\d{2}-\d{2})"};

std::regex_search(log, date_re);   // true -- found the date inside

Capturing Subgroups with std::smatch

Parentheses in the pattern define capture groups. The match results are stored in a std::smatch (string match) object:

std::string s = "2024-01-15";
std::regex date_re{R"((\d{4})-(\d{2})-(\d{2}))"};
std::smatch m;

if (std::regex_match(s, m, date_re)) {
    std::string whole = m[0];   // "2024-01-15" (the entire match)
    std::string year  = m[1];   // "2024"
    std::string month = m[2];   // "01"
    std::string day   = m[3];   // "15"
}

m[0] is always the full match. m[1], m[2], etc. are the captured groups in left-to-right order. Each element is a std::ssub_match which converts implicitly to std::string.

std::cmatch works the same way but for const char* instead of std::string.

Replacement

std::regex_replace returns a new string with all matches substituted:

std::string text = "cat and cat and cat";
std::regex cat_re{"cat"};

// Replace every match
std::string r = std::regex_replace(text, cat_re, "dog");
// r == "dog and dog and dog"

// Back-references in the replacement: $1 refers to capture group 1
std::regex date_re{R"((\d{4})-(\d{2})-(\d{2}))"};
std::string rearranged = std::regex_replace(
    "2024-01-15", date_re, "$3/$2/$1");
// rearranged == "15/01/2024"

Iterating Over All Matches

std::sregex_iterator produces one match result per occurrence:

std::string text = "foo@bar.com and baz@qux.org are valid";
std::regex email_re{R"([a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,})"};

auto begin = std::sregex_iterator{text.begin(), text.end(), email_re};
auto end   = std::sregex_iterator{};

for (auto it = begin; it != end; ++it) {
    std::smatch m = *it;
    std::cout << m[0] << "\n";
}
// foo@bar.com
// baz@qux.org

Look familiar? It is the same iterator protocol from Problem 8 and Problem 17. sregex_iterator is an input iterator; you can pass it to the algorithms in <algorithm> just like any other iterator pair.

A Performance Warning

Note. std::regex compiles the pattern at runtime. Compilation is expensive: it builds a finite automaton from the pattern string, which takes time proportional to the size of the pattern. If you use a regex inside a loop, declare it const outside the loop so it is compiled only once:

// SLOW: recompiles the pattern on every iteration
for (const auto &line : lines) {
    if (std::regex_search(line, std::regex{R"(\d+)"})) { ... }
}

// FAST: compile once, search many times
const std::regex num_re{R"(\d+)"};
for (const auto &line : lines) {
    if (std::regex_search(line, num_re)) { ... }
}

This is the single most common std::regex performance mistake.

Regex Flags

Several flags can be combined with | when constructing a std::regex:

// icase: case-insensitive matching
std::regex ci_re{"hello", std::regex::icase};
std::regex_search("HELLO world", ci_re);   // true

// multiline: ^ and $ match start/end of each line, not just the whole string
std::regex ml_re{"^start", std::regex::multiline};

// nosubs: do not store sub-expression matches (faster if you don't need them)
std::regex fast_re{R"(\d+)", std::regex::nosubs | std::regex::optimize};

The std::regex::optimize flag hints to the implementation that the pattern will be used many times, so it should spend extra time upfront constructing an efficient automaton.

Worked Example: Extracting URLs from Text

#include <regex>
#include <string>
#include <vector>

std::vector<std::string> extract_urls(const std::string &text) {
    // simplified URL pattern: http(s)://...
    const std::regex url_re{
        R"(https?://[^\s<>"{}|\\^`\[\]]+)"
    };
    std::vector<std::string> urls;
    auto begin = std::sregex_iterator{text.begin(), text.end(), url_re};
    for (auto it = begin; it != std::sregex_iterator{}; ++it) {
        urls.push_back((*it)[0]);
    }
    return urls;
}

The URL pattern is intentionally simple. Real URL parsing is more complex, but this covers the common case. Note that the const std::regex is declared inside the function body — it is still constructed once per call to extract_urls. If extract_urls is called in a tight loop, move the regex to a static const local to get the familiar “construct once per program” guarantee.

Aside (CS 241 connection: regular languages and DFAs). In CS 241 you studied the formal theory of regular languages. A regular expression describes a regular language; matching a string against the regex is equivalent to running the corresponding DFA. std::regex implements this at runtime: the constructor builds the automaton, and the search functions run it. The ECMAScript dialect adds back-references (\1, \2), which are not part of the strict formal definition of regular expressions — back-references can express non-regular patterns, so they are implemented with backtracking rather than a pure DFA, which can cause exponential worst-case behaviour on pathological inputs.

A typical use: extract the timestamp and severity from a structured log line.

// Log format: "[2024-01-15 08:32:01] ERROR: disk full"
const std::regex log_re{
    R"(\[(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2})\] (\w+): (.+))"
};
std::string line = "[2024-01-15 08:32:01] ERROR: disk full";
std::smatch m;
if (std::regex_match(line, m, log_re)) {
    std::string ts       = m[1];  // "2024-01-15 08:32:01"
    std::string severity = m[2];  // "ERROR"
    std::string message  = m[3];  // "disk full"
}

Note. std::regex is the right tool for recognising patterns. For simple prefix or suffix checks, string_view methods from Problem 42 are faster and clearer: sv.starts_with("http") is better than constructing and running a regex. For structured formats with nested grammar (JSON, XML, C++ source), a regex is the wrong tool entirely — use a proper parser.

Problem 47: Numbers Drawn From a Distribution

At some point every program needs a random number. The C function rand() has been in the language since C89, and you have probably used it before. But it is broken in several ways. The randomness is poor — most implementations use a linear congruential generator whose low-order bits cycle with very short periods. The range is implementation-defined (RAND_MAX could be 32767 on some platforms). It is seeded globally, so you cannot have two independent streams of random numbers running at the same time. And rand() % N introduces a bias whenever RAND_MAX + 1 is not a multiple of N. In Problem 17 we saw that std::random_shuffle — which was removed in C++17 — was based on rand() and inherited all of these problems.

C++11 provides a proper replacement in <random>. It separates two orthogonal concerns: generating random bits, and mapping those bits to values in a desired distribution.

Why rand() is Broken

The classic C idiom for a random integer in the range [0, N) is:

#include <cstdlib>
srand(time(nullptr));   // seed once at startup
int r = rand() % N;     // NOT uniformly distributed!

The modulo introduces a bias. If RAND_MAX + 1 is not divisible by N, the values near the bottom of the range come up slightly more often than those near the top. With RAND_MAX = 32767 and N = 100, the values 0–67 appear 329 times each and 68–99 appear 328 times each — a small but real bias. For a card shuffle this matters: you do not want 75% of deals to slightly favour certain orderings.

The fix is not to use modulo. The C++11 distributions handle the bias correctly by using rejection sampling: if the engine produces a value in the biased tail, the distribution discards it and tries again. This is exactly what std::uniform_int_distribution does internally.

The Two Concepts: Engines and Distributions

The key insight is that the same engine can drive many different distributions without bias between them. In the old rand() world, the entire program shared one global stream. With <random>, each distribution request draws from a well-defined engine, with no interference.

Engines

The workhorse is std::mt19937, an implementation of the Mersenne Twister algorithm. It has a period of 2^19937 - 1, excellent statistical properties, and is the right default for simulation and games. There is also a 64-bit version, std::mt19937_64, for generating 64-bit random values.

Seeding

#include <random>

// Deterministic seed: same output every run (useful for testing)
std::mt19937 rng{42};

// Non-deterministic seed: different output on each run
std::random_device rd;
std::mt19937 rng2{rd()};

std::random_device reads from the OS’s entropy source (/dev/urandom on Linux, BCryptGenRandom on Windows). It is not a pseudo-random engine; it is a gateway to true randomness. Using it to seed the Mersenne Twister is the standard idiom.

Note. On some embedded or virtualized platforms, std::random_device may not have access to a hardware entropy source and falls back to a deterministic sequence. Check rd.entropy() — if it returns 0.0, the device is deterministic and you should use a different seeding strategy.

Distributions

A distribution object is constructed with its parameters, then called with the engine to generate a value:

std::mt19937 rng{std::random_device{}()};

// Uniform integer in [1, 6] inclusive
std::uniform_int_distribution<int> die{1, 6};
int roll = die(rng);

// Uniform real in [0.0, 1.0)
std::uniform_real_distribution<double> unit{0.0, 1.0};
double u = unit(rng);

// Normal distribution with mean 0, standard deviation 1
std::normal_distribution<double> gauss{0.0, 1.0};
double x = gauss(rng);

// Bernoulli: true with probability p
std::bernoulli_distribution coin{0.5};
bool heads = coin(rng);

The engine is passed by reference to operator(). The distribution reads as many bits as it needs and updates the engine’s state. Two distributions can share an engine with no interaction between them.

Other Useful Distributions

The standard library provides many others: std::poisson_distribution, std::exponential_distribution, std::discrete_distribution (a weighted choice over a finite set), and std::piecewise_constant_distribution. They all follow the same dist(engine) pattern.

Discrete Distribution: Weighted Choice

A common game-programming pattern is a weighted random selection from a finite menu. std::discrete_distribution takes a list of weights and produces indices according to those weights:

// Loot table: 60% common, 30% rare, 10% legendary
std::discrete_distribution<int> loot{{60.0, 30.0, 10.0}};
std::mt19937 rng{std::random_device{}()};

int tier = loot(rng);   // 0, 1, or 2 with probabilities 0.6, 0.3, 0.1

The weights do not need to sum to 1; the distribution normalizes them.

Shuffling

std::shuffle (from <algorithm>) replaces the removed std::random_shuffle:

#include <algorithm>
#include <vector>

std::vector<int> deck = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
std::mt19937 rng{std::random_device{}()};

std::shuffle(deck.begin(), deck.end(), rng);
// deck is now in a uniformly random permutation

std::random_shuffle was removed in C++17 because it used rand(). std::shuffle takes an explicit engine, so the source of randomness is under your control.

Thread Safety

Note. Random engines are not thread-safe. Calling dist(rng) from two threads simultaneously on the same engine is a data race. The fix is to give each thread its own engine:

thread_local std::mt19937 local_rng{std::random_device{}()};

void worker() {
    std::uniform_int_distribution<int> dist{1, 100};
    int v = dist(local_rng);   // safe: local_rng is per-thread
}

The thread_local storage class (introduced in C++11) gives each thread its own copy of the variable, initialized the first time that thread touches it.

Worked Example: Monte Carlo Estimation of π

A classic application: estimate π by sampling random points in the unit square and checking whether they fall inside the unit circle.

#include <random>
#include <cmath>
#include <iostream>

double estimate_pi(long long trials) {
    std::mt19937_64 rng{std::random_device{}()};
    std::uniform_real_distribution<double> dist{-1.0, 1.0};
    long long inside = 0;
    for (long long i = 0; i < trials; ++i) {
        double x = dist(rng), y = dist(rng);
        if (x*x + y*y <= 1.0) ++inside;
    }
    return 4.0 * static_cast<double>(inside) / trials;
}

int main() {
    std::cout << estimate_pi(10'000'000) << "\n";  // ~3.1416
}

The 10'000'000 uses C++14 digit separators for readability. The uniform_real_distribution covers the range [-1, 1] on both axes, so the unit circle fits inside the sampling square with area 4; multiplying the hit rate by 4 gives the estimate of π.

Aside (CS 466 / STAT courses connection: pseudo-random sampling). The quality of Monte Carlo estimates depends on the quality of the underlying random number generator. A poor generator introduces correlations between samples that can bias results in subtle, hard-to-detect ways. This is exactly why std::mt19937 is the standard recommendation: its statistical properties have been rigorously tested (Diehard battery, TestU01) and it passes all standard randomness tests. In numerical methods courses you will encounter quasi-random (low-discrepancy) sequences (Halton, Sobol) that converge faster than pseudo-random numbers for certain integration problems; C++ does not provide these in the standard library, but the engine/distribution separation makes it easy to plug in your own engine.

For scientific simulations, you often want results to be reproducible: run the same seed, get the same sequence. Fixed seeds make bugs debuggable.

// Set via command line: ./sim --seed 42
// Or use random_device for one-off runs
unsigned seed = 42;
std::mt19937 rng{seed};
std::cout << "seed: " << seed << "\n";  // log it so you can reproduce

std::uniform_int_distribution<int> d{1, 100};
for (int i = 0; i < 5; ++i)
    std::cout << d(rng) << " ";  // deterministic: same every run with seed 42

This pattern is standard in research code: log the seed alongside results so that any run can be exactly replicated.

Note. For cryptographic purposes — generating session tokens, passwords, keys — do not use std::mt19937. The Mersenne Twister is a predictable generator: after observing 624 consecutive outputs, an attacker can reconstruct the internal state and predict all future outputs. For cryptographic randomness, use std::random_device directly (it reads from the OS’s cryptographically secure source) or a platform-specific API (BCryptGenRandom on Windows, getrandom(2) on Linux).

Problem 48: Heterogeneous Storage Revisited

Problem 36 gave us std::variant for storing one of a closed set of types — closed meaning the set is fixed at compile time. Problem 35 gave us std::optional for the degenerate case of one type that may or may not be present. Between those two tools, a great deal of heterogeneous storage is covered. But not all of it.

Sometimes the set of types is genuinely open. A scripting language interpreter stores values that can be integers, floats, strings, lists, or any user-defined type — and users can add new types. A plugin system passes messages between components that were compiled independently and know nothing about each other’s type hierarchy. A property bag on a game entity holds arbitrary attributes whose types are set at data-load time, not compile time. For those cases, C++17 provides std::any.

The void* Comparison

Before C++17, the idiomatic (if unsafe) way to store an arbitrary value was void*:

// Old C-style heterogeneous storage
void *value = nullptr;
int x = 42;
value = &x;              // any pointer fits

// To get the value back:
int *p = static_cast<int *>(value);   // hope you remembered the type!

There is nothing wrong if you actually remember the type. But nothing stops you from casting to the wrong type, and the result is undefined behaviour with no diagnostic. std::any wraps the same concept with type tracking:

std::any value = 42;
// std::any_cast<std::string>(value);  // throws bad_any_cast -- caught!
int v = std::any_cast<int>(value);     // OK

The type is remembered at assignment time and checked at extraction time.

std::any

std::any (from <any>) can hold a value of any copy-constructible type. It is the type-safe version of void*.

#include <any>

std::any a = 42;          // holds an int
a = std::string{"hello"}; // now holds a std::string
a = 3.14;                 // now holds a double

At any moment, an any holds at most one value. Assigning a new value destroys the previous one.

Constructing

std::any a1;                          // empty
std::any a2 = 42;                     // holds int{42}
std::any a3 = std::make_any<int>(42); // same; make_any is explicit about T
std::any a4 = std::string{"world"};   // holds a std::string

a1.has_value();   // false
a2.has_value();   // true
a2.reset();       // a2 is now empty

Accessing: any_cast

Retrieving the stored value requires knowing its type. You declare what you expect, and the cast either succeeds or fails:

std::any a = 42;

// Cast by value: throws std::bad_any_cast if the type is wrong
int v = std::any_cast<int>(a);      // v == 42

// Cast by reference: also throws if type is wrong
std::any_cast<int &>(a) = 99;       // modifies the stored value in place

// Cast by pointer: returns nullptr instead of throwing
int *p = std::any_cast<int>(&a);    // p != nullptr
std::string *sp = std::any_cast<std::string>(&a);  // sp == nullptr

The pointer form is the right choice when you are probing for a type you are not sure about. Catching std::bad_any_cast is the right choice when a type mismatch would be a genuine programming error.

Querying the Type

a.type() returns a const std::type_info& identifying the stored type. You can compare it with typeid:

std::any a = 42;
if (a.type() == typeid(int)) {
    std::cout << "Holds an int\n";
}

This is dynamic type introspection — the runtime equivalent of what std::variant’s std::holds_alternative<T> does statically.

Comparison: optional, variant, any

Here is the decision table:

The costs matter. optional<T> and variant<T1,...> are stack-only; no heap, no indirection. any almost certainly heap-allocates anything larger than a pointer or two (small-buffer optimization varies by implementation but is not guaranteed).

The Small-Buffer Optimization

Most implementations of std::any include a small-buffer optimization (SBO): if the stored value is small enough (typically up to sizeof(void*) bytes, though the exact threshold is implementation-defined), it is stored inline inside the any object with no heap allocation. Larger values are heap-allocated.

std::any a = 42;          // int: small -- likely stored inline, no heap
std::any b = std::string{"hello world"};  // string: larger -- heap-allocates

You cannot rely on any particular threshold. If you care about allocation, prefer std::variant or design your own type-erased wrapper with a known SBO policy.

Type Erasure Connection

std::any is a concrete instance of the type erasure pattern (which we will examine more formally in Problem 56). It uses an internal virtual-dispatch mechanism to call the correct copy constructor, destructor, and typeid for whatever type it happens to hold, without the user having to name that type. You are already familiar with this idea: std::function<Ret(Args...)> from Problem 17 is another type-erased wrapper, there over callables rather than arbitrary values.

Worked Example: A Property Bag

A common use in game programming: entity components with heterogeneous attributes stored by name.

#include <any>
#include <string>
#include <unordered_map>
#include <stdexcept>

class PropertyBag {
    std::unordered_map<std::string, std::any> props_;
public:
    template<typename T>
    void set(const std::string &key, T &&value) {
        props_[key] = std::forward<T>(value);
    }

    template<typename T>
    T get(const std::string &key) const {
        auto it = props_.find(key);
        if (it == props_.end())
            throw std::out_of_range{"key not found: " + key};
        return std::any_cast<T>(it->second);  // throws bad_any_cast if wrong T
    }

    bool has(const std::string &key) const {
        return props_.count(key) > 0;
    }
};

Usage:

PropertyBag entity;
entity.set("name", std::string{"Dragon"});
entity.set("hp", 250);
entity.set("speed", 3.5);

std::string name = entity.get<std::string>("name");  // "Dragon"
int hp           = entity.get<int>("hp");            // 250

Each attribute can be a different type. New attribute types — textures, AI behaviour parameters, custom component classes — can be added later without changing PropertyBag at all. That openness is exactly what std::any is for.

Aside (CS 247 / CS 346 connection: scripting and plugin systems). Dynamic languages like Lua and Python use this pattern pervasively: every value is essentially a tagged union (the language’s runtime equivalent of any) that carries its type at runtime. When embedding Lua in a C++ game engine, the bridge between the two worlds often uses a structure exactly like PropertyBag: a map from string names to std::any values that Lua scripts can read and write. The type safety boundary is enforced at the any_cast site.

Sometimes you want to enumerate all stored properties without knowing their types in advance. std::any::type() enables this:

void dump(const PropertyBag &bag) {
    // In a real implementation, iterate over the internal map.
    // Here we show how to dispatch on dynamic type.
    std::any a = bag.get<std::any>("somekey");  // hypothetical raw access
    if (a.type() == typeid(int))
        std::cout << "int: " << std::any_cast<int>(a) << "\n";
    else if (a.type() == typeid(std::string))
        std::cout << "str: " << std::any_cast<std::string>(a) << "\n";
    else
        std::cout << "unknown type: " << a.type().name() << "\n";
}

The type().name() call gives an implementation-defined mangled name. Useful for debugging; not suitable for production logic.

Note. The decision guide in one sentence: prefer std::variant when you know the types at compile time; prefer inheritance and virtual functions when the types are known but the behaviour is what varies; use std::any only when the types genuinely cannot be predicted at compile time and you are prepared to pay for the heap allocation and the runtime type-check on every access. any gives you maximum flexibility at the cost of all compile-time guarantees. Use it sparingly.

Problem 49: I Want Two Things at Once

We have built a complete Vector, mastered template programming, and studied every ownership model C++ offers. There is one more dimension we have not touched: time. A modern computer has several processor cores sitting idle while our programs execute on one. Every loop, every computation, every wait-for-IO is an opportunity we leave on the table.

The problem: I want to do two things simultaneously.

What Is a Thread?

A thread is an independent sequence of instructions executing within a shared address space. Multiple threads in the same process see the same global variables and heap-allocated objects, but each thread has its own call stack, its own program counter, and its own set of registers.

C++11 standardises thread creation through std::thread, declared in <thread>. Before C++11, portable concurrency required either the POSIX thread library (pthreads) or platform-specific APIs — each with a different interface and error-handling model.

Creating and Starting a Thread

#include <thread>
#include <iostream>

void say_hello() {
    std::cout << "Hello from a thread!\n";
}

int main() {
    std::thread t{say_hello};   // create thread; it starts immediately
    std::cout << "Hello from main!\n";
    t.join();                   // wait for t to finish
}

The std::thread constructor takes a callable (function, lambda, or functor) and zero or more arguments to pass to it. The thread starts executing the callable immediately upon construction — there is no separate “start” call.

void sum_range(const std::vector<int> &v,
               size_t lo, size_t hi, long long &result) {
    result = 0;
    for (size_t i = lo; i < hi; ++i) result += v[i];
}

int main() {
    std::vector<int> v(10'000'000, 1);
    long long left = 0, right = 0;
    size_t mid = v.size() / 2;

    std::thread t{sum_range,
                  std::ref(v), 0, mid, std::ref(left)};
    sum_range(v, mid, v.size(), right);
    t.join();

    std::cout << left + right << '\n';    // 10000000
}

std::ref(v) wraps v in a reference wrapper because std::thread’s constructor copies its arguments by default — passing v directly would silently copy the entire vector into the thread.

Thread Lifecycle: join and detach

Every std::thread object that is joinable — meaning its thread is still running or has finished but has not been collected — must have exactly one of two things done to it before its destructor runs:

1. t.join() — the calling thread blocks until t’s thread finishes, then marks t as non-joinable. Use when you need the result or want to wait for completion.

2. t.detach() — the calling thread lets t’s thread run independently in the background. The thread’s resources are released when the thread finishes. t is then non-joinable. Use sparingly: once detached, you cannot wait for the thread or know when it finishes.

If a std::thread is destroyed while still joinable, its destructor calls std::terminate — the same hard abort we saw in Problem 9 when two exceptions were simultaneously active.

{
    std::thread t{some_work};
    // ... do something else ...
    // if we return here without join() or detach(): std::terminate!
}

Aside (CS 343 connection: μC++ tasks vs std::thread). In CS 343 you use μC++, a language extension built on top of C++ that introduces _Task as a first-class concept. A _Task is automatically started when declared and automatically joined at the end of its scope — the compiler enforces the lifecycle that std::thread leaves to the programmer. std::thread is lower-level and more explicit. The advantage is portability and generality; the disadvantage is that the programmer is responsible for every join and detach. C++20’s std::jthread (Chapter 54) recovers the automatic-join behaviour that μC++ provides natively.

The Exception Hazard

Look familiar?

void f() {
    std::thread t{background_work};
    do_some_work();    // might throw
    t.join();          // never reached if exception is thrown
                       // t's destructor: std::terminate!
}

This is the exact same problem as Problem 14 with raw pointers. do_some_work() throws, the exception propagates out of f, t.join() is skipped, and t’s destructor panics. The program terminates abruptly rather than handling the exception.

In Problem 14 we fixed the leak by wrapping the pointer in a class whose destructor calls delete. The fix here is identical in spirit: wrap the thread in a class whose destructor calls join.

Thread RAII

class JoinThread {
    std::thread t_;
public:
    explicit JoinThread(std::thread t) : t_{std::move(t)} {}

    ~JoinThread() {
        if (t_.joinable()) t_.join();
    }

    // Threads cannot be copied -- ownership is unique
    JoinThread(const JoinThread &)            = delete;
    JoinThread &operator=(const JoinThread &) = delete;

    // Moving transfers ownership
    JoinThread(JoinThread &&)            = default;
    JoinThread &operator=(JoinThread &&) = default;
};

Now f is safe regardless of how it exits:

void f() {
    JoinThread t{std::thread{background_work}};
    do_some_work();    // may throw
}   // t's destructor joins the thread -- even on exception

The pattern is RAII: the resource (a running thread) is acquired in the constructor and released in the destructor. The destructor runs unconditionally when the scope exits, whether by normal return or by exception propagation.

Note. C++20 ships std::jthread in <thread>, which does exactly this: it joins automatically in its destructor. Unless you need to target pre-C++20 compilers, prefer std::jthread over the JoinThread wrapper above. Chapter 54 covers std::jthread in full, including its cooperative-cancellation mechanism via std::stop_token.

Passing Arguments: the Reference Pitfall

void update(int &x) { ++x; }

int val = 0;
std::thread t{update, val};    // WRONG: copies val into thread
t.join();
// val is still 0

std::thread’s constructor always copies its arguments. If the callable takes a reference, the thread receives a reference to the copy, not to the original. Use std::ref to force pass-by-reference:

std::thread t{update, std::ref(val)};   // passes reference to val
t.join();
// val is now 1

The object referenced must outlive the thread. A local variable that outlives only the current stack frame will become a dangling reference once that frame is destroyed. Lambdas make the ownership explicit — capturing by value gives the thread its own copy; capturing by reference reintroduces the lifetime risk.

std::vector<int> v(10'000'000, 1);
long long left = 0, right = 0;
size_t mid = v.size() / 2;

JoinThread t{std::thread{[&]() {
    for (size_t i = 0; i < mid; ++i) left += v[i];
}}};
for (size_t i = mid; i < v.size(); ++i) right += v[i];
// t auto-joins here

std::cout << left + right << '\n';

What We Have Not Solved Yet

Splitting work across threads is only half the story. The parallel sum above works because the two halves write to different variables (left and right). What if two threads write to the same variable at the same time?

int counter = 0;

JoinThread t1{std::thread{[&]() {
    for (int i = 0; i < 1'000'000; ++i) ++counter;
}}};
for (int i = 0; i < 1'000'000; ++i) ++counter;
// result is NOT guaranteed to be 2000000

The increment ++counter is not a single hardware instruction; it is a read, a modify, and a write. If two threads interleave those operations, some increments are lost. This is a data race and produces undefined behaviour. Chapter 50 introduces mutexes — locks that prevent two threads from interleaving on shared data.

Problem 50: Sharing Without Stepping on Toes

Problem 49 ended with an unsolved problem: two threads writing to the same integer produced undefined behaviour. The increment was not atomic. We need a way to say “only one thread at a time may touch this data.”

The root cause is a data race: two threads access the same memory location simultaneously, at least one of them writes, and there is no synchronisation between them. The C++ standard says a data race is undefined behaviour — not “probably a wrong answer”, but literally UB, as bad as a dangling pointer or an out-of-bounds array access. The compiler is allowed to assume data races do not occur and to generate code that is entirely wrong if they do. The fix is to introduce explicit synchronisation.