Answer. The defaults are the only difference. A struct has public members and public inheritance by default, while a class has private members and private inheritance by default.

Why. Both can have constructors, virtual functions, templates and access specifiers. Candidates often say "structs cannot have member functions", which is true in C and false in C++. Convention: use struct for passive data with no invariant, and class when you protect one.

Answer. const data members, reference members, members whose type has no default constructor, and base classes that need constructor arguments.

Why. By the time the body runs, every member already exists. A const or a reference cannot be assigned afterwards, and a type without a default constructor could not have been built in the first place. For everything else, the list is still preferred, because it constructs once instead of default-constructing and then assigning.

Answer. In two cases. It is not declared when you declare any constructor yourself, including a copy or move constructor. It is defined as deleted when some member or base cannot be default-constructed: a reference member without a default member initialiser, a const member of a type that would be left uninitialised, or a member whose own default constructor is deleted or inaccessible.

Why. The compiler assumes that a class with its own constructor has rules for building objects. T() = default; brings the default constructor back.

Answer. RAII binds a resource to an object: the constructor acquires the resource and the destructor releases it. Destructors of local objects run on every way out of a scope, including stack unwinding after an exception, so the resource is always released.

Why. Manual cleanup has to be repeated on every return and in every catch, and that is where leaks come from. With RAII, cleanup is written once. Examples: unique_ptr (memory), lock_guard (a mutex), fstream (a file), jthread (joining a thread).

Answer. Rule of three: if you write the destructor, the copy constructor or copy assignment, write all three. Rule of five: add the move constructor and move assignment too. Rule of zero: write none, by holding resources in members that already manage themselves. Rule of zero is the default.

Why. A hand-written destructor means the class owns something, so the member-wise copies the compiler generates would share it. Writing the five correctly is error-prone, so confine it to small resource handles (one per resource type) and compose everything else from them.

Answer. A shallow copy duplicates the pointer, so both objects point to the same buffer. A deep copy allocates a new buffer and copies the contents, so each object owns its own.

Why. The implicit copy constructor copies each member, and copying a raw pointer member is a shallow copy. For an owning class that leads to a double free when both destructors run, and to changes through one object showing up in the other. Shallow sharing is correct only when it is intended and reference counted, as in shared_ptr.

Answer. Yes. Access control in C++ is per class, not per object.

Why. That is how a copy constructor reads other.data_ and how operator== compares private fields. People who answer "no" are usually thinking of object-level privacy in languages like Smalltalk or Ruby. The check happens at compile time, on the name being accessed and the context it is accessed from.

Answer. It is at least 1 (in practice exactly 1). A complete object never has size 0, but an empty base subobject can take zero bytes (the empty base optimisation), and so can a member marked [[no_unique_address]] (C++20).

Why. Distinct objects need distinct addresses: in Empty arr[2], &arr[0] != &arr[1] requires each element to take space. The EBO is why std::unique_ptr<T> with the default deleter is the size of a raw pointer.

Answer. The class's destructor does not run. Every base and member that was already fully constructed is destroyed, in reverse order, and then the exception propagates. If the object was being created with new, the memory is freed too.

Why. The object's lifetime begins only when its constructor completes. Raw resources acquired in the constructor body leak in this case, which is the reason to hold each resource in an RAII member. A function-try-block on the constructor can observe or translate the exception, but it cannot stop it from propagating.

Answer. T(T) is ill-formed and the compiler rejects it. If it were allowed, passing the argument by value would itself need a copy, which would call the copy constructor, which would need another copy, forever.

Why. The standard says such a constructor is never a copy constructor and is ill-formed ([class.copy.ctor]). The usual answer "infinite recursion at run time" is the motivation, but in practice you get a compile error. The parameter is const T& so that temporaries and const objects can be copied. T(T&) is also a legal copy constructor, but it cannot copy const objects.

Answer. The copy constructor. The = in a declaration is initialisation syntax, not assignment. Assignment happens only to an object that already exists: T b; b = a;.

Why. The rule of thumb: if a new object is being created, a constructor runs. Assignment operators run only on objects that are already alive, and they must release whatever the object held before.

Answer. Yes. Objects with automatic, static or member storage then cannot be created outside the class, because their destructor would be called implicitly from code that has no access to it. Code can only create them on the heap and must destroy them through a member or friend, for example a destroy() function or reference counting.

Why. This is used to force heap-only objects, such as intrusively reference-counted COM-style objects that delete themselves when the count reaches zero. A protected destructor in a base class is the other common case: it stops delete through a base pointer without making the destructor virtual (Ch 2).

Answer. explicit stops the constructor from being used for implicit conversions and for copy initialisation (T t = x;). Direct initialisation (T t(x) or T t{x}) still works. Leave it off only when the conversion is natural and lossless, as with std::string from const char* or a Fraction from an integer.

Why. Implicit conversions let calls like sleep(5) compile against sleep(Duration) with the wrong unit. Since C++11, explicit also matters for multi-argument constructors, because it blocks return {a, b}; and f({a, b}). C++20 adds explicit(bool) for conditional explicitness in templates.

Answer. The implicit move constructor and move assignment are no longer declared, so std::move on a Holder now copies the vector. The class also stops being trivially destructible. Program behaviour is unchanged, but performance can collapse, for example when a std::vector<Holder> reallocates.

Why. A user-declared destructor suggests resource management, so C++11 kept the old copying behaviour for safety. ~Holder() = default; still counts as user-declared and has the same effect. Either delete the destructor or add Holder(Holder&&) = default; and friends (and then the copy operations too, since declaring a move deletes them). The Holder drill in the next section shows the effect.

+Base +engine +spare +Car | -Car -spare -engine -Base

Why. The base comes first, then the members in declaration order (engine, then wheel), whatever order the initialiser list uses. Because wheel appears in the initialiser list, its default member initialiser {"wheel"} is ignored and "spare" is used. Destruction is the exact reverse. Both compilers warn with -Wreorder.

default
copy ctor
copy ctor
copy assign
default

Why. T b = a; creates a new object, so the copy constructor runs, not assignment. b = c; assigns to an existing object. T d = T(); runs only the default constructor: since C++17, a prvalue initialises d directly, with no temporary and no copy (guaranteed copy elision, Ch 23).

make 1
make 2
drop 2
make 3
end 3
drop 3
drop 1

Why. Noisy(2); creates a temporary that is destroyed at the end of its full expression, the same line. Binding Noisy(3) to a const& local extends its lifetime to the end of r's scope. Locals are destroyed in reverse order of creation, so the extended temporary (created after a) dies first. Watch out for Noisy(x); with an identifier: that line declares a variable named x.

P()
P()
done

Why. Only two objects, a and c. P b(); is the most vexing parse: it declares a function b that takes no arguments and returns a P. Brace initialisation (P c{};) cannot be parsed as a function declaration, which is one reason to prefer it. GCC warns with -Wvexing-parse.

a=3 b=3

Why. The user-declared destructor suppresses the implicit move constructor. std::move(a) produces an rvalue, but the only constructor that can take it is the implicit copy constructor (const Holder& binds to rvalues), so the vector is copied. Remove the destructor and the output becomes a=0 b=3 with both libstdc++ and libc++. (A moved-from vector is formally "valid but unspecified", but both implementations leave it empty.)

Answer. The behaviour is undefined. end is declared first, so it is initialised first, and begin + len reads begin before it has been initialised. The program can print any value for end.

Fix. Declare begin before end, or initialise end from the parameters: end(b + len). The second fix is more robust, because it does not depend on member order at all. -Wall warns about both the reordering and the uninitialised read.

Answer. It is a double free. The implicit copy constructor copies the pointer, so a.p == b.p. Both destructors delete[] the same buffer. AddressSanitizer reports attempting double-free.

Fix. Follow the rule of three/five: write a deep-copying copy constructor and copy assignment (and the moves), or delete copying. The best fix is the rule of zero: hold a std::string.

Answer. Self-assignment. When &o == this, delete[] p_ frees the buffer that o.p_ still points to, and then strlen(o.p_) reads freed memory: a use after free. ASan reports heap-use-after-free. Self-assignment usually arrives through aliases such as v[i] = v[j], not as literal n = n.

Fix. Allocate and copy first, then delete. That also gives the strong exception guarantee if new throws. Alternatively, use copy-and-swap. An if (this == &o) check alone fixes self-assignment but still leaves the object broken if new throws.

Answer. There are two errors, and both are the intended effect of explicit. Meters b = 4.0; is copy initialisation, which cannot use an explicit constructor. twice(5.0) would need an implicit conversion from double to Meters. Meters a(3.0) is direct initialisation and is fine.

