C++ Interview Questions: Practice Real Technical Interview Problems

RAII ties resource acquisition to object construction (resource acquisition being tied to object construction) and resource release to object destruction (resource release being tied to object destruction), giving deterministic cleanup (deterministic cleanup). It does not rely on a garbage collector (the claim that RAII depends on a garbage collector is wrong) — destructors run at well-defined times such as when a stack object goes out of scope or a heap object is deleted.

This is a foundational C++ recall question. The Rule of Three states that any class that needs a user-defined destructor, copy constructor, or copy assignment operator needs all three, because the compiler-generated versions only do member-wise (shallow) copies that are unsafe for owned resources.

A stack-allocated object's destructor is invoked automatically at end of scope, so no explicit delete is needed — "It requires an explicit delete expression to destroy it when it goes out of scope" is wrong — delete is for heap objects. Its destructor can release a resource such as a file handle or lock, which is the essence of RAII. The constructor executes at the point of declaration, before the subsequent statements in the block.

p1 is constructed first, printing A() . Inside the inner block, p2 is constructed, printing A() . When the block ends, p2 (a unique_ptr) is destroyed, which deletes its object and prints ~A() . Then end is printed. Finally, when main returns, p1 is destroyed, printing ~A() .

RAII binds a resource — heap memory, a file handle, a mutex lock, a socket — to the lifetime of a stack-allocated object: the constructor acquires it, the destructor releases it. Because C++ guarantees local objects' destructors run during stack unwinding (including when an exception propagates through the scope), RAII gives automatic, exception-safe cleanup with no explicit finally-style block. std::unique_ptr, std::lock_guard, and std::fstream are all RAII wrappers around a raw resource. The other options describe unrelated or incorrect properties: RAII says nothing about constness, doesn't guarantee zero overhead, and specifically exists so cleanup happens at scope exit, not merely at program exit.

std::unique_ptr models exclusive ownership: it can be moved (transferring ownership) but not copied, and because only one unique_ptr ever owns the object, it needs no reference count — just a raw pointer and a deleter, making it effectively as cheap as a raw pointer while still freeing automatically. std::shared_ptr is for the different case of multiple simultaneous owners, and pays for an atomically-updated control block to track them. std::weak_ptr doesn't own anything — it exists to observe a shared_ptr-managed object without extending its lifetime, typically to break reference cycles. A raw pointer with manual delete reintroduces exactly the leak/double-free risk smart pointers exist to remove, so it's never the right answer to a memory-safety question even though it technically avoids smart-pointer bookkeeping.

True. const on a member function is a promise not to modify the object's logical state through that function — the compiler enforces this by making this a pointer-to-const inside the function, so any member normally can't be assigned to. mutable is the deliberate escape hatch: it marks a member (typically bookkeeping like a cache, a lazily-computed value, or a mutex used only for internal synchronization) as modifiable even through a const object or const member function. It exists precisely so a class can present a const, logically-immutable public interface while still doing internal caching under the hood.

RAII is the core C++ idiom for deterministic resource cleanup, and it's the reason C++ code that uses smart pointers and standard containers rarely needs manual cleanup code at all.

Self-assignment must be checked first; otherwise the next step would delete[] the very memory you still need. Releasing old resources second prevents leaks. Copying the source's resources third gives the object its new valid state. Returning *this last follows the convention that allows chaining like a = b = c.

The Rule of Three dates to C++98/03: a class managing resources needs a destructor, copy constructor, and copy assignment operator. C++11 introduced move semantics, expanding the guidance to the Rule of Five by adding the move constructor and move assignment operator. The Rule of Zero is the modern best-practice refinement that emerged with widespread RAII types (smart pointers, std::vector, etc.): by composing members that manage their own resources, the compiler-generated defaults are correct and no manual special member functions are needed.

