Question 1

You are writing a generic factory function make_unique_service(Args&&... args). Walk through why std::forward(args)... is required instead of std::move, explaining universal/forwarding references and reference collapsing rules when passing mixed lvalue and rvalue arguments.

Accepted Answer

Args&&... in a deduced template context is a forwarding reference, not a plain rvalue reference. The compiler deduces a separate type for each argument based on what you pass: an lvalue argument makes Args deduce to T&, and because of reference collapsing (T& && collapses to T&, T&& && collapses to T&&), the parameter ends up as T&. An rvalue argument deduces Args as plain T, so the parameter stays T&&. This lets one Args&&... pack bind to a mix of lvalues and rvalues in a single call, with each argument's original value category encoded in its deduced type. If you wrote std::move(args)... instead, every argument would be unconditionally cast to an rvalue no matter what the caller passed. That silently lets the factory 'steal' from an lvalue the caller still expects to use afterward — pass a std::string variable by name and it could get moved-from inside the factory, leaving the caller's variable empty. std::forward(args) does a conditional cast instead: since Args was deduced as T& for an lvalue argument, forward's cast is a no-op and the value stays an lvalue; since Args was deduced as plain T for an rvalue argument, forward produces an rvalue cast. So forwarding reproduces whatever value category the caller originally used, all the way through to the constructor the arguments end up at. ```cpp template std::unique_ptr make_unique_service(Args&&... args) { return std::make_unique(std::forward(args)...); } std::string name = "svc"; auto a = make_unique_service(name, 42); // name copied into Service, still usable here auto b = make_unique_service(std::move(name), 42); // name moved-from, as the caller chose ```

Question 2

To parse network packets, an engineer casts a char* network buffer directly to a struct Header* pointer. Why does this violate the C++ Strict Aliasing Rule, how does modern compiler optimization turn this into undefined behavior, and how do you safely parse data using std::memcpy or std::bit_cast?

Accepted Answer

The strict aliasing rule says the compiler may assume that two pointers of unrelated types never point to the same memory location (with a few exceptions, notably char*/unsigned char*/std::byte* may alias anything). Casting a raw char* buffer to struct Header* and dereferencing it creates a Header object at that address that was never actually constructed as a Header — no Header object's lifetime began there. Reading through that pointer is undefined behavior even though it 'looks like it should work', because the standard doesn't grant a Header* the right to alias memory that a char* wrote into as raw bytes; the char*-may-alias-anything exception only goes one direction, not the reverse. Modern compilers use strict aliasing to optimize aggressively: since a Header* and, say, an int* elsewhere in the function are assumed not to overlap, the compiler can reorder or cache loads/stores across them, hoist a load out of a loop, or skip re-reading a value it thinks can't have changed. With network parsing code, this can manifest as the parsed header fields appearing to read stale or garbage values only at higher optimization levels (-O2/-O3), which is exactly why these bugs are notoriously hard to reproduce in debug builds. The safe fix is to never alias through an incompatible pointer type. std::memcpy the raw bytes into a properly-constructed Header object (or use it to initialize one) — memcpy is defined to work on raw byte representations regardless of type, so this sidesteps aliasing entirely, and any competent compiler will optimize away the copy into equivalent code when the sizes/alignment allow it. C++20's std::bit_cast

(buffer) does this more directly for trivially copyable, same-size types, returning a proper Header object. ```cpp struct Header { uint32_t magic; uint16_t len; }; // unsafe: reinterpret_cast(charBuffer) then dereference — UB Header h; std::memcpy(&h, charBuffer, sizeof(Header)); // safe // or, C++20: Header h2 = std::bit_cast

(*reinterpret_cast*>(charBuffer)); ```

Question 3

You need to generate a 256-element CRC lookup table at compile time to eliminate runtime initialization cost. Compare using constexpr versus C++20 consteval functions and explain the constraints placed on dynamic memory allocations and loops during constant evaluation.

Accepted Answer

A constexpr function is a function that is *allowed* to run at compile time, but it isn't forced to: call it with arguments the compiler can't evaluate at compile time (e.g. a runtime variable), and it just falls back to running as an ordinary function at runtime. A consteval function (C++20 'immediate function') is the opposite guarantee: it *must* be evaluated at compile time, in every call, or the program fails to compile. For a CRC table you want purely at compile time, consteval documents that intent and catches any accidental runtime call as a compile error, instead of it silently costing you at startup. Both are subject to the same core constraint during constant evaluation: the code must be free of anything the compiler can't fully reason about at compile time — no undefined behavior, no reading uninitialized memory, no touching volatile objects, and (until fairly late standard revisions loosened this) no dynamic allocation that outlives the evaluation. Since C++14, loops, local variables, and multiple return statements are fully allowed in constexpr functions, so a straightforward for-loop filling a std::array works fine — you're not restricted to the single-return-statement style required pre-C++14. ```cpp consteval std::array makeCrcTable() { std::array table{}; for (uint32_t i = 0; i < 256; ++i) { uint32_t c = i; for (int k = 0; k < 8; ++k) c = (c & 1) ? (0xEDB88320u ^ (c >> 1)) : (c >> 1); table[i] = c; } return table; } inline constexpr auto crcTable = makeCrcTable(); // built entirely at compile time, zero runtime cost ```

Question 4

You have a custom mathematical vector class Vector3D. How do you implement custom std::tuple_size, std::tuple_element, and get<N>() template specializations to enable C++17 structured binding deconstruction auto [x, y, z] = vec;?

Accepted Answer