Fix. Be explicit at the call site: Meters b{4.0}; and twice(Meters{5.0}). Unit types are the textbook case for explicit, because a bare 5.0 could mean feet.

Approach. Store size_ and a char*, with size declared first because the buffer allocation reads it. The copy constructor allocates and copies size_ + 1 bytes. Moves steal the pointer with std::exchange. Both assignments build a local copy or moved temporary and swap it in, so self-assignment needs no special handling and the old buffer is freed by the temporary's destructor.

#include <cstdio>
#include <cstring>
#include <utility>

class String {
public:
    String(const char* s = "") : size_(std::strlen(s)), data_(new char[size_ + 1]) {
        std::memcpy(data_, s, size_ + 1);
    }
    String(const String& other) : size_(other.size_), data_(new char[other.size_ + 1]) {
        std::memcpy(data_, other.data_, size_ + 1);
    }
    String(String&& other) noexcept
        : size_(std::exchange(other.size_, 0)), data_(std::exchange(other.data_, nullptr)) {}
    String& operator=(const String& other) {
        String copy(other);
        swap(copy);
        return *this;
    }
    String& operator=(String&& other) noexcept {
        String moved(std::move(other));
        swap(moved);
        return *this;
    }
    ~String() { delete[] data_; }

    void swap(String& other) noexcept {
        std::swap(size_, other.size_);
        std::swap(data_, other.data_);
    }
    std::size_t size() const { return size_; }
    const char* c_str() const { return data_ ? data_ : ""; }

private:
    std::size_t size_;
    char* data_;
};

int main() {
    String a("hello");
    String b = a;
    String c;
    c = a;
    String d = std::move(b);
    String& alias = a;
    a = alias;
    String& self = c;
    c = std::move(self);
    std::printf("%s %s %s [%s] %zu\n", a.c_str(), c.c_str(), d.c_str(), b.c_str(), b.size());
}

hello hello hello [] 0

Complexity and pitfalls. Copies are O(n) and moves are O(1). Common mistakes: forgetting the + 1 for the terminator, leaving the moved-from pointer non-null (double free), returning nullptr from c_str() after a move, and omitting noexcept. Without noexcept, std::vector<String> copies on reallocation (Ch 20).

Estimated rating: ~1500 · straightforward logic, but six special members with lifetime and exception corner cases.

Approach. Use two inline static counters. Every constructor increments both, and the destructor decrements live_. The trap is the implicit copy and move constructors, which would create objects without counting them and drive live() negative. So all three constructors are written by hand, and the assignments are defaulted, because they do not change the number of objects.

#include <cstdio>
#include <utility>

class Counted {
public:
    Counted() { ++live_; ++created_; }
    Counted(const Counted&) { ++live_; ++created_; }
    Counted(Counted&&) noexcept { ++live_; ++created_; }
    Counted& operator=(const Counted&) = default;
    Counted& operator=(Counted&&) noexcept = default;
    ~Counted() { --live_; }

    static int live() { return live_; }
    static int created() { return created_; }

private:
    inline static int live_ = 0;
    inline static int created_ = 0;
};

int main() {
    {
        Counted a;
        Counted b = a;
        Counted c = std::move(b);
        a = c;
        std::printf("inside: live=%d created=%d\n", Counted::live(), Counted::created());
    }
    std::printf("after: live=%d created=%d\n", Counted::live(), Counted::created());
}

inside: live=3 created=3
after: live=0 created=3

Pitfalls. Defining only the default constructor gives after: live=-2. For use across threads, make the counters std::atomic<int>. In a CRTP base, Counted<T> gives every derived type its own counters.

Estimated rating: ~1100 · tests whether you know every path that creates an object.

Approach. Delete both copy operations. The move constructor takes the handle with std::exchange(other.f_, nullptr). Move assignment closes its current handle before taking the new one, and guards against self-move. The destructor closes only a non-null handle.

#include <cstdio>
#include <utility>

class File {
public:
    File(const char* path, const char* mode) : f_(std::fopen(path, mode)) {}
    ~File() { if (f_) std::fclose(f_); }
    File(const File&) = delete;
    File& operator=(const File&) = delete;
    File(File&& other) noexcept : f_(std::exchange(other.f_, nullptr)) {}
    File& operator=(File&& other) noexcept {
        if (this != &other) {
            if (f_) std::fclose(f_);
            f_ = std::exchange(other.f_, nullptr);
        }
        return *this;
    }
    explicit operator bool() const { return f_ != nullptr; }
    std::FILE* get() const { return f_; }

private:
    std::FILE* f_;
};

int main() {
    {
        File out("ch01_demo.txt", "w");
        std::fputs("raii\n", out.get());
    }
    File in("ch01_demo.txt", "r");
    char line[16] = {};
    if (!std::fgets(line, sizeof line, in.get())) return 1;
    File moved = std::move(in);
    std::printf("%s", line);
    std::printf("in=%d moved=%d\n", static_cast<bool>(in), static_cast<bool>(moved));
    std::remove("ch01_demo.txt");
}

raii
in=0 moved=1

Pitfalls. The inner block matters: the writer's destructor flushes and closes the file before it is reopened for reading. In production, prefer std::unique_ptr<FILE, decltype(&fclose)> or a stateless deleter (Ch 12), or simply std::fstream. Also decide what a failed fopen means: here it gives a null handle that converts to false, and throwing is the other option.

Estimated rating: ~1300 · a move-only handle, with the close-before-overwrite and self-move details.

Approach. Store three members with default member initialisers, so the defaulted default constructor yields an empty vector. When the vector is full, grow() allocates double the capacity, copies, and frees the old buffer. Copying allocates exactly size elements. Assignment is copy-and-swap.

#include <algorithm>
#include <cstddef>
#include <cstdio>
#include <utility>

class IntVector {
public:
    IntVector() = default;
    IntVector(const IntVector& other)
        : data_(other.size_ ? new int[other.size_] : nullptr), size_(other.size_), cap_(other.size_) {
        std::copy(other.data_, other.data_ + size_, data_);
    }
    IntVector(IntVector&& other) noexcept
        : data_(std::exchange(other.data_, nullptr)),
          size_(std::exchange(other.size_, 0)),
          cap_(std::exchange(other.cap_, 0)) {}
    IntVector& operator=(IntVector other) noexcept {
        swap(other);
        return *this;
    }
    ~IntVector() { delete[] data_; }

    void push_back(int value) {
        if (size_ == cap_) grow();
        data_[size_++] = value;
    }
    void swap(IntVector& other) noexcept {
        std::swap(data_, other.data_);
        std::swap(size_, other.size_);
        std::swap(cap_, other.cap_);
    }
    int operator[](std::size_t i) const { return data_[i]; }
    std::size_t size() const { return size_; }
    std::size_t capacity() const { return cap_; }

private:
    void grow() {
        std::size_t next = cap_ ? 2 * cap_ : 1;
        int* bigger = new int[next];
        std::copy(data_, data_ + size_, bigger);
        delete[] data_;
        data_ = bigger;
        cap_ = next;
    }

    int* data_ = nullptr;
    std::size_t size_ = 0;
    std::size_t cap_ = 0;
};

int main() {
    IntVector a;
    for (int i = 1; i <= 5; ++i) a.push_back(i);
    IntVector b = a;
    b.push_back(6);
    IntVector c;
    c = std::move(b);
    std::printf("a size=%zu cap=%zu\n", a.size(), a.capacity());
    std::printf("b size=%zu\n", b.size());
    std::printf("c:");
    for (std::size_t i = 0; i < c.size(); ++i) std::printf(" %d", c[i]);
    std::printf("\n");
}

a size=5 cap=8
b size=0
c: 1 2 3 4 5 6

Complexity and pitfalls. Doubling makes n pushes cost O(n) copies in total, so each push is amortised O(1). Growing by a constant amount instead would make n pushes cost O(n²). grow() allocates before it frees, so a throwing new leaves the vector unchanged. A generic Vector<T> would need raw storage and placement new so that capacity does not construct elements (Ch 14).

Estimated rating: ~1600 · rule of five, plus amortised growth and the correct moved-from state.

Approach. This is the named constructor idiom. The real constructor is private and trusts its arguments, and the public static make validates first, so every Date in the program went through the check. A constructor cannot return "no object", which is why the factory returns std::optional; throwing from a public constructor is the other option when bad input is truly exceptional. There are no setters: next_day() is the only mutation, and it rolls the day, month and year over in that order so the invariant holds on exit.

#include <cstdio>
#include <optional>