When you don't declare copy/move operations yourself, the compiler generates member-wise ones: for a raw pointer, that's a shallow copy of the address, not a deep copy of the pointed-to array. Copy (or default-generated move) then leaves two objects holding the same pointer; when both destructors run, the array is freed twice — undefined behavior, often a crash. The rule of three says if you need a custom destructor, copy constructor, or copy assignment, you likely need all three; the rule of five (C++11+) adds move constructor and move assignment for the same reason, since the implicitly-generated move would also just shallow-copy the pointer and leave the moved-from object still pointing at freed memory once destroyed. In practice, the preferred fix in modern C++ is the 'rule of zero' — hold the array in a std::vector<int> or std::unique_ptr<int[]> member instead, so the compiler-generated special members are already correct and no manual rule-of-five boilerplate is needed at all.

std::move is purely a cast (static_cast<T&&>) — it has no runtime effect of its own; it just makes the expression an rvalue so overload resolution can select a move constructor or move-assignment operator if one exists. A well-behaved move constructor steals the source's internal resource (pointer, buffer, handle) rather than deep-copying it, typically by copying the pointer and nulling the source's, which is what makes moves cheap for resource-owning types like std::vector or std::string. That's why the moved-from object is left 'valid but unspecified' — it's safe to destroy, reassign, or call methods with no preconditions on it, but its value is not to be relied upon. The claim that moving is guaranteed to be faster than copying for every type and the claim that std::move always triggers a move are wrong: nothing in the standard requires move to be O(1) for every type (a type with no move constructor falls back to its copy constructor, which may be O(n)), and passing an rvalue to a type with no move constructor simply resolves to the copy constructor instead of failing to compile.

This question separates candidates who've memorized 'rule of five' as a term from those who understand the mechanism: it's about the compiler-generated special members doing the wrong thing (shallow pointer copies) for a class that owns a raw resource, and a manually-managed resource needing all five to be considered together — destructor, copy ctor/assign, move ctor/assign — even if the right answer for some of them is to delete them. The strongest answers also mention the rule of zero, since in real production C++ the goal is almost always to avoid needing the rule of five at all by composing RAII types instead of manually managing raw resources.

The precise, interview-worthy answer is about mechanism, not speed as an unexplained fact: a copy duplicates the underlying data; a move transfers ownership of it (steals the pointer/buffer, nulls out the source) and is typically O(1) instead of O(n) for heap-owning types. Grounding it in a concrete case — returning a large container by value, or constructing from a temporary — shows the candidate understands where this actually shows up in real code, not just the vocabulary.

The vptr/vtable mechanism is what makes runtime polymorphism possible in C++ with no built-in reflection: dispatch is a pointer indirection through the object's own vptr, which is also why object slicing (copying only the base subobject) loses the derived vtable and breaks polymorphic behavior.