Structured bindings for a user-defined class (that isn't a plain struct with public members) work through the same 'tuple protocol' std::tuple and std::pair already implement: the compiler needs to know how many elements there are, what type each one is, and how to fetch each one by index. You supply that by specializing std::tuple_size to report the count, std::tuple_element to report each element's type, and by providing a get(Vector3D&) function the compiler can find (either as a member or, more commonly for value types, a free function found via argument-dependent lookup). Once those three pieces exist, auto [x, y, z] = vec; desugars to the compiler introducing a hidden reference to a copy of vec, then calling get<0>, get<1>, get<2> on it and binding x, y, z to those results — it's ordinary tuple-protocol machinery, not compiler magic specific to structured bindings. ```cpp struct Vector3D { double x, y, z; }; template<> struct std::tuple_size : std::integral_constant {}; template struct std::tuple_element { using type = double; }; template double get(const Vector3D& v) { if constexpr (N == 0) return v.x; else if constexpr (N == 1) return v.y; else return v.z; } Vector3D vec{1.0, 2.0, 3.0}; auto [x, y, z] = vec; // x==1.0, y==2.0, z==3.0 ```

Question 5

Design a lock-free Single-Producer Single-Consumer (SPSC) ring buffer in C++. Explain why std::memory_order_relaxed is insufficient for synchronizing the write index with payload buffers, and how std::memory_order_release and std::memory_order_acquire enforce necessary hardware memory barriers.

Accepted Answer

An SPSC ring buffer needs an atomic write index the producer advances after storing a payload, and an atomic read index the consumer advances after reading one; each side only ever writes its own index and reads the other's. memory_order_relaxed guarantees the index update itself is atomic (no torn reads/writes), but it says nothing about the ordering of *other* memory operations around it — specifically, it doesn't stop the compiler or CPU from reordering the payload write to happen *after* the index update becomes visible to the other thread. If that reordering happens, the consumer can see the incremented write index, assume the slot is ready, and read stale or partially-written payload data.

memory_order_release on the producer's index store creates a one-way barrier: every memory write the producer did *before* the release store (including writing the payload into the slot) is guaranteed to be visible to any thread that later reads the same atomic with memory_order_acquire and observes that store's value. memory_order_acquire on the consumer's load of the write index creates the matching barrier in the other direction — nothing the consumer does *after* the acquire load can be reordered before it, so once it sees the new index, it's guaranteed to also see the payload that was written before the release.

Together, release-on-write / acquire-on-read forms a 'synchronizes-with' relationship that establishes a happens-before edge between the producer's payload write and the consumer's payload read, without needing a full seq_cst fence or a mutex — this is what makes lock-free SPSC queues both correct and cheap on real hardware (on x86 this mostly folds into ordinary stores/loads; on ARM/POWER it actually emits real barrier instructions).

```cpp
std::atomic<size_t> writeIdx{0}, readIdx{0};
T buffer[CAPACITY];

// producer
buffer[writeIdx.load(std::memory_order_relaxed) % CAPACITY] = value;
writeIdx.fetch_add(1, std::memory_order_release);

// consumer
size_t w = writeIdx.load(std::memory_order_acquire);
if (readIdx.load(std::memory_order_relaxed) < w) {
    T value = buffer[readIdx.load(std::memory_order_relaxed) % CAPACITY];
    readIdx.fetch_add(1, std::memory_order_release);
}
```

Question 6

A tree data structure holds child nodes via std::vector> while child nodes hold a std::shared_ptr back to their parent. Why does clearing the root node fail to free tree memory, and how do you resolve the memory leak using std::weak_ptr with .lock() checks?

Accepted Answer

shared_ptr frees the pointed-to object only when its reference count reaches zero. With a parent holding shared_ptrs to its children and each child holding a shared_ptr back to its parent, every node in that relationship keeps another node's count above zero forever — even after you drop the last external shared_ptr to the root, the root and its children still reference each other in a cycle, so none of their counts ever hit zero and none of them get destroyed. This is the classic shared_ptr cyclic-reference leak; it's not a crash, just memory (and any RAII resources those nodes hold) that never gets released for the life of the program. The fix is to break the cycle by making one direction of the relationship non-owning. Since a child doesn't need to keep its parent alive (the parent's lifetime is controlled by whoever owns the tree from the top), the back-pointer becomes a std::weak_ptr instead of a shared_ptr. A weak_ptr observes an object without contributing to its shared_ptr reference count, so it doesn't stop the parent from being destroyed. Because a weak_ptr doesn't guarantee the object is still alive, you never dereference it directly — you call .lock(), which atomically returns a shared_ptr that's either valid (object still alive, and now safely kept alive for as long as you hold that shared_ptr) or empty/null (object already destroyed), so you always check it before use. ```cpp struct Node { std::vector> children; std::weak_ptr parent; // non-owning, breaks the cycle }; if (auto p = node->parent.lock()) { // p is a valid shared_ptr here; safe to use } // p released when it goes out of scope; doesn't keep parent alive beyond this ```

Question 7

In a low-latency trading application, standard std::vector and std::string allocations cause heap fragmentation and lock contention on the global heap. How do you implement C++17 Polymorphic Memory Resources (std::pmr) using a std::pmr::monotonic_buffer_resource stack arena?

Accepted Answer

std::pmr decouples a container's allocation strategy from its type: std::pmr::vector and std::pmr::string are the same containers as std::vector/std::string but take a std::pmr::memory_resource* at construction instead of being tied to a fixed Allocator template parameter. That memory_resource is a polymorphic interface (allocate/deallocate virtual calls), so you can swap in a completely different allocation strategy without changing the container's type or any code that operates on it. std::pmr::monotonic_buffer_resource is the simplest such resource: you hand it a fixed block of memory (often just a stack-allocated byte array) up front, and every allocation from it is a cheap bump-pointer increment inside that buffer — no calls to the global allocator, no locking, no fragmentation, as long as the buffer doesn't run out (it falls back to an upstream resource, by default the global heap, if it does). Deallocation is a no-op; the whole arena is reclaimed at once when the buffer resource is destroyed, which is exactly the pattern you want for a per-message or per-tick scratch allocation in a trading hot path — allocate freely during processing, then the entire arena disappears when that stack frame ends. This avoids global-heap lock contention entirely (nothing here touches malloc's internal locks on the hot path) and avoids fragmentation because the memory is reused/reset per call rather than churned through general-purpose allocation. ```cpp void processTick(const RawMessage& msg) { std::array stackBuf; std::pmr::monotonic_buffer_resource arena(stackBuf.data(), stackBuf.size()); std::pmr::vector orders(&arena); std::pmr::string symbol(&arena); // parse msg into orders/symbol — all allocations are bump-pointer, no global heap touched } // arena and stackBuf destroyed together; nothing to free individually ```

Question 8

A class encapsulates a raw OS socket handle and dynamically allocated buffer. Walk through implementing the Rule of Five (destructor, copy constructor, copy assignment, move constructor, move assignment) using the copy-and-swap idiom to ensure strong exception safety and prevent double-close bugs.

Accepted Answer

A class owning a raw resource like a socket file descriptor and a heap buffer needs all five special member functions defined explicitly, because the compiler-generated defaults would just copy the raw handle bit-for-bit — two objects would then both believe they own the same socket, and when both destructors run, the second close() either double-closes an already-closed descriptor or (worse) closes a descriptor the OS has since reassigned to something unrelated.

The destructor closes the socket and frees the buffer if they're valid. The copy constructor should perform a real deep copy (e.g., duplicate the socket via dup(), copy the buffer contents) so the two objects genuinely own independent resources. The move constructor instead steals the source's handle and buffer pointer, then resets the source to a valid-but-empty ('moved-from') state so its destructor is a safe no-op.

The copy-and-swap idiom collapses copy assignment and move assignment into one operator= that takes its parameter *by value* (which itself invokes either the copy or move constructor at the call site, depending on whether the argument is an lvalue or rvalue) and then swaps its own guts with that local parameter using a non-throwing swap. Because the parameter is fully constructed before entering operator=, any exception during construction happens before *this is touched at all — *this stays in its original valid state, giving the strong exception guarantee. When the function returns, the local temporary holding *this*'s old state is destroyed by the ordinary destructor, releasing the old resource exactly once.

```cpp
class Socket {
    int fd_ = -1;
    char* buf_ = nullptr;
public:
    ~Socket() { if (fd_ != -1) close(fd_); delete[] buf_; }
    Socket(const Socket& other) : fd_(dup(other.fd_)), buf_(new char[BUF_SZ]) {
        std::memcpy(buf_, other.buf_, BUF_SZ);
    }
    Socket(Socket&& other) noexcept : fd_(other.fd_), buf_(other.buf_) {
        other.fd_ = -1; other.buf_ = nullptr;
    }
    friend void swap(Socket& a, Socket& b) noexcept {
        std::swap(a.fd_, b.fd_); std::swap(a.buf_, b.buf_);
    }
    Socket& operator=(Socket other) { swap(*this, other); return *this; } // handles both copy and move assign
};
```

Question 9

While looping over a std::vector<Task> using pointers to task elements, a call to tasks.push_back() inside the loop body causes sporadic crashes and heap corruption. Explain iterator and pointer invalidation during vector capacity growth and how to safeguard against dangling pointers.

Accepted Answer

std::vector guarantees contiguous storage, which means when it runs out of spare capacity and needs to grow, it must allocate an entirely new, larger block, move (or copy) every existing element into it, and free the old block. Any pointer, reference, or iterator that referred to an element in the old block is now dangling — it points at memory that has been freed, even though the value 'looks' unchanged for a while afterward, which is exactly why the crash is sporadic rather than immediate: you're reading freed memory that often hasn't been overwritten yet, until it eventually is. This is why taking &tasks[i] or storing an iterator, then calling push_back on the same vector before you're done using that pointer, is a classic bug: push_back may or may not trigger a reallocation depending on current capacity, so the bug can pass tests for a long time and then surface only once the vector happens to cross a capacity boundary in production. The safeguards are: (1) call vector::reserve() up front with an upper bound on the final size so no reallocation happens during the loop at all; (2) store indices instead of pointers/iterators, and re-index (tasks[i]) each time rather than caching an address across a potential mutation; or (3) if elements must remain stable across insertions, use a container that doesn't invalidate on insert, like std::deque (stable references except when inserting at the middle) or std::list. ```cpp std::vector tasks = {...}; for (size_t i = 0; i < tasks.size(); ++i) { Task* t = &tasks[i]; if (t->needsRetry()) tasks.push_back(t->makeRetry()); // may reallocate — t is now potentially dangling! // fix: tasks.reserve(expectedMax) before the loop, or re-fetch &tasks[i] after every mutation } ```

Question 10

Two independent worker threads concurrently increment separate integer counters located in an array int counters[2], resulting in severe multithreaded performance degradation. Explain how CPU cache line bouncing (false sharing) causes this and how to fix it using alignas(hardware_destructive_interference_size).

Accepted Answer

CPUs don't move memory between cache and RAM one variable at a time — they move it in fixed-size chunks called cache lines, typically 64 bytes on modern x86/ARM. Two int counters placed next to each other in a small array (counters[0] and counters[1], 8 bytes total) very likely land in the same 64-byte cache line even though they are logically completely unrelated variables owned by different threads. Cache-coherency protocols (like MESI) track ownership at cache-line granularity, not per-variable. When thread A writes counters[0], the protocol must invalidate that entire cache line in every other core's cache — including thread B's core, even though thread B only ever touches counters[1]. Thread B's next access to counters[1] then misses its local cache and has to re-fetch the line from thread A's core (or memory), and vice versa the moment thread B writes. Under sustained concurrent increments, the two cores end up in a costly loop of invalidating and re-fetching the same cache line back and forth — 'ping-ponging' it between caches — which can be dramatically slower than the actual arithmetic being performed, even though there's no logical data race at all. The fix is to force each counter onto its own cache line so writes to one never invalidate the other's line. std::hardware_destructive_interference_size (C++17, ) gives a portable-ish value for the platform's cache line size, and alignas() pads the struct so consecutive instances don't share a line. ```cpp struct alignas(std::hardware_destructive_interference_size) PaddedCounter { std::atomic value{0}; }; PaddedCounter counters[2]; // each now occupies its own cache line — no more bouncing ```

Question 11

A polymorphic hierarchy defines class Base { public: ~Base() {} }; class Derived : public Base { std::unique_ptr<Buffer> buf; };. When deleting a Derived instance through a Base* pointer, memory is leaked. Explain the vtable mechanism, virtual destructor dispatch, and the object slicing phenomenon.

Accepted Answer

Any class with virtual functions gets a hidden pointer (the vptr) in each object, pointing to a per-class table of function pointers (the vtable). A virtual call like ptr->foo() doesn't jump straight to Base::foo — it follows the object's vptr to its actual runtime class's vtable and calls whatever function pointer is stored there, which is how a Base* can end up calling Derived::foo() at runtime. This only works, though, if the function you're calling is declared virtual in the first place.

Here, ~Base() is not virtual. So delete basePtr; where basePtr's static type is Base* resolves entirely at compile time to Base::~Base() — there's no vtable lookup involved for that call at all, because virtual dispatch never triggers for a non-virtual function regardless of the object's real dynamic type. The result is that Derived's destructor (and by extension, Derived's members like buf, whose own destructor would free the Buffer) never runs; only Base's destructor executes. This is technically undefined behavior per the standard, not merely 'a leak that happens to occur' — but in practice it manifests as exactly that: buf's Buffer is never freed.

Object slicing is a related but distinct bug: it happens when you copy or pass a Derived object *by value* into something expecting a Base, e.g. void process(Base b) (not Base& or Base*). Only the Base portion gets copied into the new Base object — Derived's extra members (like buf) are 'sliced off' entirely, silently, with no error. It's a copying problem, whereas the destructor issue above is a dispatch problem, but both stem from the same root idea: without virtual mechanisms or reference/pointer semantics, C++ treats a Derived-through-a-Base-lens as exactly a Base, nothing more.

The fix for the destructor case is simply to declare Base's destructor virtual: `virtual ~Base() {}` — this puts ~Base in the vtable, so delete basePtr now correctly dispatches to ~Derived() first, then ~Base(), destroying buf along the way.

Question 12

A mathematical matrix computation library avoids virtual function dispatch overhead using the Curiously Recurring Template Pattern (CRTP). How does CRTP achieve compile-time static polymorphism, and how does the base class safely invoke derived class method implementations?

Accepted Answer

CRTP has a class template inherit as its own base parameter: `class DenseMatrix : public MatrixBase`. This lets MatrixBase, at compile time, know the exact concrete type it's being mixed into — it's not a generic 'some future derived class' the way an abstract virtual base is, it's literally DenseMatrix, known and fully resolved when the template is instantiated. Because of that, MatrixBase can implement shared logic once and, when it needs to call into 'derived behavior', simply static_cast(this) to get a pointer of the concrete type, then call a method on that pointer directly — an ordinary, statically-resolved (non-virtual) function call that the compiler can inline. There's no vtable, no indirect function-pointer lookup, and no runtime branch to mispredict; the whole call chain is fixed and typically fully inlined at compile time, which is exactly the overhead virtual dispatch would otherwise add for a tight numerical loop. The safety of the cast relies entirely on the CRTP contract being followed correctly: MatrixBase is only ever actually used as a base of DenseMatrix, so static_cast(this) is always valid in practice — the pattern is a compile-time convention enforced by how the template is used, not something the type system verifies for you beyond that structural relationship. ```cpp template class MatrixBase { public: void multiplyInto(Matrix& out) const { static_cast(this)->multiplyImpl(out); // static, inlinable call } }; class DenseMatrix : public MatrixBase { public: void multiplyImpl(Matrix& out) const { /* actual dense multiply */ } }; ```

Question 13

You are distributing a shared C++ library (.so/.dll). How do you implement the PIMPL (Pointer to Implementation) idiom using std::unique_ptr in the header file, and why must the class destructor be defined in the implementation (.cpp) file rather than defaulted in the header?

Accepted Answer

PIMPL moves all of a class's private implementation details — member variables, private helper types, anything that would otherwise force clients to recompile when it changes — into a separate Impl struct that's only forward-declared in the public header, with the visible class holding just a single std::unique_ptr pointer. Because the header no longer exposes the real layout of the implementation, changing Impl's internals (adding a field, swapping a data structure) doesn't change the public class's size or layout at all, so binaries linked against the old header keep working without recompiling — this is exactly the ABI stability you need when shipping a shared library that other teams/binaries link against without rebuilding in lockstep. The subtlety is in the destructor. std::unique_ptr's own destructor needs Impl to be a complete type at the point it's instantiated, because it has to know how to call Impl's destructor (via sizeof / delete). If you write `~Widget() = default;` (or let the compiler implicitly generate it) inside the header, that destructor gets instantiated right there, in every translation unit that includes the header — at which point Impl is still only forward-declared, incomplete, and the build fails (or, in older/looser toolchains, silently does the wrong thing). The fix is to declare the destructor in the header (just `~Widget();`, no body, no =default) and define it in the .cpp file (`Widget::~Widget() = default;` is fine there), because by that point in the .cpp file Impl's full definition is visible, so unique_ptr's destructor logic can be correctly instantiated exactly once, in the one translation unit that actually knows Impl's layout. ```cpp // widget.h class Widget { public: Widget(); ~Widget(); // declared only — NOT = default here private: struct Impl; std::unique_ptr impl_; }; // widget.cpp struct Widget::Impl { /* real members */ }; Widget::Widget() : impl_(std::make_unique()) {} Widget::~Widget() = default; // fine here — Impl is complete ```

Question 14

In a diamond inheritance hierarchy where classes B and C inherit from A, and D inherits from both B and C, multiple instances of A are created inside D. How does virtual base inheritance resolve this duplicate subobject problem, and how does initialization responsibility shift to the most-derived class?

Accepted Answer

With ordinary (non-virtual) inheritance, `class B : public A`, `class C : public A`, `class D : public B, public C` gives every D object two completely separate A subobjects — one that came in through B, one through C. This causes both the memory waste of duplicated base data and, worse, ambiguity: `d.someAMember` doesn't compile because the compiler can't tell whether you mean B's A or C's A, forcing awkward disambiguation like `d.B::someAMember`.

Declaring the inheritance as virtual — `class B : public virtual A`, `class C : public virtual A` — tells the compiler that B and C should share a single A subobject rather than each carrying their own. D then ends up with exactly one A inside it, reachable unambiguously through either path, which is the actual fix for the diamond problem.

The consequence is a change in who's responsible for constructing that shared A: normally each class initializes its own immediate base in its constructor's initializer list, but since B and C would both try to initialize the *same* A subobject, the language instead makes the *most-derived* class (D) directly responsible for initializing the virtual base. B's and C's own attempts to initialize A in their initializer lists are simply ignored when they're used as part of D's construction (they only take effect if B or C were themselves the most-derived class in some other context). So if D's constructor doesn't explicitly initialize A, A's default constructor runs, even if B or C tried to pass it arguments.

```cpp
struct A { A(int x) { /* ... */ } };
struct B : virtual A { B() : A(1) {} };      // ignored when D is most-derived
struct C : virtual A { C() : A(2) {} };      // ignored when D is most-derived
struct D : B, C { D() : A(3), B(), C() {} }; // D must initialize A itself — uses A(3)
```

Question 15

A generic numerical serialization function must only accept arithmetic scalar types and reject pointers and complex objects. Compare implementing this constraint using legacy SFINAE with std::enable_if_t versus modern C++20 template requires std::is_arithmetic_v in terms of error diagnostics and compiler overhead.

Accepted Answer

SFINAE ('Substitution Failure Is Not An Error') works by making the constraint part of the function's type signature in a way that either substitutes cleanly or silently fails, removing that overload from consideration rather than producing a hard error — `std::enable_if_t, int> = 0` as an extra defaulted template parameter is the classic idiom: for a non-arithmetic T, enable_if_t has no ::type member, substitution fails, and the overload just vanishes from the candidate set as if it were never written. The practical problems with this are twofold. First, diagnostics are bad: when no overload matches, the compiler typically reports 'no matching function' along with a wall of every overload it *tried and rejected*, each with its own nested substitution-failure explanation buried in template-instantiation backtraces — genuinely hard to read, especially once enable_if is stacked with other SFINAE tricks. Second, compile-time cost: for every call, the compiler has to attempt substitution across every SFINAE-guarded overload to see which ones survive, which scales with however many overloads and however deep the type traits are. C++20 concepts express the same constraint directly and declaratively: `template requires std::is_arithmetic_v void serialize(T value)` (or, more idiomatically, wrapping the trait in a named concept). When T doesn't satisfy the constraint, the compiler can point at the exact requires-clause that failed and say so plainly, instead of a substitution-failure cascade — and because it's a first-class language construct rather than a type-system trick being repurposed, the compiler can typically check it more directly without instantiating unrelated overload machinery. ```cpp // SFINAE template, int> = 0> void serialize(T value) { /* ... */ } // C++20 concepts — same constraint, clearer error, simpler code template requires std::is_arithmetic_v void serialize(T value) { /* ... */ } ```

Question 16

An application compiled with -fsanitize=address crashes on a customer payload with an AddressSanitizer report displaying heap-buffer-overflow on address 0x602000000018. How do you read ASan shadow byte maps and call stacks to isolate an off-by-one write in a custom buffer serializer?

Accepted Answer

AddressSanitizer works by surrounding every heap allocation with 'redzones' — extra bytes it poisons (marks as invalid) that a correct program should never touch. It tracks this poisoning in a separate shadow memory region, where each byte of shadow memory represents 8 bytes of real memory and encodes how much of that 8-byte chunk is currently valid to access. When your program reads or writes into a poisoned redzone byte, ASan intercepts it immediately (via compiler-inserted checks) and aborts with a report, rather than letting the corruption silently happen and crash somewhere unrelated later.

The report gives you three key things: the faulting address (0x602000000018 here), whether it was a read or write and of what size, and — most useful for debugging — two call stacks: one showing exactly where the offending access happened, and one showing where the allocation that owns (or used to own) that memory was made. For an off-by-one in a serializer, the access stack usually points straight at the write loop, e.g. a `buf[i] = byte;` where the loop condition should be `i < size` but is `i <= size`, or a length calculation that's off by one element.

The shadow byte dump underneath the stacks shows the memory layout around the faulting address: bytes marked as 'heap left/right redzone' bracket the actual allocated region, so seeing the fault land exactly one byte past the 'redzone' boundary on the right side is the direct fingerprint of a classic one-past-the-end overflow, confirming the loop bound is off by one before you even look at the code closely. Cross-referencing that offset against the allocation size in the 'allocated here' stack trace tells you precisely how far past the buffer the write landed, which usually maps directly onto a single wrong comparison operator or size computation in the serializer.

Question 17

ThreadSanitizer (TSan) reports a data race where Thread 1 performs a write to a boolean flag is_ready while Thread 2 performs a read. Why does a standard non-atomic bool cause undefined behavior even on x86 architectures, and how do you confirm the fix using std::atomic<bool>?

Accepted Answer

It's tempting to think a plain bool is 'basically atomic' on x86 because a single-byte write is hardware-atomic at the instruction level — but the data race here isn't primarily a hardware problem, it's a compiler and memory-model problem. The C++ standard defines a data race as undefined behavior the moment two threads access the same non-atomic object without synchronization and at least one is a write, full stop, independent of what any particular CPU's instruction set can physically do. That UB gives the compiler license to do things you wouldn't expect: it can cache is_ready's value in a register across loop iterations (so a spin-wait `while (!is_ready) {}` on Thread 2 might never observe Thread 1's write at all, looping forever), reorder the read/write relative to surrounding code, or make other optimizations that assume no other thread is concurrently touching that memory.

So the bug can manifest as an infinite spin-loop, a stale read, or (in optimized builds) something that appears to work fine in debug and breaks only with optimizations on — all valid outcomes of undefined behavior, which is exactly why relying on 'x86 has strong memory ordering' doesn't save you: the compiler-level reordering/caching happens independent of the CPU's actual memory model guarantees.

ThreadSanitizer instruments every memory access and lock/unlock/atomic operation at compile time and builds a happens-before graph at runtime; when it sees two accesses to the same memory location from different threads with no happens-before edge between them and at least one is a write, it reports the race with both threads' stack traces — this is what caught the is_ready case here.

The fix is std::atomic<bool> is_ready — this gives well-defined semantics (no UB) for the concurrent access and, with the default memory_order_seq_cst, also creates the necessary happens-before relationship between the write and the read. Re-running the exact same test under TSan afterward and seeing no race reported is the standard way to confirm the fix, since the race being gone is easy to observe under a sanitizer even though it might not have reproduced reliably as a bug in normal runs.

Question 18

A production binary compiled with optimizations (-O2 -g) crashes with SIGSEGV, leaving a core dump. How do you load the core dump in GDB, switch between thread frames (thread apply all bt), inspect optimized-out register values, and print disassembly around the faulting instruction pointer (rip)?

Accepted Answer

You load the crash with `gdb ./binary core.` (or `gdb ./binary -c core` on some systems). The first thing worth running is `bt` (backtrace) on the crashing thread to get an immediate stack trace at the point of the fault, and `thread apply all bt` to dump backtraces for every thread in the process at once — essential for a multithreaded server crash where the thread that happened to segfault might just be the victim of memory corruption caused earlier by a different thread. With -O2, the -g debug info still gives you line numbers and variable names, but many local variables and even whole function calls get optimized away, inlined, or kept only in registers rather than stack slots — `print someVar` will often report `` because the compiler decided that variable's value was never needed in memory at that point. `info registers` shows you the raw register state at the crash (including rip, the instruction pointer, and rsp/rbp), which is often the only ground truth available when the higher-level variable is gone. `frame N` switches your current inspection context to a specific stack frame from the backtrace, letting you `print` and `info locals` relative to that frame. When the crash itself is confusing (e.g. it's inside a system call or a spot with no useful symbol), disassembling around the fault helps: `disassemble` with no args shows the current function's assembly with an arrow at the current rip; `x/10i $rip-20` (examine as instructions) dumps a window of raw instructions straddling the faulting address, which is often necessary to identify things like a bad dereference of a specific register that a stripped-down optimized function no longer names clearly. Cross-referencing the faulting instruction's operand register against `info registers`' recorded value for it (e.g. seeing rax = 0x0 right before a `mov (%rax),%rbx`) is frequently how you pin a SIGSEGV down to a specific null-pointer dereference even when the surrounding variable names have been optimized away.

Question 19

A long-running daemon does not have explicit memory leaks, but its heap footprint continuously expands over 48 hours. How do you use Valgrind's Massif tool to capture heap allocation snapshots, run ms_print to generate memory tree graphs, and identify the container retaining dead allocations?

Accepted Answer

'No explicit leaks' usually means a tool like Valgrind's Memcheck (or ASan's leak detector) found nothing, because every allocated block is still technically reachable from some live pointer somewhere — the classic case is a container (a cache, a map, a queue) that keeps growing because entries are added but never evicted or removed, even though nothing has 'lost' the pointer to any of them. That's not a leak in the classic sense, but the effect on the process's memory footprint is identical: unbounded growth over time. Massif is built for exactly this: `valgrind --tool=massif ./daemon` runs the program under heap-profiling instrumentation and periodically takes snapshots of the entire heap's contents, recording how much memory is allocated and, crucially, the call stack responsible for each allocation at that point in time. It writes this out to a massif.out. file as the program runs (or on exit/on a signal for a long-running daemon you need to interrupt deliberately). `ms_print massif.out.` renders that data as a text-based graph of heap usage over time, plus a breakdown at the peak (or at whichever snapshot you're inspecting) of exactly which call stacks are responsible for how much retained memory, as a tree you can drill into. For the daemon scenario, you'd look at how the top contributors' allocation sizes change across snapshots taken hours apart — a genuine leak or unbounded cache shows a call stack (e.g., inside a specific `Cache::insert` or `EventLog::append`) whose retained bytes keep climbing snapshot after snapshot, rather than staying flat, which pinpoints exactly which container and which code path is responsible without you having to manually correlate object counts by hand. From there the fix is usually adding an eviction policy (LRU/TTL/max-size bound) to that specific container rather than anything Massif does for you automatically.