class Date {
public:
    static std::optional<Date> make(int y, int m, int d) {
        if (m < 1 || m > 12 || d < 1 || d > days_in(y, m)) return std::nullopt;
        return Date(y, m, d);
    }
    int year() const { return y_; }
    int month() const { return m_; }
    int day() const { return d_; }
    void next_day() {
        if (++d_ <= days_in(y_, m_)) return;
        d_ = 1;
        if (++m_ <= 12) return;
        m_ = 1;
        ++y_;
    }

private:
    Date(int y, int m, int d) : y_(y), m_(m), d_(d) {}
    static bool leap(int y) { return (y % 4 == 0 && y % 100 != 0) || y % 400 == 0; }
    static int days_in(int y, int m) {
        static constexpr int days[] = {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
        return m == 2 && leap(y) ? 29 : days[m - 1];
    }

    int y_, m_, d_;
};

static void show(const Date& d) { std::printf("%04d-%02d-%02d\n", d.year(), d.month(), d.day()); }

int main() {
    const int tests[][3] = {{2024, 2, 29}, {2023, 2, 29}, {1900, 2, 29}, {2000, 2, 29}, {2024, 13, 1}};
    for (const auto& t : tests) {
        auto d = Date::make(t[0], t[1], t[2]);
        std::printf("%d-%d-%d %s\n", t[0], t[1], t[2], d ? "ok" : "rejected");
    }
    Date d = *Date::make(2023, 12, 31);
    d.next_day();
    show(d);
    d = *Date::make(2024, 2, 28);
    d.next_day();
    show(d);
    d.next_day();
    show(d);
    // Date bad(2024, 2, 30);  // error: the constructor is private
}

2024-2-29 ok
2023-2-29 rejected
1900-2-29 rejected
2000-2-29 ok
2024-13-1 rejected
2024-01-01
2024-02-29
2024-03-01

Pitfalls. The leap-year rule has three parts (divisible by 4, except centuries, except multiples of 400), and forgetting the last two accepts 1900-02-29. The implicit copy operations are correct here, because copying a valid date gives a valid date, so the rule of zero applies. std::optional<Date> can still hold a Date built by a private constructor because make, a member, builds it. Dereferencing an empty optional with * is undefined behaviour, so production callers check it or use .value(), which throws. A one-line struct with three public ints would be simpler and would let any caller write d.day = 31 in February.

Estimated rating: ~1200 · simple calendar logic, judged on making invalid states unrepresentable.

Answer. Load the vptr from offset 0 of *p, load the function pointer from the fixed slot for speak in that vtable, then make an indirect call with p (possibly adjusted) as this.

Why. The compiler knows from Base's definition which slot speak occupies, and every derived class keeps that slot at the same index, so the only run-time work is finding which table this object uses. Under multiple inheritance the slot may hold a thunk that adjusts this before jumping to the real override. A common wrong answer is "the runtime searches for the function by name": nothing is looked up by name, and the cost is constant regardless of hierarchy depth.

Answer. Virtual dispatch needs an existing object whose vptr names its dynamic type, and the constructor is what creates the object and writes the vptr. To create an object of a type known only at run time, use a factory function, or for copies, a virtual clone() (the "virtual constructor" idiom).

Why. new T requires the exact type at compile time so it knows the size and which constructor to call. A virtual function selects behaviour based on an object that already exists. clone() works because it is called on an existing object, which then constructs a copy of its own type. Candidates sometimes answer "because constructors have no name": that is a grammar detail, not the reason.

Answer. Overloading is several functions with the same name and different parameter lists in the same scope; overload resolution picks one at compile time from the static types of the arguments. Overriding is a derived class redeclaring a base virtual function with the same parameter types, cv-qualifiers and ref-qualifier; the body is picked at run time from the dynamic type of the object. Hiding is what happens when a derived class declares any member with the same name that does not override: every base member of that name disappears from lookup in the derived scope, decided at compile time.

Why. The textbook line "overloading is compile-time polymorphism, overriding is run-time polymorphism" is right but incomplete, and interviewers probe the gap. Overloading never crosses scopes, so a Derived::f(double) does not add an overload to Base::f(int): it hides it, and d.f(1) converts 1 to double. Writing override turns an accidental hide into a compile error, and using Base::f; turns a deliberate one back into overloading. Return types play no part in overloading, and only covariant changes are allowed when overriding.

Answer. Yes, yes, and no. A pure virtual function may have a definition, written outside the class (virtual void f() = 0 {} is ill-formed), and derived classes can call it as Base::f(). A pure virtual destructor must be defined, or the link fails with undefined reference to Base::~Base(). A derived class is concrete without writing a destructor, because its implicit destructor overrides the pure one.

Why. = 0 means "derived classes must override this", not "this has no code". Every derived destructor calls the base destructor directly (not through the vtable), so that call needs a body. The pure virtual destructor is the idiom for making a class abstract when no other function is a natural candidate. The common wrong answer, from Java and C# abstract methods, is "pure means no implementation, so a body is a compile error".

Answer. Inline: yes. Static: no. Template: no (although a virtual function inside a class template is fine).

Why. inline is about linkage (multiple definitions allowed); the compiler inlines the body wherever it can devirtualise the call, and still emits an out-of-line copy for the vtable slot. A static member function has no this and is called without an object, so there is no vptr to dispatch on. A member function template can be instantiated with any number of types in any translation unit, so the vtable size and slot numbers could not be fixed when the class is defined. A class template's virtual functions are fine because each instantiation is a separate class with a fixed set of functions.

Answer. 16.

Why. The object holds one vptr (8 bytes) whatever the number of virtual functions; the ten function pointers live in the single shared vtable. The char sits at offset 8 and the size rounds up to the 8-byte alignment of the vptr. The common wrong answer is 88 (ten pointers plus a padded char), which confuses the per-class table with the per-object pointer. The answer changes with multiple inheritance, where each polymorphic base subobject brings its own vptr.

Answer. When no one deletes a derived object through a pointer to it. The standard way to enforce that is a protected non-virtual destructor. Classes that are never used polymorphically, and final classes, also do not need one.

Why. [expr.delete]/3 makes delete base_ptr undefined only when the dynamic type differs and the destructor is not virtual. A protected destructor turns that misuse into a compile error, so you save the vptr and keep the class trivially destructible where possible. This is C++ Core Guidelines C.35: "public and virtual, or protected and non-virtual". Saying "every class with inheritance needs one" is safe advice but wrong as a rule: mixins and CRTP bases (Ch 3) deliberately use protected non-virtual destructors.

Answer. No. It is undefined behaviour even with the virtual destructor.

Why. [expr.delete]/3: for delete[], the dynamic type must be the same as the static type. delete[] walks the array using sizeof of the static type to find each element, and sizeof(Base) is not sizeof(Derived), so it would call destructors at the wrong addresses. The same stride problem breaks p[1]. The virtual destructor fixes single-object delete only. Use std::vector<std::unique_ptr<Base>> for a polymorphic collection.

Answer. Yes. Access controls who may call a name; overriding is not a call. It is the basis of the non-virtual interface (NVI) idiom.

Why. The base has a public non-virtual function that checks preconditions, takes locks, logs or times the operation, and then calls a private virtual hook. Derived classes customise the hook but cannot skip the fixed policy, and outside code cannot call the hook directly. Many candidates think private members are "not inherited": they are inherited and present in the object, just not accessible by name from the derived class. The C++ standard library uses this pattern in std::streambuf (public sputc, protected virtual overflow).

Answer. base_ref.run() compiles and runs Derived::run. derived_ref.run() does not compile.

Why. [class.access.virt]: access is checked at the call site using the static type of the object expression, while the function executed comes from the dynamic type. Through Base& the name is public. Through Derived& it is private. This surprises people who expect the override's access to "win" at run time; access is purely a compile-time property.

Answer. When you need to override a virtual function of the class you are using, access its protected members, or (before C++20) get the empty base optimisation. Otherwise prefer a member.

Why. Both model "implemented in terms of" without an is-a relationship, since outside code cannot convert to the private base. A member is simpler, has a name and allows several instances, while a private base's names enter your scope and can hide or clash. C++20 [[no_unique_address]] gives an empty member zero size, which removes the main historical reason (storing an empty deleter or allocator for free).

Answer. The vptr is overwritten with zero, so the next virtual call jumps through a null table and crashes. Formally it is undefined behaviour, because a polymorphic class is not trivially copyable.

Why. The vptr is written by the constructor before the body runs, so the memset in the body wipes it. The same applies to memcpy between polymorphic objects, calloc plus a cast instead of construction, and writing polymorphic objects to a file and reading them back (the stored vptr is meaningless in another run, especially with ASLR). The fix is to use member initialisers (int x = 0;) or value initialisation. std::is_trivially_copyable_v<T> tells you whether byte copies are allowed.

Answer. Some non-pure virtual function of Widget is declared but never defined, most often the first one out of line (the key function), or the .cpp that defines it is not linked in.

Why. GCC and Clang emit the vtable only in the translation unit that defines the key function: the first virtual function that is not pure and not inline. Every constructor references the vtable, so the error appears wherever an object is constructed, even if nobody calls the missing function. Common culprits: a declared but undefined virtual destructor, forgetting to add a file to the build, or (with Qt) a missing moc step. A pure virtual function does not cause this; the slot simply holds __cxa_pure_virtual.

Answer. Only calls made through a pointer, reference or object whose static type is the final class (or that otherwise prove the type). Calls through a Base* still dispatch.

Why. If the static type is Leaf& and Leaf is final, the dynamic type must be exactly Leaf, so the compiler can call Leaf::f directly and inline it. A Base* could point at any class, so final on Leaf tells the compiler nothing at that call site (unless whole-program devirtualisation can see the entire hierarchy). final also lets dynamic_cast<Leaf*> become a vptr comparison.

Answer. Compile-time (static) polymorphism is overloading, templates constrained by concepts, and CRTP: the call target is fixed during compilation, so it is a direct, inlinable call with no per-object overhead. Run-time (dynamic) polymorphism is virtual functions called through a pointer or reference: one vptr per object, two dependent loads and an indirect call, usually no inlining. Choose static dispatch when the set of types is known at build time and the call is hot; choose virtual functions when the type is picked at run time, objects of different types share one container, or the implementation must stay behind a library boundary.

Why. Static polymorphism pays in other currencies: one instantiation per type (code size and instruction cache), longer compile times, implementation in headers, and no heterogeneous containers. std::variant with std::visit sits between the two: a closed set of types, value storage and a jump table instead of a vtable. The usual wrong answer is "virtual calls are slow because of the vtable lookup". The lookup costs a few cycles when predicted; the real costs are the lost inlining and mispredicted branches on mixed targets (see the cost of a virtual call).

Answer. The most derived class constructs it, first, before any non-virtual base. Initialisers for the virtual base written in intermediate classes are ignored when those classes are not the most derived.

Why. There is only one virtual base subobject, so exactly one constructor call must initialise it; letting either intermediate class do it would be arbitrary. If the most derived class does not name the virtual base in its initialiser list, the virtual base is default-constructed, which is a compile error if it has no default constructor. The reading drill on virtual bases below shows the order.

Answer. Use static_cast when you know the dynamic type by construction (it is free). Use dynamic_cast when you need to ask, when you cast across branches of a hierarchy, or when the base is virtual.

Why. static_cast<Derived*>(base_ptr) just subtracts a compile-time offset; if the object is not a Derived, using the result is undefined behaviour. dynamic_cast consults RTTI and returns null (or throws std::bad_cast for references). From a virtual base, static_cast is ill-formed because the offset depends on the most derived type and is known only at run time. Cross-casts (Readable* to Writable*) are only possible with dynamic_cast.

Answer. collide(const Shape&). Overload resolution is done at compile time on static types. To select on the dynamic type, make the operation a virtual member, and for two dynamic types use double dispatch (the visitor pattern) or std::variant with std::visit.

Why. C++ virtual functions give single dispatch: only the object the function is called on is examined at run time. Arguments are never examined. The visitor pattern makes two virtual calls, one on each object, to recover both types; it is the coding drill on double dispatch below. Candidates coming from languages with multimethods sometimes expect the runtime to pick the more specific overload.

Derived 1
Derived 1
Derived 2
Base 1

Why. The body is chosen by the dynamic type, the default argument by the static type ([dcl.fct.default]/10). Through Base& and Base* the compiler inserts 1, then dispatch runs Derived::show. Through d the static type is Derived, so the default is 2. The last line creates a temporary Base by slicing, so it is a real Base object. Rule: never change a default argument in an override.

... woof woof ...

Why. std::vector<Animal> stores Animal objects, so push_back(Dog{}) copies (moves) only the Animal part into a new Animal: slicing. Animal copy = ref; slices too, even though ref refers to a dog, because the copy is a fresh Animal whose constructor installs Animal's vptr. Only the reference and the pointer keep the dynamic type. Making Animal's copy operations protected or deleted would turn both slicing lines into compile errors.

Answer. Buffer is polymorphic but its destructor is not virtual, so delete b is undefined behaviour. In practice it prints only ~Buffer: ~FileBuffer never runs and the 4 KB vector leaks. On Linux, LeakSanitizer reports the leaked 4096-byte buffer, and ASan can also report new-delete-type-mismatch, because the object was allocated with 32 bytes and sized deallocation frees it as an 8-byte Buffer. The compiler warning below is the most reliable detector.

Why. Without virtual, delete b is compiled as a direct call to Buffer::~Buffer followed by operator delete(b, sizeof(Buffer)). GCC also warns with -Wdelete-non-virtual-dtor, which is in -Wall. Fix: virtual ~Buffer(), or hold the object in a unique_ptr<FileBuffer>. The output is not compared here because the behaviour is undefined.

fancy int 2
double 2.5
fancy int 3

Why. In Fancy's scope, the name print finds only Fancy::print(int); the base print(double) is hidden, so 2.5 is converted to 2. Through Printer&, lookup sees both base overloads, picks print(double) at compile time, and since Fancy does not override it, Printer::print(double) runs. p.print(3) picks print(int) and dispatches to the override. Fix: using Printer::print; in Fancy. GCC's -Woverloaded-virtual flags this.

0
21.5

Answer. Thermo::read is not const, so it does not override Sensor::read() const. It is a new function that hides the base one in Thermo's scope. Through const Sensor&, the base version runs.

Why. An override must match the cv-qualifiers and ref-qualifier exactly. Writing double read() const override fixes it, and writing override on the broken version would have turned the bug into a compile error ("marked override, but does not override"). This is the single best argument for always writing override.

A(3)
B
C
D
d.v = 3
A(2)
C
c.v = 2

Why. When D is the most derived class, D's constructor initialises the virtual base A first, with A(3). The A(1) and A(2) initialisers in B and C are skipped because those constructors are not running for the most derived object. When a plain C is created, C is the most derived class, so its A(2) is used. Remove A(3) from D and the program fails to compile, because A has no default constructor: many candidates expect A(1) from the first base instead.

Answer. A Copier contains two Device subobjects (one in Scanner, one in Printer), so c.id is ambiguous. Converting Copier* to Device* is ambiguous for the same reason.

Why. Fix 1: say which one you mean, c.Scanner::id = 7;, if the copier really has two independent devices. Fix 2: if there should be one device, inherit virtually, struct Scanner : virtual Device and struct Printer : virtual Device, so both share a single subobject. Fix 2 costs a vbase offset per access and makes Copier responsible for constructing Device. Often the best fix is design: make Scanner and Printer data-free interfaces and keep the id in Copier.

Answer. When d is destroyed, ~Download runs first, then ~Task sets the vptr back to Task's vtable. finish() then calls cleanup() through that table, whose slot is the pure virtual stub. With GCC and Clang the runtime prints pure virtual method called to stderr and calls std::terminate, so done never prints.

Why. [class.abstract]/6 makes a virtual call to a pure virtual function from the abstract class's constructor or destructor undefined. A direct call would usually be caught at compile or link time; going through a helper hides it. Fix: do the cleanup in ~Download (each class releases what it owns, RAII style), or make cleanup non-pure. Never rely on derived behaviour from a base destructor.

circle
shape

Why. Overload resolution uses the static type of each argument at compile time. s has static type Shape&, so collide(const Shape&) is chosen even though the object is a Circle. Virtual dispatch happens only on the object a member function is called on. The visitor pattern (coding drill below) is the standard way to dispatch on argument types.

7,8,3

Why. ra = b calls Point::operator=, chosen statically because assignment operators are not virtual here. It copies only the Point fields, leaving a.z at 3: a half-assigned object that matches neither original. This is the assignment form of slicing. Making operator= virtual does not really help, because the override would have to accept a const Point& and decide what to do with a plain Point. The usual fix is to make polymorphic bases non-assignable (protected or deleted copy assignment).

01
bad_typeid

Why. A is not polymorphic, so typeid(a) is resolved at compile time from the static type A: there is no vptr to consult. P is polymorphic, so typeid(p) reads the dynamic type Q. For a polymorphic glvalue obtained by dereferencing a null pointer, typeid throws std::bad_typeid instead of crashing ([expr.typeid]/3); this is one of the few places where *nullptr has defined behaviour. The name string itself is implementation-defined, which is why the program never prints a successful one.

Approach. Give Shape a public non-virtual clone() that wraps a private virtual do_clone() returning a raw pointer, so each override can use a covariant return type and the public interface still returns a smart pointer. Make Shape's copy operations protected: derived classes can still copy themselves inside do_clone, but outside code cannot slice. Drawing's copy constructor clones each element; assignment uses copy-and-swap so a single by-value operator= handles copy and move and gives the strong exception guarantee (rule of five from Ch 1).

#include <iostream>
#include <memory>
#include <string>
#include <utility>
#include <vector>

class Shape {
public:
    virtual ~Shape() = default;
    virtual double area() const = 0;
    virtual std::string name() const = 0;
    virtual void scale(double k) = 0;
    std::unique_ptr<Shape> clone() const { return std::unique_ptr<Shape>(do_clone()); }
protected:
    Shape() = default;
    Shape(const Shape&) = default;             // derived classes may copy, outsiders may not
    Shape& operator=(const Shape&) = default;
private:
    virtual Shape* do_clone() const = 0;
};

class Rect final : public Shape {
public:
    Rect(double w, double h) : w_(w), h_(h) {}
    double area() const override { return w_ * h_; }
    std::string name() const override { return "rect"; }
    void scale(double k) override { w_ *= k; h_ *= k; }
private:
    Rect* do_clone() const override { return new Rect(*this); }  // covariant
    double w_, h_;
};

class Tri final : public Shape {
public:
    Tri(double b, double h) : b_(b), h_(h) {}
    double area() const override { return b_ * h_ / 2; }
    std::string name() const override { return "tri"; }
    void scale(double k) override { b_ *= k; h_ *= k; }
private:
    Tri* do_clone() const override { return new Tri(*this); }
    double b_, h_;
};

class Drawing {
public:
    Drawing() = default;
    Drawing(const Drawing& other) {
        shapes_.reserve(other.shapes_.size());
        for (const auto& s : other.shapes_) shapes_.push_back(s->clone());
    }
    Drawing(Drawing&&) noexcept = default;
    Drawing& operator=(Drawing other) noexcept {  // copy-and-swap: copy happens in the parameter
        shapes_.swap(other.shapes_);
        return *this;
    }
    ~Drawing() = default;

