Design Patterns Quick-Strike for C++ Interviews
In modern C++, we never guess what the compiler does. We look directly at byte offsets, CPU registers, and object ownership lifetimes.
Section 6.7 of the C++11 standard mandates that if control enters the declaration of a local static variable concurrently while the variable is being initialized, the concurrent execution shall wait until the initialization completes. Compilers like GCC, Clang, and MSVC implement this using an internal 8-byte guard variable in .bss and atomic operations (__cxa_guard_acquire and __cxa_guard_release). The first thread acquires the guard, runs the constructor, and sets the guard bit; other threads wait on a futex/event. Subsequent reads check the guard with a single acquire branch without mutex overhead.
Because std::unique_ptr is move-only, the enclosing class becomes move-only by default. You must:
- Declare
~Widget();in the header, and defineWidget::~Widget() = default;in.cppafterImplis complete. - Declare move constructor
Widget(Widget&&) noexcept;and move assignmentWidget& operator=(Widget&&) noexcept;in the header, defining both as= defaultin.cpp. - If copy semantics are desired, implement deep copying manually in
.cpp(pimpl_ = std::make_unique<Impl>(*other.pimpl_)), as compiler-generated copy is deleted bystd::unique_ptr.
Raw pointers (IObserver*) become dangling pointers if an observer is deleted, causing segmentation faults on notify(). Storing std::shared_ptr<IObserver> keeps the observer alive forever even if the rest of the application discarded its reference, causing silent memory leaks and zombie notifications. std::weak_ptr<IObserver> breaks ownership: it tracks the control block without incrementing strong_count. wp.lock() safely returns null if the observer has expired, allowing automatic pruning during notification.
Interviewer's lens
Interviewers don't test design patterns in C++ to hear Java textbook definitions; they want to see if you understand C++ memory ownership, compile-time vs runtime costs, and lifetime safety. Weak candidates write thread-unsafe singletons with raw pointers, create circular memory leaks with std::shared_ptr observers, and trigger compiler errors with incomplete types in Pimpl destructors. Strong candidates immediately deploy thread-safe Meyers' Singletons, leak-free std::weak_ptr observers with auto-pruning, zero-overhead C++20 concept policies, and explain the exact ABI and compilation firewall mechanics of the Pimpl idiom.
Under the hood & memory layout
Every C++ design pattern manifests as a distinct physical machine layout: Meyers' Singleton relies on a compiler-generated 8-byte guard variable (__cxa_guard_acquire / __cxa_guard_release) in the .bss section, guaranteeing single-execution thread safety with zero mutex overhead after initial initialization. Runtime polymorphism (Factory, Strategy, Decorator) incurs an 8-byte vptr in each object pointing to a vtable in .rodata, requiring two pointer dereferences per call. In contrast, compile-time policy strategies instantiate template code directly, allowing -O2 to inline behavior directly into the caller frame with zero runtime bytes. Observer with std::weak_ptr avoids circular retention by inspecting the 16-byte control block's strong_count without incrementing it. Pimpl shrinks the visible class to a single 8-byte std::unique_ptr<Impl>, freezing class size across ABI boundaries.
Under the Itanium ABI, a local static object possesses an associated 64-bit guard variable in .bss. The first calling thread executes an atomic test-and-set acquire barrier; subsequent calls bypass initialization with a single branch instruction.
A runtime strategy requires an 8-byte heap pointer + 8-byte object vptr + non-inlinable dynamic dispatch. A C++20 concept policy generates monomorphic code where the compiler can inline the algorithm directly with 0 vtable overhead.
Storing std::weak_ptr<IObserver> occupies 16 bytes (8B raw pointer + 8B control block pointer). It increments weak_count but leaves strong_count untouched. When strong_count drops to 0, the observer's destructor runs immediately.
The public class contains only std::unique_ptr<Impl> (8 bytes). Adding or modifying private members inside struct Impl in the .cpp file preserves sizeof(Host) and member offsets, eliminating header recompilation across dependent translation units.
Core concepts & syntax traps
Thread-Safe Meyers' Singleton & The Dependency Injection Trade-Off
Thread-Safe Meyers' Singleton & The Dependency Injection Trade-Off
In C++11 and beyond (§6.7 [stmt.dcl]), static local variables with initializers are guaranteed to be initialized thread-safely upon first execution. This is known as Meyers' Singleton. The compiler emits atomic guard instructions so multiple threads racing to call getInstance() synchronize safely without explicit locks. To guarantee uniqueness, you must delete both the copy constructor and copy assignment operator, as well as the move operations. However, in production architectures, singletons introduce hidden global state and hinder unit testing; modern systems prefer Dependency Injection (DI) where dependencies are passed explicitly as std::shared_ptr or references.
class DatabaseConfig {
public:
static DatabaseConfig& instance() {
static DatabaseConfig inst; // Thread-safe since C++11
return inst;
}
DatabaseConfig(const DatabaseConfig&) = delete;
DatabaseConfig& operator=(const DatabaseConfig&) = delete;
private:
DatabaseConfig() { /* heavy init */ }
};Never write raw pointer double-checked locking; use Meyers' Singleton or inject instances via Dependency Injection.
Factory Method & Self-Registering Plugin Registry
Factory Method & Self-Registering Plugin Registry
A classic Factory Method creates objects through an interface without coupling callers to concrete classes. In modern C++, factories return std::unique_ptr<Interface>, establishing unambiguous move-only heap ownership. To make a factory extensible without modifying its switch statements, use a Self-Registering Registry: concrete classes register a factory lambda into an internal std::unordered_map<std::string, Creator> using a static helper object before main() executes.
class WidgetFactory {
public:
using Creator = std::function<std::unique_ptr<IWidget>()>;
static WidgetFactory& instance() { static WidgetFactory f; return f; }
void registerWidget(std::string_view name, Creator c) { map_[std::string(name)] = std::move(c); }
std::unique_ptr<IWidget> create(std::string_view name) const {
auto it = map_.find(std::string(name));
return (it != map_.end()) ? it->second() : nullptr;
}
private:
std::unordered_map<std::string, Creator> map_;
};Return std::unique_ptr<T> from factories; use a self-registering map to eliminate OCP-violating switch statements.
Strategy Pattern: Runtime Polymorphism vs Compile-Time C++20 Concepts
Strategy Pattern: Runtime Polymorphism vs Compile-Time C++20 Concepts
The Strategy pattern decouples an algorithm from its enclosing context. C++ offers two architectural options:
- Runtime Strategy (
std::unique_ptr<IStrategy>): Flexible dynamic swapping at runtime at the cost of heap allocation, pointer indirection, and non-inlinable virtual table calls. - Compile-Time Strategy (Policy-Based Design with C++20 Concepts): The algorithm is parameterized as a template argument constrained by a
concept. The compiler resolves dispatch at compile-time with zero heap allocation, zero vptr overhead, and aggressive function inlining.
// Runtime Strategy:
struct ISort { virtual ~ISort() = default; virtual void sort(std::span<int>) = 0; };
// Compile-Time Policy (C++20 Concept):
template <typename T>
concept SortPolicy = requires(T s, std::span<int> data) { { s.sort(data) } -> std::same_as<void>; };
template <SortPolicy Policy>
class Dataset { Policy policy_; public: void run(std::span<int> d) { policy_.sort(d); } };Use runtime strategy when behavior must swap dynamically based on config; use C++20 policy concepts for high-frequency low-latency code.
Observer Pattern with std::weak_ptr (Preventing Memory Leaks & Dangling References)
Observer Pattern with std::weak_ptr (Preventing Memory Leaks & Dangling References)
The classic Observer interview trap asks: "What happens if an observer is deleted while registered with the Subject?"
- If the Subject stores raw pointers (
IObserver*), callingnotify()causes a catastrophic dangling pointer use-after-free crash. - If the Subject stores
std::shared_ptr<IObserver>, the Subject keeps listeners alive indefinitely, creating memory leaks and circular references. The Senior C++ Solution: The Subject storesstd::vector<std::weak_ptr<IObserver>>. Insidenotify(), the Subject attempts promotion withwp.lock(). Ifwp.expired(), the observer was deleted elsewhere, andstd::erase_ifprunes it from the list automatically!
void notify(std::string_view msg) {
std::erase_if(observers_, [&](const std::weak_ptr<IObserver>& wp) {
if (auto sp = wp.lock()) {
sp->onEvent(msg);
return false; // Retain active observer
}
return true; // Auto-prune expired observer!
});
}Always store std::weak_ptr in event broadcasters to prevent circular memory leaks and dangling callback crashes.
Decorator & Adapter Patterns in Modern C++
Decorator & Adapter Patterns in Modern C++
The Decorator pattern attaches additional responsibilities to an object dynamically by wrapping std::unique_ptr<IComponent> and forwarding calls while injecting cross-cutting behavior (logging, encryption, rate-limiting, compression). The Adapter pattern converts an incompatible existing class interface into a target interface expected by callers without altering the underlying class.
class EncryptionDecorator : public IDataStream {
std::unique_ptr<IDataStream> wrapped_;
public:
explicit EncryptionDecorator(std::unique_ptr<IDataStream> w) : wrapped_(std::move(w)) {}
void write(std::string_view s) override {
std::string enc = encrypt(s);
wrapped_->write(enc);
}
};Decorators wrap the same interface to augment behavior; Adapters bridge two different interfaces.
The C++ Pimpl Idiom & The unique_ptr Destructor Trap
The C++ Pimpl Idiom & The unique_ptr Destructor Trap
The Pimpl (Pointer to Implementation) idiom hides private data members and heavy third-party #include headers behind a forward-declared struct Impl; and a std::unique_ptr<Impl> pimpl_;.
Benefits: Fast compilation (client files do not recompile when private members change) and stable ABI.
The Destructor Trap: If you write ~Widget() = default; in Widget.h, the compiler generates the destructor code at the header call site. At that point, struct Impl is incomplete! std::unique_ptr<Impl>::~unique_ptr requires a complete type to invoke sizeof(Impl) inside delete. This fails with a static assertion or compiler error. Rule: Always declare ~Widget(); in the header, and define Widget::~Widget() = default; in the .cpp file after struct Impl is fully defined!
// Widget.h
class Widget {
public:
Widget();
~Widget(); // MUST NOT be = default in .h!
Widget(Widget&&) noexcept;
Widget& operator=(Widget&&) noexcept;
private:
struct Impl;
std::unique_ptr<Impl> pimpl_;
};
// Widget.cpp
struct Widget::Impl { std::string cache; /* heavy libs */ };
Widget::Widget() : pimpl_(std::make_unique<Impl>()) {}
Widget::~Widget() = default; // Legal here because Impl is complete!With Pimpl, always define destructors and move operators in the .cpp file where the Impl struct is complete.
Unlock Live Implementation & Interview Scenarios
The C++23 production code, live coding steps, scenario twist solutions, and common UB traps are part of Brute2Best Pro. Module 1 is completely free.
First anchor question per pattern, Part 1 LLD & Module 1 C++ basics are 100% Free forever.