Question 20

A custom hash table implementation is performing 3x slower than expected. How do you use Linux perf stat and perf record to measure L1-dcache misses, LLC (Last Level Cache) load misses, and branch mispredictions, and how would you restructure node arrays to improve cache locality?

Accepted Answer

`perf stat -e L1-dcache-load-misses,LLC-load-misses,branch-misses ./hashtable_bench` runs the program and, at the end, prints aggregate counts for exactly those hardware performance-counter events across the whole run, alongside the normal timing — this immediately tells you *whether* the slowdown looks memory-bound (high cache-miss rates relative to total memory accesses) versus something else like branch mispredicts from unpredictable control flow, without you having to guess.

For a hash table specifically, a high L1-dcache-miss and especially LLC-load-miss rate is a strong signal of pointer-chasing: a chained hash table where each bucket holds a linked list of individually heap-allocated nodes scatters those nodes across memory in essentially random locations (wherever the allocator happened to place each one), so walking a bucket's chain means following a pointer to an unpredictable address, which the CPU can't prefetch ahead of time — each hop is a likely cache miss, and misses that go all the way to LLC/main memory cost on the order of 100+ cycles each, easily dominating total runtime for a workload otherwise doing very little computation per lookup.

`perf record -g ./hashtable_bench` followed by `perf report` (or `perf report -g` for the call-graph view) attributes those cache-miss samples to specific functions and, with `-g`, specific call paths — for a hash table this typically lights up the bucket-traversal loop specifically, confirming the theory rather than just guessing from the aggregate perf stat numbers.