    void add(std::unique_ptr<Shape> s) { shapes_.push_back(std::move(s)); }
    Shape& at(std::size_t i) { return *shapes_.at(i); }
    double total_area() const {
        double total = 0;
        for (const auto& s : shapes_) total += s->area();
        return total;
    }
private:
    std::vector<std::unique_ptr<Shape>> shapes_;
};

int main() {
    Drawing a;
    a.add(std::make_unique<Rect>(2, 3));
    a.add(std::make_unique<Tri>(4, 5));
    Drawing b = a;  // deep copy
    b.at(0).scale(2);
    Drawing c;
    c = b;          // copy assignment
    c.at(1).scale(0.5);
    std::cout << a.total_area() << ' ' << b.total_area() << ' ' << c.total_area() << '\n';
    std::cout << c.at(0).name() << ' ' << c.at(1).name() << '\n';
    // Rect r = static_cast<Rect&>(a.at(0)); fine, but  Shape s = a.at(0);  does not compile
}

16 34 26.5
rect tri

Complexity and pitfalls. Copy is O(n) allocations; move is O(1). Pitfalls: forgetting to override do_clone in a further-derived class silently clones the parent type (marking leaf classes final prevents that class of bug, and some codebases add a CRTP helper that writes do_clone for you); returning std::unique_ptr<Rect> from an override does not compile because smart pointers are not covariant; and a defaulted copy constructor on Drawing would fail to compile (unique_ptr is move-only), which is the compiler telling you a decision is needed.

Estimated rating: ~1400 · standard idiom, but it needs covariance, protected copies and copy-and-swap together

Approach. One constant table per "class" plays the vtable; the first field of every object plays the vptr. Because Animal is the first member of a standard-layout Dog, a Dog* and a pointer to its base member are pointer-interconvertible, so the "override" can reinterpret_cast back to Dog legally. The destroy slot plays the virtual deleting destructor: it frees the object as its real type.

#include <iostream>

struct Animal;
struct AnimalVTable {
    void (*speak)(const Animal*);
    void (*destroy)(Animal*);
};
struct Animal {
    const AnimalVTable* vptr;
    const char* name;
};

static void speak(const Animal* a) { a->vptr->speak(a); }  // the "virtual call"
static void destroy(Animal* a) { a->vptr->destroy(a); }

struct Dog { Animal base; int barks; };
static void dog_speak(const Animal* a) {
    const Dog* d = reinterpret_cast<const Dog*>(a);  // ok: base is the first member
    std::cout << a->name << ':';
    for (int i = 0; i < d->barks; ++i) std::cout << " woof";
    std::cout << '\n';
}
static void dog_destroy(Animal* a) { delete reinterpret_cast<Dog*>(a); }
static constexpr AnimalVTable dog_vtable{dog_speak, dog_destroy};

static Animal* make_dog(const char* name, int barks) {
    Dog* d = new Dog{{&dog_vtable, name}, barks};
    return &d->base;
}

struct Cat { Animal base; bool grumpy; };
static void cat_speak(const Animal* a) {
    const Cat* c = reinterpret_cast<const Cat*>(a);
    std::cout << a->name << ": " << (c->grumpy ? "hiss" : "meow") << '\n';
}
static void cat_destroy(Animal* a) { delete reinterpret_cast<Cat*>(a); }
static constexpr AnimalVTable cat_vtable{cat_speak, cat_destroy};

static Animal* make_cat(const char* name, bool grumpy) {
    Cat* c = new Cat{{&cat_vtable, name}, grumpy};
    return &c->base;
}

int main() {
    Animal* zoo[] = {make_dog("Rex", 2), make_cat("Tom", false), make_cat("Grim", true)};
    for (const Animal* a : zoo) speak(a);
    for (Animal* a : zoo) destroy(a);
}

Rex: woof woof
Tom: meow
Grim: hiss

Complexity and pitfalls. Each call is the same two loads and an indirect call as a real virtual call. Pitfalls: the cast back is only valid while the embedded base is the first member of a standard-layout struct (otherwise you need offsetof, the kernel's container_of); calling delete on the Animal* itself would be undefined, exactly like a missing virtual destructor; and nothing checks that a table's functions match its object type, which is what the compiler-generated version guarantees for you. Mention in the interview that real vtables also hold RTTI and offset-to-top, and that you have reimplemented single inheritance only.

Estimated rating: ~1600 · needs the vtable model and the pointer-interconvertibility rule, little code

Approach. This is Sean Parent's "runtime polymorphism without inheritance". Keep the hierarchy private: a nested abstract Concept with virtual draw_ and clone, and a class template Model<T> that stores a T and forwards to the free draw found by argument-dependent lookup. Drawable owns a unique_ptr<Concept>, copies by cloning, and exposes draw as a hidden friend. Constrain the converting constructor so it never hijacks copying a Drawable. This is the same technique as std::function and std::any.

#include <iostream>
#include <memory>
#include <string>
#include <type_traits>
#include <utility>
#include <vector>

static void draw(int x, std::ostream& out, std::size_t indent) {
    out << std::string(indent, ' ') << x << '\n';
}
static void draw(const std::string& s, std::ostream& out, std::size_t indent) {
    out << std::string(indent, ' ') << s << '\n';
}

class Drawable {
public:
    template <class T>
        requires(!std::is_same_v<std::remove_cvref_t<T>, Drawable>)
    Drawable(T x) : self_(std::make_unique<Model<T>>(std::move(x))) {}
    Drawable(const Drawable& other) : self_(other.self_->clone()) {}
    Drawable(Drawable&&) noexcept = default;
    Drawable& operator=(Drawable other) noexcept {
        self_ = std::move(other.self_);
        return *this;
    }
    ~Drawable() = default;

    friend void draw(const Drawable& d, std::ostream& out, std::size_t indent) {
        d.self_->draw_(out, indent);
    }

private:
    struct Concept {
        virtual ~Concept() = default;
        virtual void draw_(std::ostream& out, std::size_t indent) const = 0;
        virtual std::unique_ptr<Concept> clone() const = 0;
    };
    template <class T>
    struct Model final : Concept {
        explicit Model(T x) : data(std::move(x)) {}
        void draw_(std::ostream& out, std::size_t indent) const override { draw(data, out, indent); }
        std::unique_ptr<Concept> clone() const override { return std::make_unique<Model>(*this); }
        T data;
    };
    std::unique_ptr<Concept> self_;
};

using Document = std::vector<Drawable>;
static void draw(const Document& doc, std::ostream& out, std::size_t indent) {
    out << std::string(indent, ' ') << "<document>\n";
    for (const auto& d : doc) draw(d, out, indent + 2);
    out << std::string(indent, ' ') << "</document>\n";
}

struct Circle { double r; };
static void draw(const Circle& c, std::ostream& out, std::size_t indent) {
    out << std::string(indent, ' ') << "circle r=" << c.r << '\n';
}

int main() {
    Document doc;
    doc.emplace_back(0);
    doc.emplace_back(std::string("hello"));
    doc.emplace_back(Circle{2});
    Drawable snapshot = doc;  // a deep copy of the document so far
    doc.push_back(std::move(snapshot));
    draw(doc, std::cout, 0);
}

<document>
  0
  hello
  circle r=2
  <document>
    0
    hello
    circle r=2
  </document>
</document>

Complexity and pitfalls. One heap allocation per stored value (a production version adds a small-buffer optimisation, see Ch 18), and one virtual call per draw. Pitfalls: the requires clause is defensive here, because a by-value template is never used to copy its own class ([class.copy.ctor]/5), but if you change the parameter to a forwarding reference T&&, the template beats the copy constructor for a non-const Drawable lvalue and wraps a Drawable inside a Drawable; the free draw for user types must be findable by ADL at instantiation, so declare it in the type's namespace; and copying doc while pushing into it (doc.push_back(doc)) is safe only because the argument is converted to a Drawable before the vector changes, which is why the reference makes the snapshot explicit.

Estimated rating: ~1800 · combines templates, a hidden class hierarchy, ADL and value semantics; many candidates have never seen it

Approach. Each node implements accept(Visitor&) by calling v.visit(*this). The first dispatch (virtual accept) recovers the node type; inside it, *this has a static type, so overload resolution picks the right visit overload, and the second dispatch (virtual visit) recovers the visitor type. Visitors keep their state as members. The trade-off: new operations are cheap, new node types require changing every visitor. std::variant plus std::visit is the closed-set, allocation-free alternative.

#include <iostream>
#include <memory>
#include <string>
#include <utility>

struct Num;
struct Add;
struct Mul;

struct Visitor {
    virtual ~Visitor() = default;
    virtual void visit(const Num&) = 0;
    virtual void visit(const Add&) = 0;
    virtual void visit(const Mul&) = 0;
};

struct Expr {
    virtual ~Expr() = default;
    virtual void accept(Visitor& v) const = 0;
};
using ExprPtr = std::unique_ptr<Expr>;

struct Num final : Expr {
    explicit Num(long v) : value(v) {}
    void accept(Visitor& v) const override { v.visit(*this); }
    long value;
};
struct Add final : Expr {
    Add(ExprPtr l, ExprPtr r) : lhs(std::move(l)), rhs(std::move(r)) {}
    void accept(Visitor& v) const override { v.visit(*this); }
    ExprPtr lhs, rhs;
};
struct Mul final : Expr {
    Mul(ExprPtr l, ExprPtr r) : lhs(std::move(l)), rhs(std::move(r)) {}
    void accept(Visitor& v) const override { v.visit(*this); }
    ExprPtr lhs, rhs;
};

static ExprPtr num(long v) { return std::make_unique<Num>(v); }
static ExprPtr add(ExprPtr l, ExprPtr r) { return std::make_unique<Add>(std::move(l), std::move(r)); }
static ExprPtr mul(ExprPtr l, ExprPtr r) { return std::make_unique<Mul>(std::move(l), std::move(r)); }

class Evaluator final : public Visitor {
public:
    long eval(const Expr& e) { e.accept(*this); return result_; }
    void visit(const Num& n) override { result_ = n.value; }
    void visit(const Add& a) override { long l = eval(*a.lhs); result_ = l + eval(*a.rhs); }
    void visit(const Mul& m) override { long l = eval(*m.lhs); result_ = l * eval(*m.rhs); }
private:
    long result_ = 0;
};

class Printer final : public Visitor {
public:
    std::string print(const Expr& e) { out_.clear(); e.accept(*this); return out_; }
    void visit(const Num& n) override { out_ += std::to_string(n.value); }
    void visit(const Add& a) override { binary(*a.lhs, " + ", *a.rhs); }
    void visit(const Mul& m) override { binary(*m.lhs, " * ", *m.rhs); }
private:
    void binary(const Expr& l, const char* op, const Expr& r) {
        out_ += '(';
        l.accept(*this);
        out_ += op;
        r.accept(*this);
        out_ += ')';
    }
    std::string out_;
};

int main() {
    ExprPtr exprs[] = {mul(add(num(2), num(3)), num(4)), add(num(1), mul(num(2), num(-5)))};
    Printer printer;
    Evaluator evaluator;
    for (const auto& e : exprs) std::cout << printer.print(*e) << " = " << evaluator.eval(*e) << '\n';
}

((2 + 3) * 4) = 20
(1 + (2 * -5)) = -9

Complexity and pitfalls. O(n) per traversal, two virtual calls per node. Pitfalls: in Evaluator, storing the left result in a local before evaluating the right side matters, because both recursive calls overwrite result_; forward declarations of every node are needed before Visitor; and deep trees recurse, so a pathological input can overflow the stack (an explicit stack fixes that). Interviewers often follow up with "how would you add a Sub node?" (every visitor changes) and "how is this different from std::visit?" (closed set, no heap, no virtual calls).

Estimated rating: ~1500 · classic pattern; the subtle part is explaining why two dispatches recover two types

Approach. Store a kind enum in the base, set by each constructor. Order the enumerators so that each intermediate class covers a contiguous range (all polygons between K_Square and K_LastPolygon); then each class's static classof is one or two comparisons. dyn_cast checks classof and then does a static_cast, which is safe because the check proved the type. cast asserts instead of checking. This is exactly how LLVM's llvm/Support/Casting.h works.

#include <cassert>
#include <iostream>
#include <memory>
#include <vector>

class Shape {
public:
    enum Kind { K_Square, K_Triangle, K_LastPolygon = K_Triangle, K_Circle };
    Kind kind() const { return kind_; }
    virtual ~Shape() = default;  // only so unique_ptr<Shape> deletes correctly
protected:
    explicit Shape(Kind k) : kind_(k) {}
private:
    const Kind kind_;
};

class Polygon : public Shape {
public:
    int sides() const { return sides_; }
    static bool classof(const Shape* s) { return s->kind() >= K_Square && s->kind() <= K_LastPolygon; }
protected:
    Polygon(Kind k, int n) : Shape(k), sides_(n) {}
private:
    int sides_;
};

class Square final : public Polygon {
public:
    explicit Square(double s) : Polygon(K_Square, 4), side(s) {}
    static bool classof(const Shape* s) { return s->kind() == K_Square; }
    double side;
};

class Triangle final : public Polygon {
public:
    Triangle() : Polygon(K_Triangle, 3) {}
    static bool classof(const Shape* s) { return s->kind() == K_Triangle; }
};

class Circle final : public Shape {
public:
    explicit Circle(double r) : Shape(K_Circle), radius(r) {}
    static bool classof(const Shape* s) { return s->kind() == K_Circle; }
    double radius;
};

template <class To, class From>
static bool isa(const From* p) { return To::classof(p); }

template <class To, class From>
static To* dyn_cast(From* p) { return p && To::classof(p) ? static_cast<To*>(p) : nullptr; }

template <class To, class From>
static To* cast(From* p) {
    assert(isa<To>(p) && "cast<> to the wrong type");
    return static_cast<To*>(p);
}

int main() {
    std::vector<std::unique_ptr<Shape>> shapes;
    shapes.push_back(std::make_unique<Square>(2));
    shapes.push_back(std::make_unique<Circle>(1));
    shapes.push_back(std::make_unique<Triangle>());
    shapes.push_back(std::make_unique<Square>(3));

    int polygons = 0, sides = 0;
    double square_sides = 0;
    for (const auto& s : shapes) {
        if (auto* p = dyn_cast<Polygon>(s.get())) { ++polygons; sides += p->sides(); }
        if (auto* sq = dyn_cast<Square>(s.get())) square_sides += sq->side;
    }
    std::cout << "polygons=" << polygons << " sides=" << sides << '\n';
    std::cout << "square side sum=" << square_sides << '\n';
    std::cout << "circle radius=" << cast<Circle>(shapes[1].get())->radius << '\n';
    std::cout << "isa<Circle>(square)=" << isa<Circle>(shapes[0].get()) << '\n';
}

polygons=3 sides=11
square side sum=5
circle radius=1
isa<Circle>(square)=0

Complexity and pitfalls. Each check is O(1) with no memory access beyond the kind field, much cheaper than dynamic_cast's hierarchy walk. Pitfalls: adding a new polygon after K_LastPolygon silently breaks Polygon::classof, so new kinds must go inside the range and the "last" marker must move; the hierarchy is closed (a plugin cannot add a kind without editing the enum); and cast becomes an unchecked static_cast in release builds where assert is compiled out.

Estimated rating: ~1600 · small code, but the range trick for intermediate classes and the safety argument are what interviewers probe

Approach. The registry is a function-local static ("Meyers singleton"), created on first use, so a static registration object in any translation unit can safely call into it during static initialisation: this sidesteps the static initialisation order fiasco covered in Ch 3. A small Register<T> helper turns registration into one line per codec. A std::map keeps names sorted and emplace reports duplicates.

#include <cctype>
#include <functional>
#include <iostream>
#include <map>
#include <memory>
#include <string>
#include <utility>
#include <vector>

class Codec {
public:
    virtual ~Codec() = default;
    virtual std::string encode(const std::string& in) const = 0;
};

class CodecRegistry {
public:
    using Factory = std::function<std::unique_ptr<Codec>()>;
    static CodecRegistry& instance() {
        static CodecRegistry registry;  // constructed on first call, thread-safe since C++11
        return registry;
    }
    bool add(std::string name, Factory f) { return factories_.emplace(std::move(name), std::move(f)).second; }
    std::unique_ptr<Codec> create(const std::string& name) const {
        auto it = factories_.find(name);
        return it == factories_.end() ? nullptr : it->second();
    }
    std::vector<std::string> names() const {
        std::vector<std::string> out;
        for (const auto& [name, factory] : factories_) out.push_back(name);
        return out;
    }
private:
    CodecRegistry() = default;
    std::map<std::string, Factory> factories_;
};

template <class T>
struct Register {
    explicit Register(const char* name) {
        CodecRegistry::instance().add(name, [] { return std::make_unique<T>(); });
    }
};

// Each block below would normally live in its own .cpp file.
class Upper final : public Codec {
public:
    std::string encode(const std::string& in) const override {
        std::string out = in;
        for (char& c : out) c = static_cast<char>(std::toupper(static_cast<unsigned char>(c)));
        return out;
    }
};
static const Register<Upper> reg_upper("upper");

class Reverse final : public Codec {
public:
    std::string encode(const std::string& in) const override { return {in.rbegin(), in.rend()}; }
};
static const Register<Reverse> reg_reverse("reverse");

class Rot13 final : public Codec {
public:
    std::string encode(const std::string& in) const override {
        std::string out = in;
        for (char& c : out) {
            if (c >= 'a' && c <= 'z') c = static_cast<char>('a' + (c - 'a' + 13) % 26);
            else if (c >= 'A' && c <= 'Z') c = static_cast<char>('A' + (c - 'A' + 13) % 26);
        }
        return out;
    }
};
static const Register<Rot13> reg_rot13("rot13");

int main() {
    auto& registry = CodecRegistry::instance();
    const auto names = registry.names();
    for (std::size_t i = 0; i < names.size(); ++i) std::cout << (i ? " " : "") << names[i];
    std::cout << '\n';
    for (const char* name : {"upper", "rot13", "reverse", "zip"}) {
        auto codec = registry.create(name);
        std::cout << name << ": " << (codec ? codec->encode("Hello") : "<unknown>") << '\n';
    }
    std::cout << "duplicate accepted: " << registry.add("upper", [] { return std::make_unique<Reverse>(); }) << '\n';
}

reverse rot13 upper
upper: HELLO
rot13: Uryyb
reverse: olleH
zip: <unknown>
duplicate accepted: 0

Complexity and pitfalls. Lookup is O(log n). Pitfalls worth raising: if codecs live in a static library, the linker drops object files that nothing references, so their registration objects never run (fix with --whole-archive or an explicit reference); registration during static initialisation is single-threaded, but adding codecs later from several threads needs a mutex; and the registry must not be a namespace-scope global, because another TU's registration could run before it is constructed.

Estimated rating: ~1500 · easy code; the static initialisation and linker questions are what make it senior-level

Answer. Abstraction chooses the operations a type exposes so callers can ignore the details. Encapsulation hides the representation behind access control so only the class can break its invariants. A C struct plus free functions (like FILE used through fopen/fread but with public fields) is an abstraction without enforced encapsulation; a class with a private field and a getter and setter for each one is encapsulated in syntax but offers no abstraction.

Why. Interviewers want to hear that the two are related but different levels: abstraction is the design decision, encapsulation the enforcement mechanism. The test of both together is whether you could change the representation (three pointers in std::vector versus a pointer and two sizes) without any caller noticing. Answering "encapsulation is data hiding and abstraction is hiding complexity" without an example sounds memorised.

Answer. Encapsulation: access control (private, protected) so that only member functions can break an invariant. Abstraction: choosing a small public interface, expressed as a class's public members, an abstract class or a concept. Inheritance: derivation, with public, protected or private access and optional virtual bases. Polymorphism: one interface, many types, either at compile time (overloading, templates, CRTP) or at run time (virtual functions). Polymorphism does not need inheritance.

Why. Interviewers want each pillar tied to a mechanism and a caveat, not four definitions recited. Templates, std::function and std::variant give polymorphism with no common base class, and a non-virtual or private base gives inheritance with no polymorphism. C++ is multi-paradigm, so a design can use only some of the pillars. A frequent weak answer treats abstraction and encapsulation as synonyms; the previous drill separates them.

Answer. An abstract class is any class with at least one pure virtual function, declared or inherited and not overridden. An "interface" is only a convention: an abstract class with nothing but pure virtual functions, a virtual (or protected) destructor and no data. So yes, an abstract class can have constructors, data members, non-virtual functions and implemented virtual functions. You just cannot create an object of it, or pass or return one by value.

Why. Derived constructors call the abstract base's constructor to initialise its part, so the constructor is useful (make it protected, since only derived classes can call it anyway). The common wrong answer is "an abstract class cannot have a constructor because it cannot be instantiated". Use pure interfaces at module boundaries and for multiple inheritance, because without data there is nothing to duplicate in a diamond. Use an abstract class with state for shared implementation, as in the template method and NVI idioms (Ch 2).

Answer. operator=, operator(), operator[], operator-> and conversion operators must be members ([over.oper]). A member operator<< would make your object the left operand, so you would have to write obj << std::cout.

Why. For a member operator, the left operand is the object the function is called on. Streams put the stream on the left, and you cannot add members to std::ostream, so the printing operator must be a non-member, usually a hidden friend. The reason these five must be members is that the language wants them tied to the class (for example, a non-member operator= could change the meaning of assignment for a type from outside). Many candidates also list +=: it should be a member by convention, but a non-member operator+= is legal.

Answer. The int is a dummy tag that lets prefix and postfix overload each other. It returns by value because it must return the old value, which no longer exists in the object. It should not return const T in modern C++.

Why. Prefix returns T& to the incremented object. Postfix must copy the old state first, so it returns that copy. Older books recommended const T to make it++++ fail to compile, but a const return value cannot be moved from, which costs a copy wherever the result is used. Some style guides still say "return const for postfix", so be ready to explain the trade-off; the C++ Core Guidelines and the standard library return plain T. The copy is also why ++it is preferred for non-trivial iterators.

Answer. All three compile in C++20: the compiler rewrites != as !(==) and also tries operands in reversed order. A user-written operator<=> does not provide ==; only a defaulted <=> implicitly declares a defaulted ==.

Why. [over.match.oper]/3 adds rewritten candidates: for x != y, x == y and y == x; for x < y, (x <=> y) < 0 and 0 < (y <=> x). Equality is deliberately separate from ordering because it can often be faster (two strings of different length are unequal without comparing characters). In C++17 you needed four functions for the four expressions above. A pitfall from the reversal: a member bool operator==(const T&) that forgot its const makes a == b formally ambiguous with its own reversed form in C++20; GCC and Clang accept it with a warning (Clang's -Wambiguous-reversed-operator), but code that was clean in C++17 starts warning. Make comparison operators const or hidden friends.

Answer. mutable members, anything a member pointer or reference points to (constness is shallow), static members, globals, and other objects reached through parameters. It can also const_cast away const, which is defined only if the object itself was not created const.

Why. const on a member function only changes this to const T*, so the members of *this become const: a member int* p becomes int* const p, and *p = 1 still compiles. Modifying an object that was defined const (for example a global const Widget w;) through a const_cast is undefined behaviour, and the compiler may have placed it in read-only memory. The design rule is logical constness: callers must not observe a change, and a mutable cache written from a const function must be synchronised because const functions are assumed safe to call concurrently.

Answer. It has no this, so it can be called without an object (T::f()) and cannot use non-static members directly. It can access private members of any T object it is given. It cannot be const, volatile, ref-qualified or virtual.

Why. const and ref-qualifiers describe the implicit object, and virtual dispatches on it; without an object neither means anything. Access control is per class, so a static factory can call a private constructor. A pointer to a static member function is an ordinary function pointer (usable as a C callback), unlike a pointer to a non-static member function. People often wrongly say a static member function cannot touch private members.

Answer. Dynamic initialisation of namespace-scope statics in different translation units happens in an unspecified order, so a global constructor that uses a global from another file may see it before it is constructed. Fixes: make the dependency constexpr or constinit, construct it on first use with a function-local static, or remove the global. Function-local static initialisation is thread-safe since C++11 ([stmt.dcl]/4).

Why. Across units the order depends on the link order, so the bug comes and goes with build changes. A function-local static is initialised when control first passes through its declaration, behind a guard variable and a lock (__cxa_guard_acquire), so concurrent first calls block until one finishes. The often-forgotten half is destruction, in reverse order of construction completion, so one static's destructor can touch an already destroyed static. A common slip: constinit does not make the variable const; it only guarantees there is no dynamic initialisation to order.

Answer. None of the three: not inherited, not transitive, not symmetric. Used properly, it does not break encapsulation, because the class itself names exactly which functions may see its representation.

Why. A friend function such as operator<< is part of the class's interface that happens to need non-member syntax; making it a friend is no worse than making it a member. Stroustrup's phrasing: friendship is granted, not taken. It becomes a problem when a class befriends an unrelated class to avoid designing an interface, because then changes to the representation can break code far away. Hidden friends (defined inside the class) are the preferred form for operators.

Answer. No. It is a violation when Rectangle is mutable with independent set_width and set_height. If rectangles are immutable values, a square satisfies every promise a rectangle makes, and the inheritance is fine.

Why. Liskov substitution is about behavioural contracts, not real-world taxonomy. The mutable rectangle's contract includes "setting the width leaves the height unchanged", which a square cannot honour. Remove the setters and the only promises left (it has a width, a height and area() == w * h) hold for squares. The common wrong answers are "always a violation because squares have one side" and "never, because a square is a rectangle in maths". Both miss that the answer depends on the operations.

Answer. Default to composition for reuse. Use public inheritance only when the derived type is truly substitutable for the base (Liskov holds) and you need run-time polymorphism through a base pointer or reference, typically from an interface or an abstract class designed for extension.

Why. Composition depends only on the member's public interface, so it survives changes to the member's implementation, lets you hold several or swap implementations, and exposes only what you forward. Inheriting for code reuse couples you to how the base calls its own virtual functions (the fragile base class problem in the reading drills) and exposes every public base member on your type. Private inheritance is the middle ground for "implemented in terms of" when you need to override a virtual function of the helper (Ch 2).

Answer. The implicitly defined destructor is generated inline in each client's translation unit, where Impl is incomplete, and it instantiates std::default_delete<Impl>::operator(), which static-asserts that the type is complete. Fix: declare ~Widget(); in the header and define Widget::~Widget() = default; in the .cpp after Impl is defined. Do the same for the move operations.

Why. delete on a pointer to an incomplete class type is undefined if the class has a non-trivial destructor, so std::unique_ptr turns that into a compile error. Defining the special members out of line moves the instantiation to the one file where Impl is complete. std::shared_ptr<Impl> would compile without this because it captures the deleter when constructed, which happens in the .cpp, but it also gives the class shared semantics, which is usually wrong.

Answer. CRTP cannot choose the type at run time or store different derived types in one container, because Shape<Square> and Shape<Circle> are unrelated types. To catch the wrong template argument, make the base constructor private and declare friend Derived;, so only the named derived class can construct it.

Why. With the wrong argument, static_cast<const Square&>(*this) inside the base is applied to a Circle, which is undefined behaviour that usually reads garbage. With a private constructor, Circle's constructor cannot call Shape<Square>() and compilation fails. For a heterogeneous collection of CRTP types, combine them with std::variant and std::visit, or add a thin virtual interface on top. A third limitation: if the derived class forgets to implement the function and it has the same name as the base one, the base calls itself recursively for ever, which is why implementations often use a distinct name such as area_impl.

Answer. Yes. It is safe if the object was allocated with plain new (not new[], not on the stack, not as a member or inside a container), nothing in the function touches members or calls virtual functions after the delete, and no other code uses the object afterwards.

Why. After delete this, this is a dangling pointer, but the function's code is still valid and can return. Intrusive reference counting does exactly this: void release() { if (--refs_ == 0) delete this; }. To force heap allocation, make the destructor private or protected so stack objects fail to compile. Interviewers sometimes follow up with "can this be null?": not in a valid program, because calling a member function through a null pointer is already undefined behaviour.

Answer. Cannot: ::, ., .*, ?:, sizeof, alignof, typeid and the cast keywords. Should not: &&, || and , (they lose short-circuiting and built-in sequencing semantics) and unary & (it breaks taking addresses).

Why. The non-overloadable ones either take a name rather than a value as an operand (., ::) or are needed to reason about any type (sizeof). An overloaded && is a function call, so both operands are evaluated before the call. Libraries that overload them (Boost.Spirit's ,, expression templates) do so for embedded languages, never for ordinary value types. Generic code uses std::addressof to be robust against overloaded &.

pre post pre
0 2 2
pre pre
4

Why. c++ runs the postfix operator, which saves the old value, calls the prefix operator (printing pre) and then prints post, returning the old n == 0. ++c prints pre and returns a reference to c, which is copied into b with n == 2. ++++c works because prefix returns a non-const reference, so the second increment applies to c itself, giving 4. With postfix, c++++ would increment a temporary and leave c unchanged by the second step.

Answer. It returns a reference to a local variable that is destroyed when the function returns, so c dangles. Binding the result to const Vec& in main does not extend anything: lifetime extension applies only to temporaries bound directly, not to a reference returned from a function.

Why. GCC warns with -Wreturn-local-addr and, since the behaviour is undefined, compiles the function to return a null pointer, so the program crashes; Clang warns with -Wreturn-stack-address and may print garbage or the "right" answer by luck. Arithmetic operators produce new values, so the canonical signature returns by value: Vec operator+(Vec a, const Vec& b) { a.x += b.x; a.y += b.y; return a; }. Returning a value is cheap thanks to copy elision (Ch 23).

mutable const const
20 1

Why. The overload is chosen by the constness of the object expression, not by whether the result is read or written. r is non-const, so r[1] uses the mutable overload. cr and the parameter r inside first are const references, so they use the const overload, even though they refer to the same non-const object. A common wrong answer is that "reading uses the const version": int x = r[0]; on a non-const r still calls the mutable one.

2 1
000

Answer. std::set never calls ==. It treats a and b as the same key when !(a < b) && !(b < a), and this operator< looks only at x, so {1, 3} counts as a duplicate of {1, 2} and is dropped, and count({1, 99}) finds a "match". Meanwhile == says p and q differ, so the type has two inconsistent notions of sameness.

Why. Ordered containers and algorithms use equivalence derived from the comparator, not equality. The fix is to compare every member that == compares, in a fixed order: friend auto operator<=>(const Point&, const Point&) = default;, which also keeps == consistent, or std::tie(a.x, a.y) < std::tie(b.x, b.y) before C++20. The common wrong answer is "the set uses == to detect duplicates". A worse variant, a.x < b.x || a.y < b.y, is not a strict weak ordering at all, and using it in a std::set is undefined behaviour.

11
0
10

Why. A defaulted <=> compares members lexicographically in declaration order. 1.10.0 > 1.9.7 because the minor field 10 is greater than 9 (which a string comparison of "1.10.0" and "1.9.7" would get wrong). Player compares name first, so "bob" < "alice" is false and the score is never looked at: member order is part of the meaning. For double, <=> returns std::partial_ordering, and any comparison with NaN is unordered, so 1.0 < NaN is false.