C++ guarantees a fixed construction order for a derived object: base classes first (in the order they're listed in the class definition, not the initializer list), then non-static data members (in declaration order within the class, again regardless of initializer-list order), and only then does the derived class's own constructor body run. This matters in practice for a well-known gotcha: calling a virtual function from a base class constructor does NOT dispatch to a derived override, because at that point in construction the object's vptr still points at the base class's vtable — the derived part of the object doesn't exist yet. Destruction runs in the exact reverse order: derived destructor body, then members (reverse declaration order), then base classes (reverse order), which is also why a base class needs a virtual destructor to correctly destroy a derived object through a base pointer.

After main returns, a and b are destroyed. a's refcount drops to 1 (held by b->prev) and b's refcount drops to 1 (held by a->next), so neither block is actually freed — a classic circular reference. The fix is to change line 6 so that prev is declared as std::weak_ptr<Node>, breaking the ownership cycle. weak_ptr does not contribute to the reference count, so when main ends both refcounts reach 0 and the destructors run.

True. shared_ptr uses reference counting, and a cycle means each object's count includes a reference from the other object in the cycle. Even after every external shared_ptr to the cycle goes away, each object inside the cycle still holds a count of at least one (from its partner), so neither reference count ever drops to zero and neither destructor ever runs — a real leak, not just a delayed free. The standard fix is to make one direction of the relationship a std::weak_ptr instead (e.g., a child holding a weak_ptr back to its parent): weak_ptr observes the object without contributing to its reference count, so it doesn't keep the cycle alive, and it can be .lock()ed into a temporary shared_ptr only while the object is still known to exist.

word is a local variable with automatic (stack) storage duration — it's destroyed when firstWord returns. Returning word by reference (line 3) hands the caller a reference to storage that no longer holds a valid std::string; that's a dangling reference, and using it (line 8's std::cout << w) is undefined behavior — it might print garbage, print the old value by luck (if the memory hasn't been reused yet), or crash, and the exact outcome can differ by compiler, optimization level, and what else is on the stack. Note that line 7 itself is legal C++ — binding a reference to a temporary would normally extend a temporary's lifetime, but that extension does not apply here because the dangling reference was already produced inside firstWord, before the caller ever sees it. The fix is to return std::string by value (not by reference); modern C++'s move semantics and guaranteed copy elision (C++17) make that no more expensive than the broken reference version, so there's no performance reason to reach for the reference here.

Polymorphism through virtual functions only works through a pointer or reference to the base class, because dispatch relies on the object's vptr pointing at its actual (dynamic) type's vtable. printArea(Shape s) takes its parameter by value, so the call printArea(c) invokes Shape's copy constructor with a Circle argument — and a Shape copy constructor only knows how to copy the Shape subobject. The radius member and the Circle vtable pointer are left behind entirely; s inside printArea is a genuine, fully-formed Shape, not a truncated Circle, so s.area() correctly (if surprisingly) calls Shape::area(). This is 'object slicing.' The fix is to take the parameter by reference or pointer (void printArea(const Shape& s)), which binds to the existing Circle object instead of copying it, preserving its vtable and dynamic type.

The C++ standard guarantees that when a constructor exits via an exception, every subobject (base classes and non-static data members) that has already been constructed is destroyed in reverse order of construction. This is the core RAII guarantee: partially constructed objects never leave their already-constructed parts undestroyed. The destructor body of the throwing class itself is NOT invoked (since the object never fully constructed), but the sub-object destructors are.

std::make_shared performs a single heap allocation that contains both the control block (strong/weak counts, deleter, allocator) and the managed object. When the strong count hits zero the destructor runs, but the memory for the object cannot be returned to the allocator because it lives inside the same block as the control block, which must survive for any outstanding weak_ptr. Only when the weak count also reaches zero does the allocator free the combined block. In contrast, std::shared_ptr<T>(new T) performs two allocations: one for the object (via new) and one for the control block. When the strong count hits zero the object's memory is freed immediately (via delete), and the control block is freed separately when the weak count reaches zero.

std::enable_shared_from_this<T> exposes a shared_from_this() member that works by calling lock() on an internal mutable std::weak_ptr<T> member (named weak_this in typical implementations). That weak_ptr is populated only when a shared_ptr constructor takes ownership of the object — the constructor detects the enable_shared_from_this base (via a is_convertible trait check) and, if the internal weak_ptr is empty, stores a weak_ptr aliasing the newly created control block. If no shared_ptr has ever owned the object, weak_this remains default-constructed (empty), so lock() returns a null shared_ptr. The standard-library implementation observes this null result and throws std::bad_weak_ptr.

std::move_if_noexcept<T> returns T&& when is_nothrow_move_constructible_v<T> is true (or when T is not copy-constructible), and const T& otherwise. The vector reallocation logic uses this so that elements whose move could throw are copied, preserving the original buffer untouched until the full transfer succeeds—giving push_back its strong exception guarantee. A noexcept move constructor allows elements to be moved for performance with no risk.

g takes a forwarding reference T&&. For g(a), a is an lvalue of type int, so T deduces to int&; reference collapsing makes x an int&, and std::forward<int&>(x) yields an lvalue, selecting h(int&) → A. For g(b), b is an lvalue of type const int, so T deduces to const int&; std::forward<const int&>(x) yields a const int& lvalue, and only h(const int&) is viable → B. For g(3), the prvalue causes T to deduce to int; x is int&& and std::forward<int>(x) yields an xvalue, selecting h(int&&) → C. For g(std::move(a)), std::move(a) is an xvalue, so T again deduces to int; std::forward<int>(x) yields an xvalue, selecting h(int&&) → C. The output is ABCC.