The restructuring fix is to trade pointer-chasing for contiguity: replace per-node heap allocations with open addressing (all entries live directly in one contiguous array, probing to the next slot on collision) or, if chaining is kept, store each bucket's entries in a small contiguous array/inline small-buffer rather than a linked list of separately-allocated nodes. Either way, a lookup then walks through memory sequentially or with a small number of nearby jumps instead of following scattered pointers, which lets the hardware prefetcher actually help and collapses most of those cache misses.

Question 21

What is the difference between a pointer and a reference in C++, and when would you use each?

Accepted Answer

A pointer is a variable that stores a memory address; it can be reassigned to point at something else after it's created, can be set to nullptr to represent 'points at nothing', supports pointer arithmetic, and needs to be explicitly dereferenced with * to access the value it points to. A reference is an alias for an existing object: it must be bound to something at the moment it's declared, can never be rebound to refer to something else afterward, cannot be null (a reference is always assumed to refer to a valid object), and is used with normal syntax, no dereference operator needed.

In practice, references are preferred for function parameters where you want to modify the caller's argument or avoid a copy without giving the function the option to reseat what it's referring to or accept 'no value' — `void scale(Vector3D& v)`. Pointers are preferred when 'no value' is a legitimate state you need to represent, when the thing being pointed to might need to change over the pointer's lifetime, or when you're doing manual memory management or working with C APIs.

```cpp
void incByRef(int& x) { x++; }      // must pass an actual int, can't be null
void incByPtr(int* x) { if (x) (*x)++; } // caller can pass nullptr, must check

int a = 5;
incByRef(a);        // a becomes 6
incByPtr(&a);        // a becomes 7
incByPtr(nullptr);   // safe — the null check handles it
```

Question 22

What does const correctness mean in C++, and what's the difference between a const pointer and a pointer to const?

Accepted Answer

Const correctness means using the const keyword throughout your code so the compiler enforces, at compile time, which values are and aren't allowed to change — a const parameter promises callers you won't modify their argument, and a const member function promises callers of that method that it won't modify the object's observable state (letting it be called on const objects and const references, and signaling intent to anyone reading the code).

The classic confusion is where const sits relative to the *. `const int* p` (equivalently `int const* p`) is a pointer to a const int — you can reassign p to point somewhere else, but you can't modify the int through p. `int* const p` is a const pointer to a (mutable) int — you can modify the int through p, but you can never make p point anywhere else after initialization. `const int* const p` combines both restrictions.

A const member function that legitimately needs to modify one specific field (e.g. a cache or a mutex used purely for internal bookkeeping, not part of the object's logical state) can mark that field mutable, which is the sanctioned escape hatch rather than casting away constness.

```cpp
void printLen(const std::string& s) { std::cout << s.length(); } // s guaranteed unmodified

class Cache {
    mutable std::optional<int> cached_; // allowed to change even in a const method
public:
    int get() const { if (!cached_) cached_ = computeExpensive(); return *cached_; }
};
```

Question 23

What's the difference between function overloading and function overriding in C++?

Accepted Answer

Overloading is having multiple functions with the *same name* but *different parameter lists* (different types, count, or const-ness) in the same scope — the compiler picks which one to call at compile time based on the argument types you pass, purely from static analysis of the call site. It has nothing to do with inheritance or polymorphism; a class can overload a method, or you can overload free functions.

Overriding is specific to inheritance: a derived class redefines a *virtual* function from its base class using the *exact same signature* (same parameters, same const-ness, covariant return types allowed). Unlike overloading, which is resolved at compile time, overriding is resolved at runtime via the object's actual dynamic type (through the vtable) — calling a virtual function through a Base* or Base& invokes whichever override matches the object's real, dynamic class, not the static type of the pointer/reference.

```cpp
struct Printer {
    void print(int x) { std::cout << x; }        // overload 1
    void print(const std::string& s) { std::cout << s; } // overload 2 (compile-time choice)
};

struct Base { virtual void speak() { std::cout << "Base"; } };
struct Derived : Base { void speak() override { std::cout << "Derived"; } }; // override (runtime choice)

Base* b = new Derived();
b->speak(); // prints "Derived" — resolved at runtime via vtable
```

Question 24

What are pure virtual functions and abstract classes, and why would you use them?

Accepted Answer

A pure virtual function is declared with `= 0` instead of a body (though it may optionally still have a body defined elsewhere, callable only via explicit base-class qualification): `virtual void draw() = 0;`. A class with at least one pure virtual function becomes an abstract class — you cannot instantiate it directly (`Shape s;` fails to compile), and any concrete class that wants to be instantiated must derive from it and provide an override for every pure virtual function it declares. This is how you express an interface or contract in C++: the abstract base class defines *what* operations exist without saying *how* they're implemented, and every concrete subtype is forced, by the compiler, to supply its own implementation. Code that only needs to work through the interface — say, a rendering loop that draws a list of shapes — can be written entirely in terms of the abstract base's pointer/reference type and polymorphically call into whatever concrete shape each element actually is, without knowing or caring about the concrete types at all. ```cpp class Shape { public: virtual void draw() const = 0; virtual double area() const = 0; virtual ~Shape() = default; // virtual destructor — essential, see the vtable/slicing question }; class Circle : public Shape { double r_; public: explicit Circle(double r) : r_(r) {} void draw() const override { /* ... */ } double area() const override { return 3.14159 * r_ * r_; } }; // Shape s; // compile error — Shape is abstract std::vector> shapes; shapes.push_back(std::make_unique(2.0)); for (auto& s : shapes) s->draw(); // works through the interface, no knowledge of Circle needed ```

Question 25

What is the actual difference between struct and class in C++?

Accepted Answer

The only technical difference is the default access level: members and base classes of a struct default to public, while members and base classes of a class default to private. Everything else — the ability to have constructors, destructors, methods, virtual functions, inheritance, templates, access specifiers — works identically for both; struct and class are, aside from that one default, the exact same kind of type.

The distinction that matters is convention, not compiler enforcement: struct is idiomatically used for simple, mostly-public data aggregates with little or no behavior (a Point{x,y}, a config bundle), while class is used for types with real encapsulation, invariants, and behavior where you want most internals private by default. Following that convention makes code easier to read at a glance — seeing struct signals 'plain data, probably safe to poke at directly', while class signals 'there's likely internal state you shouldn't touch except through its methods'.

```cpp
struct Point { double x, y; };          // fields public by default — plain data

class BankAccount {
    double balance_ = 0; // private by default
public:
    void deposit(double amt) { balance_ += amt; }
    double balance() const { return balance_; }
};
```

Question 26

What are the trade-offs between std::vector, std::list, and std::deque, and when would you pick each?

Accepted Answer

std::vector stores elements contiguously in a single heap-allocated block, giving O(1) random access by index and the best cache locality of the three (elements are packed next to each other, so iterating is fast and prefetcher-friendly). Its weak point is insertion/removal anywhere except the end: inserting in the middle requires shifting every subsequent element (O(n)), and growing past capacity means reallocating and moving everything (amortized O(1) for push_back overall, but with occasional expensive spikes and, as covered elsewhere, iterator/pointer invalidation on reallocation).

std::list is a doubly-linked list: O(1) insertion and removal anywhere, given an iterator to the position, and no invalidation of other iterators/references when you insert or erase elsewhere in the list. The cost is no random access at all (indexing requires walking N nodes), and much worse cache locality since each node is a separate heap allocation potentially scattered across memory — this is the exact pointer-chasing problem discussed in the hash table cache-locality question.

std::deque (double-ended queue) is a compromise: internally a sequence of fixed-size contiguous chunks, giving O(1) push/pop at both the front and back (unlike vector, which is only O(1) amortized at the back) while still supporting random access by index, though indexing and iteration are somewhat slower than a plain vector due to the extra indirection between chunks.

As a default, reach for vector unless you specifically need frequent insertion/removal in the middle (favor list) or frequent push/pop at both ends (favor deque, e.g. implementing a sliding window or a queue).

Question 27

What is the difference between std::map and std::unordered_map, and how do you choose between them?

Accepted Answer

std::map is typically implemented as a balanced binary search tree (a red-black tree in most standard library implementations), which keeps its keys in sorted order at all times and gives O(log n) for insert, erase, and lookup. Because it's ordered, you get useful operations that a hash-based container can't offer efficiently, like iterating keys in sorted order, or finding the smallest key greater than some value (lower_bound/upper_bound). std::unordered_map is a hash table: no ordering guarantee at all (iteration order is implementation-defined and can even change after rehashing), but average-case O(1) for insert/erase/lookup, only degrading to O(n) worst case if there are heavy hash collisions (which a good hash function and load-factor management largely avoid in practice). It also requires the key type to be hashable (a std::hash specialization) and equality-comparable, whereas map only needs a strict weak ordering (operator< or a custom comparator). As a rule of thumb: pick unordered_map by default when you just need fast key-value lookups and don't care about order — it's usually noticeably faster for large collections. Pick map when you need sorted iteration, range queries (lower_bound/upper_bound), or a key type that's easy to order but awkward to hash well. ```cpp std::map sortedScores; // iterates alphabetically by key std::unordered_map fastScores; // faster average lookups, no ordering ```

Question 28

Explain exception handling in C++ — try/catch/throw, stack unwinding, and how RAII interacts with it.

Accepted Answer

You signal an error condition with `throw someException;`, wrap risky code in a `try` block, and handle specific exception types with one or more `catch` blocks that follow it, matched in order against the exception's type (catch by const reference is the idiomatic form, to avoid slicing a derived exception type down to its base). If no catch block in the current function matches, the exception propagates up to the caller, and so on, until a matching handler is found or the program terminates via std::terminate if none ever is.

As the exception propagates outward looking for a handler, every stack frame between the throw and the catch is unwound: all local objects in those frames are destroyed, in reverse order of construction, exactly as if the function had returned normally — this is 'stack unwinding'. This is precisely why RAII (Resource Acquisition Is Initialization) matters so much in exception-safe C++: if a resource's cleanup lives in a destructor (a lock_guard releasing a mutex, a unique_ptr freeing memory, a fstream closing a file), that cleanup happens automatically during unwinding, with no explicit code needed at each possible throw point. If instead you manage a resource manually (raw new/delete, manual lock()/unlock()), an exception thrown between acquisition and manual release skips the release entirely, leaking the resource or leaving a mutex locked forever.

```cpp
void process(const std::string& path) {
    std::ifstream file(path); // RAII: closed automatically even if an exception is thrown below
    if (!file) throw std::runtime_error("cannot open " + path);
    // ... use file ...
} // file's destructor runs here on normal return OR during unwinding — either way, closed

try {
    process("config.txt");
} catch (const std::exception& e) {
    std::cerr << "failed: " << e.what();
}
```

Question 29

What is the 'Rule of Zero', and how does it relate to the Rule of Five?

Accepted Answer

The Rule of Five says: if your class needs to define any one of the destructor, copy constructor, copy assignment, move constructor, or move assignment, it almost certainly needs to define all five, because the compiler's implicitly-generated versions of the others will likely do the wrong thing once you've taken manual control of resource management (this is exactly the socket-handle example covered elsewhere — writing a custom destructor without also fixing copy semantics leads to double-close bugs).

The Rule of Zero is the higher-leverage alternative: design your class so it *never has to write any of the five itself*, by ensuring every resource-owning member is already a well-behaved RAII type — a std::vector, std::string, std::unique_ptr, std::shared_ptr, etc. — rather than a raw pointer, raw handle, or raw array. When every member already correctly manages its own copy/move/destroy behavior, the compiler-generated (defaulted) special member functions for your class just call each member's corresponding special member function, which does exactly the right thing automatically, with zero code from you and zero chance of forgetting one of the five.

```cpp
// Rule of Five needed: raw pointer member, must hand-write all five special members
class BufferOwnerRaw { char* data_; size_t size_; /* ...5 special members... */ };

// Rule of Zero: delegate ownership to a member that already does RAII correctly
class BufferOwner { std::vector<char> data_; }; // compiler-generated ctor/dtor/copy/move all just work
```

The practical guidance is: reach for Rule of Zero by composing existing RAII types whenever possible, and only fall back to hand-writing the Rule of Five when your class itself is the thing directly wrapping a raw resource (like a socket handle) that has no existing RAII wrapper.

Question 30

What's the difference between std::unique_ptr, std::shared_ptr, and std::weak_ptr?

Accepted Answer

std::unique_ptr represents sole, exclusive ownership of a heap object: only one unique_ptr can own a given object at a time, so it's move-only (copying is disabled at compile time) — ownership can be transferred with std::move, but never duplicated. It has essentially zero overhead over a raw pointer (typically just wraps the pointer and, unless a custom deleter is supplied, adds nothing else), and automatically deletes the object when it goes out of scope. std::shared_ptr represents shared ownership: multiple shared_ptr instances can point to the same object, and a control block (allocated alongside or near the object) keeps an atomic reference count that increments on copy and decrements on destruction; the object is deleted only when the count reaches zero. This is more expensive than unique_ptr — the atomic increments/decrements have real cost under contention, and there's a control block allocation — so it should be used when you genuinely need shared ownership, not as a default 'safe pointer' choice. std::weak_ptr observes an object managed by shared_ptr without contributing to the reference count and therefore without keeping it alive — it's used to break reference cycles (as in the parent/child tree example elsewhere) or to check 'is this object still around?' without extending its lifetime. Since the object might have already been destroyed, you can never dereference a weak_ptr directly; you call .lock(), which returns either a valid shared_ptr (temporarily bumping the count while you use it) or an empty one if the object is gone. ```cpp auto u = std::make_unique(); // exclusive owner auto s1 = std::make_shared(); // shared, refcount = 1 auto s2 = s1; // refcount = 2 std::weak_ptr w = s1; // doesn't affect refcount if (auto locked = w.lock()) { /* use locked safely */ } ```

Question 31

What's the difference between new/delete and malloc/free in C++?

Accepted Answer

new and delete are C++ operators that combine memory allocation with object lifecycle: new allocates enough raw memory for the type and then invokes its constructor on that memory, returning a properly-typed pointer with no cast needed; delete calls the object's destructor first and then frees the memory. malloc and free, inherited from C, only deal with raw, untyped memory — malloc(n) hands back a void* to n uninitialized bytes with no constructor run, and free() just releases the bytes with no destructor run, so using them on a non-trivial C++ type (one with a real constructor/destructor, virtual functions, or members that need initialization) leaves the object improperly constructed or destructed.

new also integrates with the type system and error handling differently: on failure it throws std::bad_alloc by default (or you can opt into a non-throwing form with `new(std::nothrow)`), whereas malloc simply returns nullptr on failure and expects you to check it manually. new/delete can additionally be overloaded per-class (to plug in a custom allocator), which malloc/free have no equivalent hook for.

The hard rule is to never mix them: an object created with new must be destroyed with delete (never free — free won't call the destructor and doesn't know how new's allocator recorded the block size), and memory from malloc must be released with free, never delete. In modern C++ you should rarely call any of these directly anyway — prefer smart pointers and containers, which call new/delete for you correctly and automatically.

Question 32

What are lambda expressions in C++, and how do the different capture modes ([], [&], [=], and specific captures) behave?

Accepted Answer

A lambda is an anonymous, inline function object: `[captures](params) -> returnType { body }`. Under the hood the compiler generates a small class with operator() implementing the body, and the capture clause controls what state from the surrounding scope that generated class stores as members and how. `[]` captures nothing — the lambda can only use its own parameters and anything in global/static scope. `[&]` captures everything used from the enclosing scope by reference (so the lambda sees live updates to those variables, but is unsafe to use after those variables go out of scope, e.g. from an async callback outliving the enclosing function). `[=]` captures everything used by value (a snapshot taken at lambda-creation time, safe to outlive the original scope but means later changes to the original variables aren't seen). You can also name specific variables to control per-variable capture mode explicitly, like `[&total, count]` (total by reference, count by value), which is generally preferable to the blanket `[&]`/`[=]` forms for readability and to avoid accidentally capturing more than intended. By default, a lambda's operator() is const, meaning value-captured variables can't be modified inside the lambda body; adding the `mutable` keyword lifts that restriction (though it only affects the lambda's own internal copy — it never propagates back to the original variable, since that copy was captured by value in the first place). ```cpp int threshold = 10; std::vector v = {3, 15, 7, 20}; std::sort(v.begin(), v.end(), [](int a, int b) { return a < b; }); // no captures needed auto countAbove = std::count_if(v.begin(), v.end(), [threshold](int x) { return x > threshold; }); // capture by value ```

Question 33

How do you use std::thread with a mutex and std::lock_guard to safely share state between threads?

Accepted Answer

std::thread launches a callable on a new OS thread as soon as it's constructed; you must eventually call .join() (block until it finishes) or .detach() (let it run independently) on every std::thread object before it's destroyed, or the program calls std::terminate. Any data that multiple threads read and write concurrently without synchronization is a data race — undefined behavior, as covered in the TSan/atomic bool question — so shared mutable state needs a mutex to serialize access: only one thread at a time is allowed to hold the lock and touch the protected data.

Manually calling mutex.lock() and mutex.unlock() is risky because any early return, thrown exception, or added code path between them can skip the unlock, leaving the mutex locked forever and deadlocking every other thread that tries to acquire it. std::lock_guard is the RAII wrapper for this: its constructor locks the mutex, its destructor unlocks it, so the unlock happens automatically and unconditionally when the lock_guard goes out of scope — including during exception-driven stack unwinding — exactly the same pattern as a smart pointer freeing memory.

```cpp
std::mutex m;
int counter = 0;

void worker() {
    for (int i = 0; i < 100000; ++i) {
        std::lock_guard<std::mutex> lock(m); // locked here
        counter++;
    } // unlocked here automatically, every iteration
}

std::thread t1(worker), t2(worker);
t1.join(); t2.join();
std::cout << counter; // deterministically 200000, no race
```

Question 34

What causes a deadlock when using multiple mutexes, and how do std::lock and std::scoped_lock help avoid it?

Accepted Answer

The classic deadlock scenario ('AB-BA deadlock') happens when two threads need to hold two locks at once but acquire them in opposite order: Thread 1 locks mutex A then tries to lock mutex B, while Thread 2 has already locked mutex B and is trying to lock mutex A. Neither thread can proceed — each is holding the lock the other one needs — and both wait forever.

One fix is discipline: always acquire multiple locks in the same global order everywhere in the codebase, so this circular-wait condition can never arise. But that requires every call site to agree on an ordering and get it right, which is fragile as a codebase grows.

The more robust fix is to acquire both locks together, atomically, using std::lock(m1, m2) (which uses a deadlock-avoidance algorithm internally to acquire both without risking this interleaving) or, more idiomatically in modern C++, std::scoped_lock (C++17), which does the same thing with RAII cleanup — locking multiple mutexes safely as one operation and unlocking all of them automatically when it goes out of scope.

```cpp
std::mutex mA, mB;

void transfer() {
    std::scoped_lock lock(mA, mB); // acquires both, in a deadlock-safe way, regardless of order elsewhere
    // ... critical section touching resources guarded by both ...
} // both unlocked automatically
```

Question 35

What is a dangling pointer or dangling reference, and how can it arise?

Accepted Answer

A dangling pointer or reference is one that still holds an address (or refers to a location) whose underlying object's lifetime has already ended — the memory may have been freed, reused for something else, or is otherwise no longer valid, but the pointer/reference itself doesn't know that and looks exactly like a valid one. Dereferencing it is undefined behavior: it might crash immediately, silently read garbage, or (worst case) appear to work by luck until the memory happens to get reused.

Common ways it arises: returning a reference or pointer to a local (stack) variable from a function — the local is destroyed the moment the function returns, so the caller is left holding a reference to a stack frame that no longer exists; freeing/deleting an object while another pointer to it is still stored somewhere and later used; and, as covered in the vector reallocation question, taking a pointer into a container's element and then triggering a reallocation that moves everything to new memory.

```cpp
int& badRef() {
    int local = 42;
    return local; // returning a reference to a local — dangling the instant the function returns
}

int* p;
{
    int x = 10;
    p = &x;
} // x's scope ends here, its storage is no longer valid
// *p here is undefined behavior — p is now dangling
```

Question 36

What's the difference between a shallow copy and a deep copy in C++, and why does it matter for classes managing raw pointers?

Accepted Answer

A shallow copy copies a class's members exactly as they are stored — if a member is a raw pointer, the copy gets a pointer to the *same* pointed-to memory as the original, not a new independent copy of the data. This is exactly what the compiler's default (implicitly-generated) copy constructor and copy assignment do, since they perform a member-wise copy with no special handling for what a raw pointer conceptually 'owns'.

For a class that owns heap memory through a raw pointer, this is dangerous: once you have two objects both holding a pointer to the same buffer, whichever one is destroyed first frees that memory, and the other object is left holding a dangling pointer — using it afterward is undefined behavior, and if both objects' destructors run (e.g. at the end of a scope), you get a double-free, which typically corrupts the heap allocator's internal bookkeeping.

A deep copy instead allocates a brand-new block of memory in the copy and copies the *contents* the original pointer refers to, so the two objects end up with entirely independent ownership — each can be destroyed safely without affecting the other. This has to be done explicitly, by writing your own copy constructor/assignment (or, per the Rule of Zero question, by avoiding raw pointers entirely in favor of a container/smart pointer that already implements deep-copy or move semantics correctly).

```cpp
class Buffer {
    int* data_; size_t size_;
public:
    Buffer(size_t n) : data_(new int[n]), size_(n) {}
    ~Buffer() { delete[] data_; }
    // without this, the compiler-generated copy ctor does a shallow copy -> double free
    Buffer(const Buffer& o) : data_(new int[o.size_]), size_(o.size_) {
        std::copy(o.data_, o.data_ + size_, data_); // deep copy
    }
};
```

Question 37

How do function templates and class templates work in C++, and what's the difference between them?

Accepted Answer

A function template is a blueprint the compiler uses to generate an actual, concrete function for each distinct set of types it's called with — write `max` once, and calling it with ints generates a genuine `max(int, int)` function at compile time, calling it with doubles generates a separate `max(double, double)`, and so on. Type deduction usually means you don't even have to specify T explicitly; the compiler infers it from the arguments you pass. A class template is the same idea applied to a whole type: `std::vector` isn't a real type until instantiated with a concrete T — `std::vector` and `std::vector` are genuinely different, unrelated types generated from the same template definition, each with its own compiled member functions specific to that T. Both are resolved entirely at compile time (this is why templates, unlike virtual functions, add no runtime dispatch overhead — the compiler already knows exactly which concrete function/type is being used at each call site), at the cost of longer compile times and, historically, harder-to-read error messages when something goes wrong deep inside a template instantiation (an issue C++20 concepts specifically improve, as covered elsewhere). ```cpp template T maxOf(T a, T b) { return a > b ? a : b; } // one definition, many generated instantiations template class Box { T value; public: explicit Box(T v) : value(v) {} T get() const { return value; } }; auto m = maxOf(3, 7); // instantiates maxOf Box b("hello"); // instantiates Box ```

Question 38

What's the difference between static_cast, dynamic_cast, const_cast, and reinterpret_cast?

Accepted Answer

static_cast performs conversions that are well-defined and checkable at compile time: numeric conversions (int to double), pointer conversions up or down a class hierarchy *without* a runtime safety check (so downcasting with static_cast is only safe if you already know, some other way, that the object really is the derived type), and explicit calls to single-argument constructors/conversion operators. It's the everyday, 'I know this conversion is valid' cast. dynamic_cast is specifically for safe downcasting in a polymorphic hierarchy (the class must have at least one virtual function, since it relies on RTTI attached via the vtable): it checks at runtime whether the object's actual dynamic type really supports the target type, returning nullptr for a failed pointer cast, or throwing std::bad_cast for a failed reference cast, rather than silently producing an invalid pointer the way static_cast would. const_cast only adds or removes const/volatile qualification — it can't change the underlying type otherwise. Using it to call a legacy non-const API on data you know is genuinely non-const is fine; using it to remove const from something that was originally declared const and then modifying it is undefined behavior. reinterpret_cast reinterprets the raw bits of one pointer/integral type as another, unrelated type, with no safety checks and no actual conversion logic run — it's the most dangerous of the four, easily leading to the exact strict-aliasing undefined behavior covered in the network-packet-parsing question, and should be reached for only rarely, for low-level bit-level work. ```cpp double d = 3.14; int i = static_cast(d); // well-defined numeric conversion Base* b = new Derived(); Derived* dp = dynamic_cast(b); // checked downcast, nullptr if wrong void legacyApi(char* s); const char* cs = "x"; legacyApi(const_cast(cs)); // strip const for a C API uint32_t bits = reinterpret_cast(someFloat); // reinterpret raw bits — dangerous, aliasing risk ```

Question 39

What's the difference between std::string and a C-style string (const char*)?

Accepted Answer

std::string owns and manages its own dynamically resizable character buffer: it tracks its length internally so `.size()`/`.length()` is O(1) (no scanning required), grows and shrinks automatically as you append/erase, cleans up its own memory via RAII (no manual free needed), supports natural operators (`+` to concatenate, `==` to compare), and offers bounds-checked access via `.at()` in addition to unchecked `operator[]`.

A C-style string is just a raw pointer to a contiguous, null-terminated (`\0`-terminated) sequence of characters — there's no length stored anywhere, so getting the length means calling strlen(), which scans the whole string, O(n) every time you need it. Any memory management (allocating the buffer, freeing it) is entirely manual, and common C string functions like strcpy have no built-in bounds checking, which is exactly the class of bug (buffer overflows) that ASan/heap-buffer-overflow reports typically catch.

std::string bridges to C APIs that expect a const char* via the `.c_str()` method, which returns a pointer to a null-terminated view of the string's contents — useful when calling into legacy or system APIs while keeping std::string as your primary representation everywhere else in modern C++ code.

```cpp
std::string s = "hello";
s += ", world";              // automatic growth, no manual buffer management
const char* cstr = s.c_str(); // bridge to a C API expecting const char*
printf("%s
", cstr);
```

Question 40

What is the difference between stack and heap memory allocation in C++?

Accepted Answer

Stack memory is allocated automatically for local variables and function parameters, in a fixed region reserved per thread, and is managed by simply moving a stack pointer up on function entry and back down on return — it's extremely fast (no bookkeeping, no allocator call) and its lifetime is tied strictly to scope: a stack-allocated object is destroyed automatically the instant its enclosing scope ends. The downside is size: the stack is a fixed, relatively small region (often a few MB per thread), so very large local arrays or deep/unbounded recursion can exhaust it, causing a stack overflow crash.

Heap memory is allocated on demand via new/malloc (or, idiomatically, through containers and smart pointers that call these internally), from a much larger pool the OS manages, and its lifetime is controlled by the program, not by scope — an object can be created in one function and remain alive long after that function returns, as long as something still holds a pointer/reference to it. The cost is that allocation and deallocation are genuinely more expensive operations (allocator bookkeeping, potential locking, potential fragmentation over time), and unlike the stack, nothing frees heap memory automatically unless you use RAII (smart pointers, containers) to tie its lifetime back to some scope indirectly.

```cpp
void demo() {
    int stackArr[100];                  // stack: fast, freed automatically at end of demo()
    int* heapArr = new int[100];        // heap: slower to allocate, must be explicitly deleted
    delete[] heapArr;
} // stackArr's memory is reclaimed here automatically; heapArr would leak if delete[] were forgotten
```

Question 41

What is copy elision / Return Value Optimization (RVO), and why is it mandatory in some cases since C++17?

Accepted Answer

When a function returns a local object by value, the naive mental model says: construct the local, then copy (or move) it into the caller's destination. Copy elision is the optimization where the compiler instead constructs the object *directly in the caller's storage* from the start, skipping the intermediate copy/move entirely — the local variable and the caller's result are literally the same memory, not two separate objects with one copied into the other.

Before C++17, this was permitted but not guaranteed — compilers had long done it in practice for the simple 'return a temporary' case (a prvalue), but it was technically an optional optimization, and the standard even carved out a specific exception allowing it *even when the copy/move constructor had observable side effects* (like printing something), which was already a strong hint about how essential compilers considered it.

C++17 changed this for one specific case: when returning a prvalue directly, like `return Widget(args);` or `return makeWidget();`, elision is now *mandatory* by the language rules — there's no temporary object being copied or moved at all, conceptually, so the type doesn't even need an accessible copy or move constructor for this to compile. This is called 'mandatory copy elision' and applies to prvalues specifically.

Returning a *named* local variable, however (`Widget w; ... return w;`), is Named RVO (NRVO), which remains an optional, quality-of-implementation optimization, not guaranteed by the standard — most modern compilers do apply it in straightforward cases, but the type must still have an accessible copy or move constructor in case the compiler doesn't manage to elide it (e.g. across different return paths returning different named locals).

```cpp
struct Widget { Widget() { std::cout << "ctor
"; } Widget(const Widget&) { std::cout << "copy
"; } };

Widget makeWidget() { return Widget(); } // C++17: guaranteed elision — prints only "ctor", never "copy"
auto w = makeWidget(); // constructed directly into w's storage, no copy/move actually happens
```

Question 42

What is Empty Base Optimization (EBO) in C++, and why do standard library types rely on it?

Accepted Answer

An empty class (one with no non-static data members) still has a nonzero size when instantiated standalone — typically 1 byte — because the language requires that no two distinct objects have the same address, and a zero-sized object couldn't guarantee that. But when that same empty class is used *as a base class* of another class, the compiler is allowed to overlap its (empty) storage with the derived class's other members, giving it an effective offset/footprint of zero within the derived object, as long as doing so doesn't violate the distinct-address rule (e.g. it can't overlap with another empty base of the identical type sitting at the same level). This is Empty Base Optimization.

This matters a lot in the standard library because generic containers and smart pointers often carry a stateless policy object alongside their real data — think std::vector's allocator, or std::unique_ptr's deleter. If that allocator/deleter/comparator has no actual state (which the vast majority of default ones don't), storing it as a plain data member would waste at least one word (often padded further) per container instance for genuinely nothing. By instead having the container privately inherit from the policy type rather than holding it as a member, EBO lets that stateless policy occupy zero extra bytes, so a std::unique_ptr<T> with a stateless default deleter is exactly the size of a raw pointer, not a pointer plus a wasted deleter slot.

```cpp
struct Empty {};
struct WithMember { Empty e; int x; };      // typically 8 bytes (padding for the empty member + int)
struct WithBase : Empty { int x; };          // typically 4 bytes — EBO lets Empty add nothing
static_assert(sizeof(WithBase) < sizeof(WithMember));
```

Question 43

What is Argument-Dependent Lookup (ADL, or 'Koenig lookup'), and how can it cause surprising overload resolution?

Accepted Answer

Normally, when you call an unqualified function like foo(x), the compiler looks for foo in the current scope and any enclosing scopes, following ordinary name-lookup rules. ADL adds an extra step specifically for function calls: the compiler *also* searches the namespaces associated with the types of the arguments — so calling foo(x) where x is of type ns::Widget also searches namespace ns for a matching foo, even if you never wrote `using namespace ns;` or otherwise brought that name into scope.

This is precisely what makes the standard 'swap idiom' work: generic code that wants to swap two values of an unknown type T is written as `using std::swap; swap(a, b);` (not `std::swap(a, b);` directly) specifically so that, if T is a user type with its own more efficient swap defined in T's own namespace, ADL finds and prefers that custom swap over the generic std::swap fallback — without the generic code needing to know T's namespace at all.

The surprising side is that ADL can pull in a function you never intended to call, purely because one of your argument's types happens to live in a namespace that also defines a same-named, plausible-looking overload — this has historically caused subtle bugs and 'why did it call *that* function' confusion, especially with operator overloads (operator<< and operator== are found via ADL just as often as named functions are), which is part of why some style guides recommend being deliberate about which functions you define in which namespaces for types meant to be used generically.

```cpp
namespace geo {
    struct Point { int x, y; };
    void swap(Point& a, Point& b) { std::swap(a.x, b.x); std::swap(a.y, b.y); } // custom, found via ADL
}

template<typename T> void genericSwap(T& a, T& b) {
    using std::swap;
    swap(a, b); // ADL finds geo::swap for geo::Point, falls back to std::swap otherwise
}
```

Question 44

What is the One Definition Rule (ODR), and how can violating it produce silent bugs instead of a compile or link error?

Accepted Answer

The One Definition Rule requires that every non-inline function, non-inline global variable, and class/type have exactly one definition across the entire program (across all translation units combined) — inline functions, templates, and types are allowed to be defined identically in multiple translation units (typically because they're defined in a header included everywhere), but critically, the standard requires those repeated definitions to be *token-for-token identical*.

A violation happens when two translation units end up compiling *different* definitions of what's supposed to be 'the same' type or inline function — a common real-world cause is a header whose content changes based on a preprocessor macro (`#ifdef DEBUG_LAYOUT` adding an extra field to a struct, for example), where one .cpp file is compiled with that macro defined and another isn't, so each .cpp effectively sees a structurally different definition of the same class name.

The insidious part is that this frequently compiles and links completely cleanly: the linker generally doesn't (and, for inline/template definitions, largely can't) verify that every translation unit's copy of a given definition actually matches byte-for-byte — it just picks one definition (often just whichever it saw first) to use for every call site, even from translation units that were compiled against a different layout. The result is that some code paths access a struct using field offsets computed for the *wrong* layout, silently reading garbage or corrupting adjacent memory, with no compiler warning and no linker error pointing at the actual root cause — the bug can look entirely unrelated to the header/macro that's actually causing it, and can be maddening to track down without specifically suspecting an ODR violation.

The defense is largely discipline: never let a shared header's type definitions change shape based on which translation unit happens to define a macro first, and make sure every .cpp file that includes a shared header is built with identical relevant preprocessor definitions.

Question 45

What is Small String Optimization (SSO), and how does it let std::string avoid heap allocation for short strings?

Accepted Answer

Naively, you'd expect every std::string, no matter how short, to heap-allocate a buffer for its characters — but that would mean even a two-character string like "ok" costs a full malloc call and the deallocation/bookkeeping overhead that goes with it, which is wasteful for the extremely common case of short strings (variable names, small labels, short keys). Small String Optimization avoids this: most standard library implementations store short strings' character data directly *inside* the std::string object itself, in a small fixed-size buffer that's part of the object's own memory (often reusing space that would otherwise be needed for the heap pointer/capacity fields), rather than pointing off to a separately allocated heap block.

The exact inline-capacity threshold is implementation-defined — commonly somewhere around 15 to 22 characters depending on the standard library implementation and pointer size (libstdc++, libc++, and MSVC's implementation all differ slightly here) — but the general shape is the same across all of them: as long as a string's length stays within that inline capacity, constructing, copying, and destroying it involves no heap allocation at all, just ordinary memory copies within the object. The moment a string grows past that threshold (via append, concatenation, or being constructed with a longer literal), the implementation transparently switches over to heap-allocating a buffer, exactly as the naive model would expect, and all the usual std::string operations keep working identically either way — SSO is purely an internal implementation detail, invisible from the public API surface.

This is one reason short std::string usage (short-lived local strings, map/set keys that are short identifiers) tends to be much cheaper in practice than intuition based on 'strings always heap-allocate' would suggest, and it's part of why passing std::string by value for short strings often isn't nearly as costly as people assume.

Question 46

What's the difference between std::variant and a raw union, and how does std::visit work with it?

Accepted Answer

A raw union stores all its member types in the same overlapping memory, but it has no idea which member is 'currently active' — that's entirely on the programmer to track separately (often via a manually-maintained tag/enum alongside it), and accessing a member other than the one that was last written is undefined behavior in the general case (with narrow, specific exceptions the standard carves out for certain layout-compatible cases). Unions also can't cleanly hold non-trivial types (ones with real constructors/destructors) without the programmer manually calling placement-new and explicitly invoking the right destructor before switching which member is active — the compiler won't do any of that bookkeeping for you. std::variant is a type-safe tagged union: it always knows, at runtime, which one of its alternative types is currently held, correctly runs constructors/destructors as the active type changes, and will throw std::bad_variant_access if you try to access the wrong alternative through the type-checked accessors — there's no way to accidentally read the wrong type's bit pattern the way a raw union permits. Because you generally don't know which alternative is active at compile time, you don't write a normal if/else chain against it — std::visit(callable, variant) instead dispatches to whichever overload of the callable matches the currently-active type, at runtime, choosing the right code path for you. A common idiom is to hand it an 'overloaded lambda set' (a small helper struct combining several lambdas via inheritance) so each alternative type gets its own handling in one call. ```cpp std::variant v = "hello"; std::visit([](auto&& val) { using T = std::decay_t; if constexpr (std::is_same_v) std::cout << "int: " << val; else std::cout << "string: " << val; }, v); ```

Question 47

What is thread_local storage duration in C++, and what is it typically used for?

Accepted Answer

A variable declared thread_local gets a completely separate instance for every thread that touches it — each thread reads and writes its own private copy, with no sharing and therefore no data race, even though the code refers to it by one single name everywhere. For non-trivial types, each thread's instance is lazily constructed the first time that thread actually reaches the point where it's used (or at thread-start for simpler cases), and destroyed when that thread exits.

This is useful anywhere you want per-thread state without paying for synchronization or without threads stepping on each other's data: a classic example is a per-thread pseudo-random number generator, since std::mt19937 has internal mutable state that would either need a mutex to share safely across threads (killing parallelism) or would need to be re-seeded/recreated constantly if used as a plain local — a thread_local instance instead gets initialized once per thread and reused for the life of that thread with zero locking. Other common uses include a per-thread scratch buffer/arena, per-thread error-context state (similar in spirit to how C's errno is effectively thread-local in modern implementations), and per-thread caches to avoid contention on a shared cache.

```cpp
int nextRandom(int lo, int hi) {
    thread_local std::mt19937 rng(std::random_device{}()); // one instance per thread, initialized once each
    return std::uniform_int_distribution<int>(lo, hi)(rng);
}
```

Question 48

What is the difference between volatile and std::atomic in C++, and why is volatile not a substitute for atomics in multithreaded code?

Accepted Answer

volatile tells the compiler only one thing: don't optimize away or reorder reads/writes to this variable relative to *other volatile accesses* — every read must actually read from memory (not from a cached register value) and every write must actually write to memory, in the exact order they appear in the source. It exists for interacting with memory-mapped hardware registers or values a signal handler might change asynchronously, where you specifically need the compiler to not 'helpfully' assume the value can't have changed between accesses.

What volatile does *not* provide is atomicity (a volatile int can still be torn/partially written on some platforms/types) or any cross-thread memory ordering guarantee at all — it says nothing about how the *hardware* (as opposed to the compiler) may reorder or cache memory operations relative to other threads, and it establishes no happens-before relationship the way std::memory_order_acquire/release does. Using volatile bool as a 'ready flag' between threads is a genuinely common but incorrect pattern: it may happen to work on some platforms under some compiler versions by coincidence, but it's not a guarantee the standard makes, and it's exactly the kind of bug a tool like ThreadSanitizer would flag as a data race.

std::atomic<T> is the actual tool for this: it guarantees the operation is indivisible (no torn reads/writes) *and* lets you specify the memory ordering semantics needed to synchronize visibility of other memory operations between threads (as covered in the SPSC ring buffer and TSan questions). As a rule of thumb: volatile is for talking to hardware/signal handlers, std::atomic is for talking between threads — they solve genuinely different problems and one cannot substitute for the other.

Question 49

What is 'two-phase lookup' in C++ templates, and why do you sometimes need the typename and template disambiguator keywords for dependent names?

Accepted Answer

Templates are compiled in two distinct phases. Phase 1 happens at the point the template is *defined*: the compiler parses it and resolves every name that doesn't depend on the template parameters (non-dependent names) immediately, exactly as it would for ordinary non-template code. Phase 2 happens at the point the template is *instantiated* with actual concrete types: only then does the compiler resolve names that *do* depend on a template parameter (dependent names), because it can't know what those names actually refer to until it knows the real type being substituted in. This creates a genuine ambiguity the compiler can't resolve during phase 1: given something like `T::something`, the compiler has no way of knowing, without knowing what T actually is, whether `something` names a type, a static data member, or a member function template — and depending on which one it is, the surrounding syntax needs to be parsed completely differently (a type name used in an expression context needs different parsing rules than a value). C++ resolves this ambiguity by making you tell the compiler explicitly, at the point you write the dependent name: `typename T::something` tells it 'this is a type name, parse accordingly' (required whenever you use a dependent type name in most contexts, e.g. as a base for a variable declaration); and `obj.template someMethod()` tells it 'someMethod is a template, and the following < is the start of template arguments, not a less-than operator' — required whenever you call a dependent member function template with explicit template arguments. ```cpp template void foo(T obj) { typename T::value_type v; // without 'typename', ambiguous: type or value? obj.template convert(); // without 'template', '<' could parse as less-than } ```

Question 50

What is the C++20 spaceship operator (operator<=>), and how does defaulting it reduce boilerplate for comparable types?

Accepted Answer

Before C++20, giving a struct full comparison support meant hand-writing up to six separate operator overloads (==, !=, <, <=, >, >=), each usually doing essentially the same member-by-member comparison logic in slightly different forms — tedious to write and easy to get subtly inconsistent (e.g. forgetting to update operator< when a field is added, while operator== is updated correctly). operator<=> ('the spaceship operator') replaces most of that: it's a single three-way comparison operator that returns an ordering category type (std::strong_ordering, std::weak_ordering, or std::partial_ordering, depending on what the compared members support) representing whether the left side is less than, equal to, or greater than the right side. When you declare `auto operator<=>(const T&) const = default;`, the compiler automatically generates a member-wise three-way comparison (comparing members in declaration order, short-circuiting at the first non-equal member) and derives *all six* relational operators from that single definition — you get consistent <, <=, >, >=, ==, and != for free, always in sync with each other and with the struct's actual member list. ```cpp struct Version { int major, minor, patch; auto operator<=>(const Version&) const = default; // generates ==, !=, <, <=, >, >= automatically }; Version a{1, 2, 0}, b{1, 3, 0}; bool isOlder = a < b; // true — compares major, then minor, then patch, in order bool isEqual = a == b; // false ```

SDE (C++) Interview Questions & Answers

Ready to practice these live?