Back to interview questions
By
Team Sherlock.sh
C++ interviews should reveal how a candidate reasons about object lifetime, ownership, abstraction, and the cost of execution. Knowing syntax is not enough: a developer must explain which object owns a resource, when an iterator becomes invalid, how an exception affects state, and why apparently correct concurrent code may still contain a data race. These distinctions matter in services, libraries, desktop applications, and performance-sensitive systems.
This collection progresses through 120 questions in three levels, from language and standard-library foundations to practical implementation and senior engineering decisions. Its focus is modern C++ programming rather than embedded-C hardware details or a general catalog of object-oriented design principles. Use the code and changed-assumption follow-ups to test reasoning, not memorization of compiler output or claims that one abstraction is always fastest.
How can recruiters assess whether a C++ candidate truly understands the lifetime and concurrency risks behind a working-looking solution?
Ask the candidate to trace ownership, identify which references survive a container operation, or justify the synchronization in a small producer-consumer example. Then change one constraint and ask what would fail and how they would test it.
Sherlock AI helps recruiters assess signals of potential AI cheating, deepfakes, impersonation, and unauthorized assistance during interviews.
Use those signals alongside code walkthroughs and technical follow-up, not as conclusive proof of misconduct. A strong candidate distinguishes language guarantees from implementation behavior and explains where their evidence stops.
C++ Interview Questions
Use this complete question bank to select a balanced interview before reading the answers. State the language version and relevant ownership, threading, and error-handling assumptions so candidates can reason against a clear contract.
C++ Interview Questions for Beginners
These questions establish the foundations: compilation, initialization, object lifetime, classes, ownership, containers, and basic generic programming.
How does modern C++ differ from C?
What happens between a C++ source file and an executable?
What should you know about the sizes and ranges of fundamental types?
Why is initialization different from assignment, and how do braces help?
How do const and constexpr differ?
What does auto deduce, and when can it hide an unintended copy?
How are pointers and references different?
Why should C++ code prefer nullptr to zero or NULL for null pointers?
When should a function take a value, a const reference, or a mutable reference?
How do scope, storage duration, and object lifetime differ?
What is RAII, and why is it useful beyond memory management?
What is the practical difference between struct and class?
Why do constructors use member initializer lists?
What does a destructor do, and when is it called?
What is the difference between copying and moving an object?
What is the rule of zero?
When should you use unique_ptr?
When is shared_ptr appropriate, and what does it cost?
How does weak_ptr help with shared ownership cycles?
How should inheritance differ from composition in a basic design?
What do virtual functions and override do?
Why may a base class need a virtual destructor?
How are function overloading and overriding different?
What is object slicing, and how do you avoid it?
How do exceptions interact with automatic objects?
When would you choose vector rather than array?
How do string and string_view differ?
What is an iterator, and why is end not an element?
How does a range-based for loop choose copies or references?
Why use standard algorithms instead of writing every loop manually?
What is a lambda, and what do its captures mean?
What problem does a function template solve?
Why are namespaces useful, and why avoid using namespace std in headers?
What is the difference between a declaration and a definition?
What do include guards prevent, and what do they not prevent?
What is the one-definition rule at a beginner level?
Why prefer named casts to C-style casts?
Why use enum class instead of an unscoped enum?
What is undefined behavior, and how is it different from unspecified behavior?
How would you investigate a small C++ program that sometimes crashes?
C++ Interview Questions for Intermediate
These questions test implementation judgment in move semantics, deduction, constraints, iterator validity, vocabulary types, views, exceptions, and synchronization.
How do lvalues, xvalues, and prvalues affect overload resolution?
Why can std::move copy a const object instead of moving it?
What makes T&& a forwarding reference rather than an ordinary rvalue reference?
How does std::forward preserve the caller's value category?
Which return-value optimizations are guaranteed in C++17, and which remain optional?
Why can a user-declared destructor change a class's move behavior?
Why does noexcept on a move constructor matter to vector growth?
When does binding a reference extend a temporary's lifetime, and when does it not?
How would you prevent dangling string_view and span values in an API?
How does explicit prevent surprising conversions in class interfaces?
How should you diagnose an ambiguous overloaded function call?
Why does template argument deduction sometimes fail even when a conversion exists?
When should you use template overloading instead of explicit specialization?
What does SFINAE remove from an overload set, and what does it not protect?
How do C++20 concepts improve a generic interface without proving its semantics?
How does if constexpr differ from a normal if in a function template?
When should you choose constexpr versus consteval?
When is std::function preferable to a templated callable parameter?
What lifetime bugs can lambda captures introduce in asynchronous code?
How do reserve and resize differ, and when does vector invalidate references?
Why must remove_if usually be followed by erase on a vector?
How do map and unordered_map differ beyond their average lookup complexity?
Why can operator[] be the wrong choice for a map lookup?
What properties must a comparator satisfy for std::sort?
When is optional a better return type than a sentinel value?
How should you process a variant safely, and what is valueless_by_exception?
When does any make sense, and what trade-offs does it introduce?
When would you use C++23 expected instead of optional or exceptions?
How do structured bindings change copying and mutation of container entries?
Why can a lazy ranges pipeline behave differently from a materialized container?
What are the basic, strong, and no-throw exception guarantees?
How does copy-and-swap provide exception safety, and when can it be inefficient?
How can a custom deleter make unique_ptr manage a non-memory resource?
How would you design a weak_ptr cache without retaining objects indefinitely?
How does jthread improve thread lifetime management, and what problems remain?
When should you use lock_guard, unique_lock, or scoped_lock?
Why must a condition-variable wait use a predicate?
Why does an atomic counter not automatically make a whole operation thread-safe?
How do error_code overloads change filesystem error handling?
How would you choose between emplace_back and push_back for a vector?
C++ Interview Questions for Experienced
These scenarios probe API contracts, failure atomicity, binary compatibility, object-model rules, performance measurement, memory ordering, cancellation, and production diagnosis.
How would you implement an update that provides the strong exception guarantee?
Why can a destructor or noexcept function turn an exception into process termination?
How would you design an API that makes ownership and borrowing unambiguous?
How do you preserve dynamic type when copying polymorphic objects?
When would you choose type erasure instead of templates or an inheritance-based interface?
How does pImpl help with ABI stability, and what does it not guarantee?
How would you investigate an ODR violation that appears only in optimized builds?
What would you verify before replacing headers with C++20 modules?
How would you reduce template-related build time and binary size without abandoning generic code?
Why can two logically equivalent C++20 constraints fail to order overloads as expected?
What lifetime risks accompany std::pmr containers and a monotonic buffer resource?
How would you diagnose false sharing rather than a true data race?
Why can a contiguous vector outperform a linked list for an insertion-heavy workload?
How would you design a microbenchmark that the optimizer cannot turn into a misleading result?
Why does casting a pointer not make type-punning valid, and when is std::bit_cast useful?
What must be true before constructing an object in manually managed storage?
How can you check signed addition without first triggering signed-overflow undefined behavior?
How do you reason about expressions whose argument evaluation order is unspecified?
When is relaxed atomic ordering sufficient, and what does it fail to publish?
How does a release-acquire handoff safely publish non-atomic data?
Does sequential consistency eliminate the need to reason about a concurrent protocol?
Why must compare-exchange loops handle failure and sometimes recompute their desired value?
What is the difference between a lock-free atomic and a wait-free algorithm?
What is the ABA problem, and why does it make reclamation difficult?
What does C++20 atomic shared_ptr protect, and what remains the caller's responsibility?
How would you prevent deadlocks in code that acquires several locks and invokes callbacks?
How would you design shutdown for a worker pool without losing tasks or hanging?
How can member declaration order make a class with jthread unsafe during construction or destruction?
Why do coroutine suspension points create unusual lifetime bugs?
What does the C++20 coroutine machinery provide, and what must a library supply?
Why can std::async code unexpectedly execute serially or block at scope exit?
What changes when you add a standard execution policy to an algorithm?
How would you investigate a production-only use-after-free without guessing at the fix?
How do AddressSanitizer, UndefinedBehaviorSanitizer, and ThreadSanitizer complement each other?
How would you plan a C++17-to-C++20 or C++23 migration across a large codebase?
Why can returning by value outperform returning a reference or output parameter?
How would you design a zero-copy parser without creating dangling views?
How would you analyze initialization-order problems involving global objects?
How do you evaluate a custom allocator or object pool proposed as a performance fix?
What should a senior C++ reviewer verify before accepting a performance-oriented API redesign?
C++ Interview Questions and Answers
The answers follow the bank in identical order, combining direct explanations with practical examples and trade-offs. Examples use standard C++17 unless explicitly labeled C++20 or C++23. Language and standard-library support must both be checked in the chosen toolchain. Later features are identified rather than assumed; no C++26 behavior is required. Code examples are deliberately small and do not establish performance or portability guarantees.
C++ Interview Questions and Answers for Beginners
Look for a clear account of what an object represents, who owns its resources, and which operations are valid. Vocabulary should connect to a concrete example and a relevant failure mode.
1. How does modern C++ differ from C?
C++ supports procedural programming like C, but also provides classes, templates, overloading, exceptions, and deterministic resource management through constructors and destructors. Modern C++ usually expresses ownership with standard containers and smart pointers instead of scattering allocation and cleanup calls throughout a program. It is not simply C with classes, and valid C source is not automatically valid C++ source. For example, implicit conversion from void* to an object pointer differs. A strong candidate chooses abstractions that make invariants explicit while understanding their costs, rather than assuming that every C++ feature requires dynamic allocation or that every low-level implementation is faster.
2. What happens between a C++ source file and an executable?
A typical toolchain preprocesses each source file and its included headers, compiles the resulting translation unit, and links object files and libraries into an executable. Compilation checks declarations and generates code; linking resolves references to definitions across translation units. A missing declaration normally produces a compiler error, while a declared function with no available definition commonly produces a linker error. Headers do not become separate implementations merely because several files include them. Build systems also select the language standard, include paths, macros, and linked libraries. Diagnose a failure at the stage that reports it instead of treating every build error as a syntax problem.
3. What should you know about the sizes and ranges of fundamental types?
The standard constrains fundamental types without making every width identical across platforms. For example, sizeof(char) is one byte, but a byte is not universally required to contain eight bits, and the width of long varies between common data models. Use <limits> to inspect numeric properties and fixed-width types from <cstdint> when an available exact-width type is required by a representation. Signedness matters when comparing values or converting between signed and unsigned types. A portable interface should specify its data requirements rather than assume that an int, pointer, or serialized structure has the same representation everywhere.
4. Why is initialization different from assignment, and how do braces help?
Initialization establishes an object's initial state; assignment changes an existing object. Prefer initializing a variable when declaring it, so there is no interval in which it holds an unusable value. Brace initialization rejects narrowing conversions covered by the language's list-initialization rules. However, braces are not interchangeable with parentheses for every class: std::vector<int>{3, 7} contains two elements, while std::vector<int>(3, 7) contains three sevens. Choose the form that expresses the intended constructor call. The commented declaration below is intentionally ill-formed because a floating-point value cannot be list-initialized into an integer this way.
5. How do const and constexpr differ?
const prevents modification through the declared const-qualified object or access path; it does not generally mean that a value is known at compile time. A constexpr variable must have a constant-expression initializer and is const. A constexpr function can participate in constant evaluation when its arguments and the evaluated operations permit it, but ordinary calls can also run at runtime. For example, a compile-time array bound can use an appropriate constant expression, while a const integer read from a file cannot supply that bound in standard C++. Neither keyword automatically makes referenced mutable objects deeply immutable or makes shared access thread-safe.
6. What does auto deduce, and when can it hide an unintended copy?
auto asks the compiler to deduce a type from an initializer; it does not introduce dynamic typing. Plain auto generally drops top-level const and reference qualifiers during deduction, so initializing it from a referenced object can create a copy. Use auto& to bind a reference or const auto& for read-only access when that fits the lifetime requirements. For example, auto item = names.front() copies a string, whereas const auto& item = names.front() refers to the existing element. The latter becomes invalid if that element is destroyed or an operation invalidates references. Choose deduction syntax based on ownership and mutation, not merely brevity.
7. How are pointers and references different?
A pointer is an object whose value can designate another object or function, or be null; it can usually be reassigned. A reference is an alias established by initialization and cannot later be rebound to a different referent. Both can become dangling if the designated object's lifetime ends. Use a reference for a required existing object and a pointer when an optional object or pointer-specific operation is meaningful, while documenting ownership separately. A raw pointer does not inherently own its target. Assigning through a reference modifies the referent; assigning a new address to a pointer changes which object the pointer designates.
8. Why should C++ code prefer nullptr to zero or NULL for null pointers?
nullptr has the dedicated type std::nullptr_t and converts to pointer types without behaving like an integer argument. This makes intent clearer and avoids common overload-resolution surprises caused by 0 or an integer-like NULL macro. With overloads accepting int and int*, passing 0 selects the integer overload, whereas nullptr selects the pointer overload. A null pointer still cannot be dereferenced, and checking it does not establish that a non-null pointer remains valid. Prefer value types or references when absence is not part of the interface, rather than making every parameter nullable simply because null pointers are available.
9. When should a function take a value, a const reference, or a mutable reference?
Pass small, inexpensive values such as integers by value. A const reference can avoid copying a larger object when the function only observes it and does not need independent ownership. A mutable reference communicates that the function may change the caller's object. Taking a value can also be a good ownership-taking design when the function needs its own copy and can move from that parameter. These are starting points, not universal performance rules: aliasing, lifetime, moves, and actual measurements matter. Do not retain a borrowed reference beyond the caller's guaranteed lifetime, and do not assume const access prevents another alias from modifying the object.
10. How do scope, storage duration, and object lifetime differ?
Scope describes where a name can be used, storage duration describes how long storage is available, and lifetime describes when an object exists in that storage. They often line up for an ordinary local variable but are not the same concept. A local static variable has block scope and static storage duration. An allocated object can outlive the scope containing the pointer that originally referred to it, although losing its only owning handle can leak it. Returning a pointer or reference to an ordinary local object leaves a dangling result. Reason about the owner's lifetime and invalidation rules, not just whether a name is visible.
11. What is RAII, and why is it useful beyond memory management?
RAII binds resource ownership to an object's lifetime: construction acquires or establishes ownership, and destruction releases the resource. It applies to locks, files, sockets, and transactions as well as allocated memory. Automatic objects are destroyed when their scope exits normally and during ordinary exception unwinding, which avoids duplicating cleanup across return paths. The abstraction should have a clear valid state and a destructor that does not let exceptions escape. RAII is not garbage collection, and it does not promise cleanup after every process termination mechanism. For example, a lock guard releases its mutex when its scope ends without a separate manual unlock on each path.
12. What is the practical difference between struct and class?
struct and class both define class types with constructors, destructors, member functions, inheritance, and access control. Their language-level defaults differ: members and base classes are public by default for struct and private by default for class. A common convention uses a struct for a simple value whose members can sensibly be public, and a class when operations need to preserve an invariant behind a private representation. That is a design convention rather than a restriction. Changing the keyword alone does not alter object-oriented capabilities or guarantee a different memory layout; the actual members, bases, and other language rules determine those properties.
13. Why do constructors use member initializer lists?
A constructor's member initializer list initializes base subobjects and data members before the constructor body runs. Assigning inside the body is not equivalent: a member must first have been initialized, and const members and reference members require suitable initialization rather than later assignment. Members initialize in declaration order, regardless of the written order in the initializer list. Keep those orders aligned to make dependencies visible and heed compiler warnings. Default member initializers are useful for consistent defaults across constructors. A constructor should establish the object's invariant or fail, instead of returning a superficially constructed object whose essential state is invalid.
14. What does a destructor do, and when is it called?
A destructor runs the class's destruction logic; after its body, non-static data members and base subobjects are destroyed in reverse construction order. For an automatic object, this normally happens on leaving its scope. For an object owned by a smart pointer, it happens according to that ownership mechanism. A destructor is not synonymous with freeing the object's own storage: destruction and deallocation are distinct steps, even though a delete-expression commonly performs both. Destructors should release owned resources without allowing exceptions to escape. Do not manually call an ordinary local object's destructor and then let scope exit destroy it again; lifetime management must remain coherent.
15. What is the difference between copying and moving an object?
Copying creates or assigns another value from an existing object, usually leaving the source's value unchanged. Moving allows an operation to reuse resources from a source whose value the caller no longer needs. A move is not automatically cheap and does not always happen merely because std::move appears: that function enables move-related overload selection by casting, while the selected constructor or assignment operator performs the work. Standard-library moved-from objects generally remain valid but may have unspecified state unless documented otherwise. In the example, unique_ptr transfers sole ownership; its specified moved-from state is null, unlike an assumption that every moved-from container is empty.
16. What is the rule of zero?
The rule of zero says that a class should usually let its members manage resources so it does not need to define its own destructor, copy operations, or move operations. A class holding std::string and std::vector can often rely on their correct ownership behavior and the compiler-generated special members. This reduces subtle errors such as double deletion and forgotten exception cleanup. It is a design guideline, not a language rule or a ban on custom ownership abstractions. When directly managing a resource, consider all relevant special members together; independently adding a destructor can change which move operations the compiler implicitly declares.
17. When should you use unique_ptr?
Use std::unique_ptr to represent exclusive ownership of a dynamically managed object when a direct value or container is not the better fit. It destroys its owned object through its deleter and can transfer ownership by moving, but cannot be copied. Prefer std::make_unique for ordinary creation and pass a borrowed pointer or reference to code that does not participate in ownership. A function accepting a unique_ptr by value clearly takes ownership. Exclusive ownership is often easier to reason about than shared ownership because there is one responsible owner. It still does not make a borrowed raw pointer safe after that owner resets or is destroyed.
18. When is shared_ptr appropriate, and what does it cost?
std::shared_ptr is appropriate when multiple independent owners genuinely need an object to remain alive until the last owner releases it. Copies normally share an ownership control block rather than copying the underlying object. This adds bookkeeping and reference-count update costs and can make the time of destruction less obvious. It does not make the pointed-to object's operations thread-safe. Avoid using shared ownership merely to avoid deciding who owns a resource. Strong ownership cycles can keep objects alive indefinitely, so designs may need weak back-references. std::make_shared is often convenient, but allocation layout and retained control-block storage can matter in specialized situations.
19. How does weak_ptr help with shared ownership cycles?
std::weak_ptr observes an ownership group managed by shared_ptr without keeping the managed object alive. It is useful for back-references, caches, and relationships that should not count as ownership. Calling lock() attempts to obtain a shared_ptr; a successful result holds the object alive for that local use. Test the returned pointer rather than checking expiration and assuming the object will still exist afterward. For example, a child may weakly reference its parent while the parent strongly owns the child. Weak pointers address lifetime participation, not synchronization of the object's contents or the architectural question of whether shared ownership was necessary.
20. How should inheritance differ from composition in a basic design?
Public inheritance models a subtype that can honor the base type's contract when used through a base interface. Composition models an object that contains or uses another object without claiming that substitutability. A report generator containing a file writer usually needs composition, not inheritance from the writer. Inheritance can support runtime polymorphism, but it also couples derived classes to base-class decisions and requires careful lifetime and interface design. Do not select it only to reuse a few implementation lines. Prefer a simple value or contained collaborator unless the design actually needs a stable polymorphic relationship and its associated behavior guarantees.
21. What do virtual functions and override do?
A virtual member function supports dynamic dispatch: a call through a suitable base pointer or reference selects the final overrider for the actual object's dynamic type. override asks the compiler to verify that a derived declaration really overrides a base virtual function, catching mistakes such as a missing const qualifier. It does not turn an unrelated function into an override. A qualified call can suppress virtual dispatch, and construction and destruction have special dispatch rules. In an interview, explain both the interface contract and the lifetime of the referred object; invoking a virtual function through a dangling pointer is not rescued by polymorphism.
22. Why may a base class need a virtual destructor?
If an object of a derived type will be deleted through a pointer to its base, the usual polymorphic base design requires a virtual destructor. Without the necessary virtual destruction support, this ordinary deletion pattern has undefined behavior. A public virtual destructor lets destruction proceed through the derived object. A protected non-virtual destructor can instead prevent clients from deleting through the base when that is the intended design. Not every class needs virtual functions or a virtual destructor. Decide according to the ownership interface, because virtual dispatch introduces design and representation consequences rather than being a universal safety switch for all types.
23. How are function overloading and overriding different?
Overloading provides functions with the same name but different parameter lists, and overload resolution selects a viable function at compile time based on the call. Overriding provides a derived implementation of a base virtual function and participates in dynamic dispatch. Changing only a return type does not generally create an overload. A derived function with the same name but a different parameter list can hide base overloads rather than override them; a using-declaration can make those overloads visible. Use override on intended overrides so the compiler checks the relationship instead of relying on the programmer to spot a nearly matching signature.
24. What is object slicing, and how do you avoid it?
Object slicing occurs when a derived object is copied into a base object by value, preserving only the base subobject's value. The new object is genuinely a base object, so its lost derived state and behavior cannot be recovered by a virtual call. A function taking a base by value can cause the same problem when passed a derived object. Use references or pointers when the function should observe an existing polymorphic object, and use an explicit cloning design when independent polymorphic ownership is required. This is different from a base reference: referring to the base subobject does not itself copy away the derived portion.
25. How do exceptions interact with automatic objects?
When an exception transfers control to a matching handler, stack unwinding destroys fully constructed automatic objects whose scopes are exited. That behavior makes RAII resource owners important: a vector or file wrapper can clean up even when later work fails. A constructor that throws does not run the destructor of its incomplete most-derived object, but already constructed bases and members are destroyed. Catch standard exception objects by const reference when inspecting them without copying or slicing. Unwinding is not a promise for every termination path, and a destructor throwing during active unwinding can cause termination. Handle recoverable failures at a layer that can make a meaningful decision.
26. When would you choose vector rather than array?
std::vector owns a contiguous sequence whose size can change at runtime; std::array<T, N> stores a fixed number of elements with the extent in its type. Both support indexed access and standard algorithms. A vector is a natural default for a dynamically sized list, whereas array suits a genuinely fixed-size value such as a three-component coordinate. Growing a vector can reallocate its storage and invalidate existing pointers, references, and iterators. An array does not resize, but its elements still die with the owning array. Choose based on required semantics rather than assuming that all vector operations allocate or that a fixed-size array always resides on the stack.
27. How do string and string_view differ?
std::string owns a mutable character sequence, while C++17 std::string_view is a non-owning view described by a pointer and length. A view can avoid copying when a function temporarily examines existing text, but it must not outlive the characters it references. A view's data is not necessarily null-terminated, so passing data() to a C API expecting a terminated string can be wrong. String mutation can also invalidate a view or change what it observes. In the example, the owner remains alive and unchanged while the view is used; the substring operation selects a view without allocating a second owned string.
28. What is an iterator, and why is end not an element?
An iterator represents a position in a sequence and supports operations determined by its iterator category or concept. A container's begin() denotes the first position, while end() denotes the past-the-end position. The half-open range [begin, end) includes elements before end, not an element stored at end. For an empty container, begin equals end, so dereferencing either is invalid. Do not assume every iterator supports arithmetic: linked-list iterators can advance but cannot use random-access indexing. Iterators also have invalidation rules tied to container operations. Reacquire them or use the documented return value after mutations instead of continuing with a stale position.
29. How does a range-based for loop choose copies or references?
The loop variable declaration determines how each dereferenced element initializes that variable. auto value usually makes a copy, auto& value binds a mutable reference, and const auto& value avoids an ordinary element copy while providing read-only access through the reference. Proxy-reference types are a reason to avoid claiming that every container behaves exactly like a vector of integers. Also consider mutations that invalidate the loop's traversal state; appending to a vector while traversing it can be unsafe. The following loop intentionally modifies the existing elements, so references express the operation directly rather than changing temporary copies.
30. Why use standard algorithms instead of writing every loop manually?
A standard algorithm names an established operation such as sorting, searching, or transforming and makes its requirements easier to recognize. This can reduce indexing errors and separate traversal from the operation applied to each element. It is not a blanket guarantee of faster code: iterator requirements, comparator correctness, allocations, and workload still matter. For example, std::sort requires random-access iterators and a suitable ordering relation, so it is not directly applicable to a linked list's iterators. Use a handwritten loop when its control flow is genuinely clearer, but do not hide familiar operations behind complicated loops merely to avoid learning the library's contracts.
31. What is a lambda, and what do its captures mean?
A lambda expression creates a callable object, often useful for a local operation passed to an algorithm. Capturing a local variable by value gives the callable its own captured state; capturing by reference refers to the existing variable and depends on that variable's lifetime. Reference captures are dangerous when a callback escapes the scope that owns the referenced objects. Capturing a pointer by value copies the pointer, not the pointed-to object. Prefer explicit captures when they make dependencies clearer, and consider whether the callable executes immediately or is retained for later. The capture choice is an ownership and lifetime decision, not merely syntax for accessing local names.
32. What problem does a function template solve?
A function template describes a family of functions parameterized by types or other template parameters. It allows an algorithm to operate on different compatible types without copying its implementation for each one. The compiler checks the instantiated operations for the actual arguments, so generic code still has requirements even when they are not written as constraints. A simple larger-value function requires comparison and a suitable return operation; not every type satisfies those requirements. C++20 concepts can make requirements explicit, but ordinary templates are available in earlier standards. Avoid describing templates as runtime dispatch: their usual selection and instantiation are compile-time mechanisms.
33. Why are namespaces useful, and why avoid using namespace std in headers?
Namespaces group declarations and distinguish otherwise identical names, reducing collisions between independently developed libraries. A qualified name such as std::vector identifies the intended namespace explicitly. A using-directive in a widely included header changes unqualified lookup for every translation unit that includes it, potentially causing ambiguity or altering which names are considered. Keep headers restrained and use narrowly scoped using-declarations where they improve readability without exporting a broad naming policy. Namespaces are not security boundaries and do not hide implementation merely by naming it. They organize interfaces; linkage, access control, and file structure address different concerns.
34. What is the difference between a declaration and a definition?
A declaration introduces or redeclares a name and describes relevant properties, while a definition supplies the entity's defining contents, such as a function body or an object's definition. For example, int calculate(int); declares a function and a corresponding function body defines it. A declaration lets another translation unit compile a call without containing that function's implementation. The program must still satisfy definition and linkage requirements when built. Not every variable declaration allocates a new independent object: an appropriate extern declaration can refer to an object defined elsewhere. Understanding this distinction helps diagnose missing-symbol and duplicate-definition errors instead of repeatedly adding includes.
35. What do include guards prevent, and what do they not prevent?
Include guards use conditional preprocessing to ensure that a header's contents are processed at most once within a translation unit. They prevent repeated class definitions caused by direct or indirect inclusion of the same header in that translation unit. They do not prevent the header from being included in several different translation units, so they do not make arbitrary non-inline function definitions in headers safe. Use unique guard names and make headers self-contained by including what their declarations require. #pragma once is widely supported but is not a standard C++ directive. Either mechanism addresses repeated inclusion, not the whole program's definition rules.
36. What is the one-definition rule at a beginner level?
The one-definition rule controls how many definitions entities may have and when definitions in different translation units must agree. A non-inline function commonly has one program-wide definition, while certain entities such as classes, templates, and inline functions can be defined in multiple translation units under specific conditions. Those definitions cannot silently describe incompatible types or behavior. Header guards only address repeated inclusion within one translation unit; they do not solve inconsistent definitions across files. Some violations need not receive a diagnostic, so a successful link is not proof of correctness. Keep shared definitions in consistent headers and avoid macros that give the same entity different meanings between translation units.
37. Why prefer named casts to C-style casts?
Named casts state the intended category of conversion and are easier to search and review. static_cast expresses many ordinary explicit conversions, dynamic_cast supports checked conversions within suitable polymorphic hierarchies, const_cast changes cv-qualification, and reinterpret_cast handles low-level reinterpretations under restrictive rules. They are not interchangeable, and an explicit cast does not prove the result is safe. For example, casting away const does not permit modifying an object that was originally defined const. A C-style cast can choose among several conversion mechanisms, concealing that distinction. Prefer fixing an interface or representing the intended type directly before using a cast to suppress a compiler complaint.
38. Why use enum class instead of an unscoped enum?
A scoped enumeration keeps its enumerator names inside the enum's scope and does not implicitly convert to an integer. This makes accidental mixing of unrelated categories less likely and permits descriptive names such as State::ready without exporting a bare ready name. Specify an underlying type when its range or representation is part of a deliberate interface requirement, while still treating serialization as an explicit design problem. An enum is not automatically a validated input domain: values created through conversions or external data can require checking. Use scoped enums for distinct named states rather than substituting arbitrary integers throughout the application.
39. What is undefined behavior, and how is it different from unspecified behavior?
Undefined behavior means the language imposes no requirements on the program's behavior for that execution. Examples relevant to C++17 include signed integer overflow and dereferencing a dangling pointer; a crash is not required. Unspecified behavior instead permits a set of valid choices without requiring the implementation to document which choice it makes. Implementation-defined behavior requires the implementation to document its choice. Do not infer correctness from an apparently sensible result produced by a debug build. Optimizations can rely on the absence of undefined behavior. In interview examples, identify the violated rule and repair the program rather than predicting one reliable output from invalid execution.
40. How would you investigate a small C++ program that sometimes crashes?
First reproduce the failure with a minimized input and record the build configuration, platform, and exact symptom. Enable useful compiler warnings, inspect the crash with a debugger, and use applicable sanitizers to look for memory errors or undefined operations. Review ownership, bounds, iterator invalidation, initialization, and thread access before guessing at an optimizer defect. A sanitizer report is evidence about the executed paths, not proof that all unreported paths are correct. Reduce the case while preserving the failure, fix the underlying lifetime or logic error, and add a regression test. Avoid making the failure disappear by changing timing or disabling optimization without explaining the cause.
C++ Interview Questions and Answers for Intermediate
These explanations make hidden assumptions visible. Distinguish a cast from an operation, a non-owning view from storage, and a thread-safe control block from thread-safe application data.
41. How do lvalues, xvalues, and prvalues affect overload resolution?
A value category describes an expression, not simply the type of its object. An lvalue identifies an object that is not treated as expiring; an xvalue identifies an object whose resources may be reused; a prvalue computes a value or initializes a result object. These categories determine reference binding and therefore which overload is viable. A named variable is an lvalue expression even when its declared type is an rvalue reference. In an interview, trace both the type and the expression category before predicting a copy or move. Calling everything on the right side of an assignment an rvalue produces incorrect answers.
42. Why can std::move copy a const object instead of moving it?
std::move performs a cast that permits move-aware overload resolution; it does not transfer resources by itself. Applied to a const string, it produces a const rvalue reference. The ordinary string move constructor needs a non-const rvalue reference because moving generally modifies the source, so the copy constructor can be selected instead. This is why marking a local const can conflict with an intended ownership transfer. Use const to express genuine immutability, not as a mechanical performance habit. Also avoid assuming that an arbitrary user-defined type's moved-from object is empty: its usable state depends on its documented contract.
43. What makes T&& a forwarding reference rather than an ordinary rvalue reference?
T&& is a forwarding reference when T is an appropriate deduced, cv-unqualified function-template parameter; it can then bind to either lvalues or rvalues through deduction and reference collapsing. By contrast, const T&& is not a forwarding reference, nor is a class template's already-fixed T in an ordinary member parameter. Forwarding references preserve caller information that an ordinary value parameter would discard. Use them for transparent wrappers, not automatically for every interface. An unconstrained forwarding overload can accept more argument types than intended and interfere with copy constructors or better-documented overloads, making diagnostics and ownership expectations harder to understand.
44. How does std::forward preserve the caller's value category?
std::forward<T>(value) conditionally casts according to the deduced T, so a wrapper passes lvalues onward as lvalues and rvalues as rvalues. The parameter name itself is an lvalue expression, making this explicit step necessary. The C++17 example verifies both paths without depending on implementation-specific copy counts. Forward only when preserving the original argument category is the intended contract; repeatedly forwarding the same rvalue can expose an already-moved-from object to later operations. Forwarding also does not extend the lifetime of a temporary beyond the rules of the underlying call.
45. Which return-value optimizations are guaranteed in C++17, and which remain optional?
In C++17, eligible initialization from a same-type prvalue constructs the result directly without an intervening copy or move. This guarantee does not cover potentially overlapping subobjects, such as a base subobject. Returning a named local instead permits named return-value optimization, which is not universally guaranteed. That distinction matters for types with deleted copy and move constructors and for tests that count constructor calls. Prefer returning a local by name rather than writing return std::move(local), which can prevent NRVO. The following guaranteed-prvalue case is different from returning a named Token variable. Its destructor must still be accessible and valid even though no intermediate Token needs destruction.
46. Why can a user-declared destructor change a class's move behavior?
A user-declared destructor suppresses implicit declaration of the move constructor and move assignment operator. An rvalue may therefore bind to an available copy operation, which can make code compile while unexpectedly copying. Review all special members together whenever a class directly owns a resource, but prefer member types that already manage ownership so the enclosing class can follow the rule of zero. Explicitly defaulting a move operation is useful only if moving each member preserves the class invariant. A raw owning pointer, for example, does not become safely transferable merely because the compiler is asked to default the move constructor.
47. Why does noexcept on a move constructor matter to vector growth?
When a vector reallocates, it must transfer existing elements while honoring its exception guarantees. For a copyable element with a potentially throwing move constructor, copying can preserve the old elements if constructing the new storage fails. A genuinely nonthrowing move makes relocation easier to perform safely and can avoid expensive copies. Declare noexcept only when the implementation can uphold it: an escaping exception then causes termination. A move-only type with a throwing move has more limited failure guarantees in relevant vector operations. Benchmark the actual type and workload instead of assuming every move is cheaper than every copy.
48. When does binding a reference extend a temporary's lifetime, and when does it not?
Directly binding an appropriate local reference to a temporary can extend that temporary's lifetime to the reference's lifetime. That rule does not propagate through arbitrary function calls or through another reference. Returning a reference to a local object remains invalid, and returning a reference parameter does not make a caller's temporary permanent. For example, a temporary bound to a function reference parameter generally lasts through the containing full-expression, not as long as a reference saved from the result. In code review, identify the expression that actually creates the temporary and the exact binding context; reasoning from the variable's const qualification alone is insufficient.
49. How would you prevent dangling string_view and span values in an API?
Treat std::string_view in C++17 and std::span in C++20 as non-owning access paths whose backing storage must remain alive and valid. Returning a view into a local string or vector leaves a dangling result; reallocating an owner's storage can invalidate previously obtained views. Prefer an owning return value when lifetime cannot be expressed clearly, and document when callers must retain ownership. A span's element count does not provide automatic bounds checking for every access. Views are useful for synchronous parsing or algorithms that do not retain arguments, but an asynchronous task often needs an owned copy or an explicitly shared owner instead.
50. How does explicit prevent surprising conversions in class interfaces?
explicit stops converting constructors and conversion functions from participating in certain implicit conversions while still allowing appropriate explicit initialization or casts. A strong ID type should not silently accept every integer in unrelated calls, because accidental interchange with counts or flags can hide a logic error. Direct initialization such as UserId{7} makes the boundary visible. Explicit conversion to bool is useful for stateful handles because contextual boolean tests can still express validity without opening unrestricted numeric conversions. C++20 also supports conditional explicitness, but a simple fixed explicit constructor is often easier to explain, review, and maintain for a domain-specific type.
51. How should you diagnose an ambiguous overloaded function call?
List the candidate functions, determine which are viable, and compare the required conversion sequences rather than guessing from visual similarity. Exact matches, promotions, other standard conversions, and user-defined conversions have different ranking rules; templates and constraints introduce additional tie-breakers. For instance, a short argument typically prefers an int overload through integral promotion over a long overload through conversion. If two alternatives are indistinguishable under the rules, the call is ill-formed rather than selecting the first declaration. Repair the interface with clearer types or fewer competing implicit conversions; a cast at every call site often hides the original design problem.
52. Why does template argument deduction sometimes fail even when a conversion exists?
Deduction usually determines template arguments from the actual argument types before ordinary conversions are considered for the resulting function. A template taking two parameters of the same T therefore does not automatically choose a common arithmetic type for an int and a double. The caller can specify T explicitly, convert intentionally, or use separate template parameters with an appropriate result policy. Each repair expresses a different contract, especially when narrowing would lose information. Avoid making every deduction failure disappear through casts: the compiler may be exposing a meaningful mismatch between units, signedness, ownership, or precision that the interface should handle explicitly.
53. When should you use template overloading instead of explicit specialization?
Function-template overloading is usually a clearer way to provide behavior for a different parameter pattern because overload resolution considers the overloads themselves. A function template cannot be partially specialized, although a class template can. Explicit specializations of function templates interact with the selection of the primary template and can surprise maintainers who expect them to behave like ordinary overloads. Use class-template specialization for genuinely type-dependent representation or traits, and constrained overloads in C++20 for alternative behaviors with explicit requirements. Keep the generic contract coherent: a specialized implementation should not silently introduce different ownership or failure semantics for one incidental argument type.
54. What does SFINAE remove from an overload set, and what does it not protect?
Substitution failure is not an error means that certain failures in the immediate substitution context of a function template remove that candidate rather than rejecting the entire program. It lets an overload participate only when a required expression or type exists. An error deep inside an instantiated function body is not automatically protected, so SFINAE is not a universal exception handler for template compilation. In C++17, detection idioms and std::enable_if_t can express such conditions. Prefer a small named trait over dense nested machinery, and use C++20 constraints where available to communicate the requirement directly to both callers and diagnostics.
55. How do C++20 concepts improve a generic interface without proving its semantics?
Concepts let a template state compile-time requirements and constrain which arguments it accepts. They improve discoverability and often make a failed call easier to diagnose than an error several instantiations deep. Satisfying a syntactic requirement does not prove every semantic promise: a callable that compiles as a comparator can still violate strict weak ordering. The example deliberately expresses a narrow integral-input contract rather than claiming all numeric types are interchangeable. Choosing an overly broad existing concept can be as misleading as omitting constraints, so align the requirement with the operations and invariants the implementation actually needs.
56. How does if constexpr differ from a normal if in a function template?
C++17 if constexpr selects a branch at compile time, allowing the discarded branch to avoid instantiation in the relevant templated context. A normal if still requires both branches to be valid even when its condition looks constant. This is useful when one type needs pointer dereferencing and another should be returned directly. The discarded branch is still parsed, and non-dependent errors cannot be freely hidden there. Use the feature for a small number of local compile-time alternatives; a long type-switch inside one template can be harder to maintain than separate constrained overloads or a focused customization mechanism.
57. When should you choose constexpr versus consteval?
A constexpr function can participate in constant evaluation when its arguments and evaluated operations permit it, but it can also be called at runtime. C++20 consteval specifies an immediate function whose applicable calls must produce compile-time evaluation rather than serving as an ordinary runtime fallback. Use constexpr for reusable calculations that are useful in both contexts, such as a small size conversion. Use consteval when accepting runtime input would violate the API's purpose, such as generating a compile-time descriptor. Neither keyword means that every object touched by the function becomes immutable, and compile-time execution must still satisfy the language's constant-expression rules.
58. When is std::function preferable to a templated callable parameter?
std::function provides an owning, type-erased callable wrapper with a fixed signature, useful when callbacks of different concrete types must share storage or an interface. A templated callable parameter keeps the concrete type available, which can support inlining and avoid type-erasure overhead but may increase generated code and expose implementation details in headers. In C++17, a stored std::function target must be copy-constructible, so a lambda owning a unique_ptr is not directly suitable. Do not assume every wrapper allocates or every template is faster; test realistic captures and call patterns. C++23 offers move_only_function when an owning, move-only wrapper fits the contract.
59. What lifetime bugs can lambda captures introduce in asynchronous code?
A reference capture does not keep its referent alive, so a callback executed after the originating scope ends can dereference a destroyed object. Capturing this likewise does not own the containing object, and default capture syntax can obscure that fact. Prefer explicit captures that make the intended lifetime reviewable: move an owned value into the closure, or capture a weak_ptr and check whether the owner still exists before accessing it. Capturing a shared_ptr may be appropriate but can create cycles through stored callbacks. Decide whether late execution should retain, skip, or cancel the operation rather than using ownership merely to silence a lifetime warning.
60. How do reserve and resize differ, and when does vector invalidate references?
reserve changes capacity when necessary but does not add elements; resize changes the number of live elements. Indexing reserved-but-unconstructed positions is not valid. Reallocation invalidates all pointers, references, and iterators into a vector, while insertion without reallocation invalidates iterators and references at or after the insertion point. Erasure also affects positions at or after the erased range. Keep indices or reacquire access after mutation when appropriate, but remember an index can refer to a different logical element after erasure. Reserving a credible final size can reduce reallocations; repeatedly reserving one extra slot can undermine the intended growth strategy.
61. Why must remove_if usually be followed by erase on a vector?
std::remove_if rearranges retained values into the front of the range and returns a new logical end; it does not shrink the container. Erasing the remaining suffix updates vector size and destroys those trailing elements. Values in the removed suffix should not be interpreted as a clean list of the removed records. The following C++17 example keeps odd numbers while preserving their relative order. C++20 std::erase_if provides a convenient container-level form. During such transformations, avoid retaining references to logical records that may be overwritten or shifted, even when a particular memory address remains allocated.
62. How do map and unordered_map differ beyond their average lookup complexity?
std::map maintains key order and provides logarithmic lookup, making ordered traversal and range queries natural. std::unordered_map uses hashing with average constant-time lookup but can degrade under poor collision behavior; rehashing affects iterator validity and has allocation costs. Consider memory overhead, key-comparison cost, hash quality, reference stability requirements, and the need for deterministic ordering before choosing. A small contiguous collection can beat either structure for a particular workload, so complexity notation alone is insufficient. Custom equality and hashing must agree: keys that compare equal must produce equal hashes. Benchmark representative key distributions rather than only sequential integer keys.
63. Why can operator[] be the wrong choice for a map lookup?
For map-like containers, operator[] inserts a missing key and value-initializes the mapped value instead of merely reporting absence. A read-only-looking access can therefore mutate state, allocate memory, and hide a missing-record bug behind a default value. Use find when absence is expected, or at when a missing key should produce an exception. C++17 try_emplace is useful for conditional insertion without constructing the mapped object in the container when the key already exists. Be precise about argument evaluation, however: expressions passed as arguments are still evaluated before the call. Choose the operation from the intended semantics rather than its shorter spelling.
64. What properties must a comparator satisfy for std::sort?
A comparator must establish a strict weak ordering for the supplied values, not merely return something that usually resembles less-than. In particular, an element must not compare less than itself, and the ordering and induced equivalence must be consistent. Using <= instead of < violates the contract. For records, compare the primary field and then a deterministic tie-breaker when the application requires one. NaN-containing floating-point data needs an explicit ordering policy rather than assuming ordinary < handles every dataset correctly. Violating the comparator requirements can make the algorithm's behavior undefined; tests should include equal keys and adversarial triples, not just distinct ascending inputs.
65. When is optional a better return type than a sentinel value?
C++17 std::optional<T> represents either a T value or its absence without reserving a valid T value as a sentinel. This is useful when every integer is meaningful or an empty string is a legitimate result. It communicates that callers must consider the missing case, but it does not explain why a computation failed. For multiple error causes, use an explicit error representation instead. Access through value() throws on absence, while unchecked access requires a present value. Also remember that optional<bool> has two distinct questions: whether a bool exists and whether that contained bool is true.
66. How should you process a variant safely, and what is valueless_by_exception?
C++17 std::variant stores one alternative from a fixed set of types, making the possible states visible in the type. Prefer std::visit for exhaustive processing or std::get_if when one alternative is expected but not guaranteed. A mismatched std::get throws rather than performing an unchecked reinterpretation. Some throwing type-changing operations can leave a variant valueless by exception, which must be considered when designing exception-sensitive code. Choose alternatives with straightforward ownership and reliable moves when practical. A variant is not automatically a superior replacement for polymorphism: its closed alternative set suits some domains, while a plugin interface may require extension without editing every visitor.
67. When does any make sense, and what trade-offs does it introduce?
C++17 std::any stores a value of a runtime-selected copy-constructible type when the complete type set cannot conveniently appear in the interface. It can support an extensible metadata registry, but moves type agreement from compile time into runtime checks and conventions. any_cast must request the appropriate stored type; its pointer form allows a mismatch to be checked without throwing. Unlike variant, any does not enumerate all acceptable alternatives for exhaustive handling. Prefer a dedicated structure or variant when the schema is known. Otherwise, document type ownership, naming conventions, and mismatch behavior so the container does not become an unstructured channel for hidden dependencies.
68. When would you use C++23 expected instead of optional or exceptions?
std::expected<T, E> represents either a value or a typed error, making recoverable failure part of the function's visible return contract. It is more informative than optional when callers need to distinguish invalid syntax from a missing resource, for example. Compared with exceptions, it encourages explicit local propagation and handling, but can create repetitive checking if the surrounding design lacks compositional helpers. It does not guarantee that constructing T or E cannot throw. Confirm C++23 library support in the actual toolchain, and choose error types that carry useful context without accidentally exposing sensitive input or imposing excessive allocation costs on common failure paths.
69. How do structured bindings change copying and mutation of container entries?
C++17 structured bindings expose components with names, but the declaration's reference qualification still controls whether the underlying binding object is copied or referenced. In a range-for over a map, auto [key, value] works with a copy, whereas auto& [key, value] refers to the entry and allows modifying the mapped value. The key remains const in either map entry representation where applicable. Use const auto& for read-only iteration without unnecessary entry copies. Avoid treating the syntax as magic destructuring with universal reference semantics; understanding the hidden binding object is important when elements are expensive, move-only, or backed by proxy references.
70. Why can a lazy ranges pipeline behave differently from a materialized container?
C++20 views commonly defer work until iteration, so a filter-and-transform pipeline need not allocate a new collection. That also means the underlying range must remain valid, repeated traversals can repeat work, and changes to the source can affect later observations subject to the view's requirements. Predicates should not depend on uncontrolled side effects. The C++20 example retains the vector throughout traversal and materializes only a scalar total. A view is not necessarily non-owning in every case, and not every range is a view; inspect the specific adaptor rather than making lifetime assumptions from the presence of pipe syntax.
71. What are the basic, strong, and no-throw exception guarantees?
The basic guarantee preserves invariants and avoids resource leaks after failure, while allowing state changes. The strong guarantee makes a failed operation leave the relevant observable state unchanged. The no-throw guarantee means the operation does not throw. These are API commitments, not outcomes inferred merely from using RAII. A transaction that updates two containers can leak nothing yet still leave one updated and the other unchanged. Identify the commit point and every potentially throwing operation before claiming rollback behavior. Document the guarantee that callers can actually rely on, and use failure-injection tests to exercise allocations, element copies, and other error paths.
72. How does copy-and-swap provide exception safety, and when can it be inefficient?
Copy-and-swap first constructs a replacement state, then commits through a swap that must not throw for the intended strong guarantee. If creating the replacement fails, the original object is unchanged. It naturally handles self-assignment but may allocate and copy unnecessarily when an existing buffer could be reused safely. For resource-owning classes, verify that swapping all invariant-related members is valid and that allocator restrictions do not invalidate the assumptions. Prefer the rule of zero where standard members already provide the needed behavior. Copy-and-swap is a useful transaction pattern, not a requirement that every assignment operator should incur a full duplicate allocation.
73. How can a custom deleter make unique_ptr manage a non-memory resource?
A custom deleter adapts unique_ptr's ownership mechanism to a resource that must be released with a function other than delete, such as a C file handle. The deleter must match the acquisition mechanism and should not throw during destruction. Its type can affect the smart pointer's size, so a function pointer deleter and a stateless function object need not have identical storage costs. A close failure also requires a policy: if callers need to observe it, provide an explicit checked close operation rather than relying exclusively on a destructor. Ownership adaptation solves release responsibility, not every error-reporting or thread-safety concern.
74. How would you design a weak_ptr cache without retaining objects indefinitely?
A cache of std::weak_ptr<T> lets callers reuse an object while independent owners keep it alive, without making cache membership itself an ownership claim. Look up the entry and use lock() to obtain a local strong owner; if that fails, recreate or report absence according to the cache contract. Synchronize the cache map separately: atomic ownership acquisition does not protect its structure, and concurrent misses can otherwise construct duplicate objects. Expired entries also retain bookkeeping until removed. With commonly coallocated make_shared storage, weak owners can retain the allocation even after the object's destructor runs. Periodically prune expired entries and measure retained bytes as well as live-object count; weak ownership is not a complete eviction policy.
75. How does jthread improve thread lifetime management, and what problems remain?
A joinable std::thread must be joined or detached before its destructor runs, or termination occurs. A joinable C++20 std::jthread requests stop and joins in its destructor, reducing accidental lifetime-management failures. Its stop mechanism is cooperative: the worker must observe or participate in cancellation, and an indefinitely blocked worker can still make destruction wait indefinitely. Neither class makes accesses to shared data safe automatically. Define the owner, cancellation protocol, and exception boundary before launching work. In particular, avoid allowing an exception to escape the worker entry function, and ensure every captured object outlives all worker accesses even on error or early return paths.
76. When should you use lock_guard, unique_lock, or scoped_lock?
Use lock_guard for simple scope-bound ownership of one mutex. Use unique_lock when ownership must be transferred, locking deferred, or the lock temporarily released, as required by condition-variable waiting. C++17 scoped_lock conveniently acquires multiple mutexes with a deadlock-avoidance algorithm. That does not make an entire program deadlock-free: locks held outside the operation, callbacks, and inconsistent higher-level protocols can still create cycles. Keep critical sections focused and avoid calling unknown code while holding a lock. The best wrapper expresses the needed ownership behavior without exposing unnecessary manual lock and unlock operations that become fragile when exceptions or early returns occur.
77. Why must a condition-variable wait use a predicate?
A condition variable reports a reason to recheck shared state, not a durable stored event. A wait can wake spuriously, and another consumer can change the condition before the waiting thread regains the mutex. The predicate form waits until the protected condition is true, closing these gaps. Update the state under the same mutex used by the waiter, then notify. The following C++17 example also handles the producer finishing before the consumer starts waiting. Real queues additionally need a shutdown predicate so consumers can exit when no future item will arrive; notification alone is not a complete shutdown protocol.
78. Why does an atomic counter not automatically make a whole operation thread-safe?
An atomic operation protects its own object according to its memory-order contract; it does not turn a sequence of operations or neighboring non-atomic accesses into one transaction. For example, separately checking a counter and then incrementing it can let multiple threads pass a capacity test. Use a mutex for a multi-field invariant or a carefully designed compare-exchange loop when appropriate. Default sequential consistency simplifies reasoning but still does not supply a missing protocol. Relaxed ordering can suit a standalone statistics counter when it is not publishing other state. Whether an atomic type is lock-free is implementation-dependent and separate from the correctness of the algorithm.
79. How do error_code overloads change filesystem error handling?
C++17 filesystem operations often offer an overload that reports operating-system errors through std::error_code instead of throwing filesystem_error for those failures. This can suit batch traversal, where inaccessible entries are recorded and processing continues. Inspect the error immediately and distinguish a valid negative result from failure; for example, a path not existing and an inability to inspect it are different situations. Do not assume every error-code overload is unconditionally noexcept, because allocation-related failures can still matter for some operations. Filesystem state also changes concurrently, so an existence check is not a guarantee that a later open or removal will succeed.
80. How would you choose between emplace_back and push_back for a vector?
emplace_back constructs an element from forwarded arguments in the vector, while push_back accepts an existing element to copy or move. Emplacement can avoid an intermediate object when constructing from its ingredients, but passing an already-created object to emplace_back does not magically eliminate every transfer. Reallocation still has its own element-movement costs and invalidation rules. Prefer the spelling that most clearly communicates the intended construction, especially when explicit constructors or overloaded argument lists make emplacement surprising. Evaluate performance with the actual element type and reserve strategy; replacing every push_back mechanically is less valuable than understanding allocations, ownership, and unnecessary upstream copies.
C++ Interview Questions and Answers for Experienced
Senior answers should connect language rules to a defensible engineering decision. State invariants, identify evidence, and explain trade-offs instead of promising universal speedups or treating one successful test as proof of correctness.
81. How would you implement an update that provides the strong exception guarantee?
Prepare the new state without modifying the observable old state, then commit using operations that cannot fail. For example, construct a replacement vector, validate its contents, and swap it into the object only after preparation succeeds. RAII releases the temporary if construction or validation throws. The guarantee concerns the operation's documented observable state: a log entry or an external payment cannot automatically be undone by swapping memory. Also verify allocator and swap requirements rather than assuming every swap is nonthrowing. When a cheap nonthrowing commit is unavailable, choose an explicit rollback strategy or document a weaker guarantee instead of promising transactional behavior the implementation cannot deliver.
82. Why can a destructor or noexcept function turn an exception into process termination?
An exception escaping a nonthrowing function invokes std::terminate; a destructor is commonly implicitly nonthrowing, though its exception specification depends on bases and members. Separately, throwing a second exception out of a destructor invoked during stack unwinding also causes termination. Resource cleanup should therefore not depend on callers catching exceptions from destructors. Put fallible operations such as flushing a remote transaction in an explicit function that reports failure, and make the destructor perform best-effort cleanup without allowing an exception to escape. Do not mark a complicated operation noexcept merely for speed: inspect every path and the behavior of operations it invokes.
83. How would you design an API that makes ownership and borrowing unambiguous?
Choose parameter and return types that communicate whether an operation owns, borrows, or shares an object, then document lifetime requirements that types do not express. Taking std::unique_ptr<T> by value clearly transfers exclusive ownership; taking T& borrows an existing object; a pointer can represent an optional borrowed object. A std::span<const T> in C++20 combines a borrowed contiguous sequence with its length but does not extend its lifetime. Use std::shared_ptr<T> only when shared ownership is actually part of the contract, not simply because a function needs access. Review asynchronous storage especially carefully: retaining a borrowed argument after return needs an independent lifetime arrangement.
84. How do you preserve dynamic type when copying polymorphic objects?
Copying a derived object into a base value slices away its derived portion, so polymorphic values need a deliberate copying interface. A common design gives the base a virtual clone() returning std::unique_ptr<Base>, and each derived override constructs a copy of its own concrete type. The base also needs a virtual destructor when deletion occurs through the base pointer. Smart-pointer return types are not covariant in the way raw pointer return types can be, so the override normally returns the same std::unique_ptr<Base> type. Decide whether cloning should copy identity, handles, caches, or shared resources; a mechanically generated copy may be semantically wrong even when it compiles.
85. When would you choose type erasure instead of templates or an inheritance-based interface?
Type erasure is useful when clients need a stable uniform interface while concrete implementation types should remain hidden or heterogeneous. Templates can expose more optimization opportunities and avoid a runtime dispatch boundary, but instantiate code for concrete types and often expose implementation details in headers. Inheritance-based virtual interfaces offer explicit dynamic polymorphism but require types to participate in the chosen hierarchy. A type-erased wrapper can adapt unrelated types, at the cost of an indirection and potentially allocation or size restrictions. Select based on ownership, copyability, allocation policy, ABI requirements, and measured dispatch cost; no single mechanism is categorically fastest or most maintainable.
86. How does pImpl help with ABI stability, and what does it not guarantee?
pImpl keeps implementation data behind an owning pointer, reducing public-header dependencies and insulating the exposed class layout from many private implementation changes. Define operations requiring the complete implementation type, particularly destruction of a std::unique_ptr<Impl>, in a source file where Impl is complete. This adds indirection and often a heap allocation, and copy behavior must be deliberately implemented or disabled. pImpl does not make arbitrary compiler, standard-library, calling-convention, or public-interface changes ABI-compatible. A production boundary also needs documented supported toolchains and ownership rules; changing a virtual interface or passing incompatible library types across a binary boundary can still break clients.
87. How would you investigate an ODR violation that appears only in optimized builds?
Compare the supposedly identical entity definitions across translation units, including preprocessed output, configuration macros, generated headers, inline functions, and template definitions. The one-definition rule permits certain repeated definitions only under specific conditions; differing definitions can produce an ill-formed program without a required diagnostic. Link-time selection or inlining can expose different symptoms rather than creating the underlying defect. Rebuild all dependent objects with consistent options and headers, enable available linker or LTO diagnostics, and reduce the reproduction. Treat clean linking as insufficient evidence. Shared-library loading and symbol visibility add platform-specific behavior, so inspect the deployed binary set rather than only the source tree.
88. What would you verify before replacing headers with C++20 modules?
Check the compiler, build system, dependency scanner, standard library, and deployment toolchain as a combination, not merely whether a compiler accepts import. Modules can improve interface organization and avoid repeated textual parsing, but build ordering and compiled module artifacts require explicit support. Binary module interfaces are generally toolchain- and configuration-sensitive artifacts, not portable distribution files. Separate named-module migration from header-unit experiments and retain tests for macro-dependent integrations. Start with a bounded component and measure clean and incremental builds. C++20 language availability alone does not guarantee that every required standard-library module or cross-toolchain distribution workflow is supported.
89. How would you reduce template-related build time and binary size without abandoning generic code?
Measure where compilation and code size are spent before changing the design: parse time, instantiation time, optimizer work, and duplicated generated code are different problems. Move type-independent work into non-template functions, reduce unnecessary header dependencies, and consider explicit instantiation for a genuinely closed set of supported types. An extern template declaration can suppress some implicit instantiation work when paired with an appropriate explicit-instantiation definition. Type erasure at selected boundaries can reduce combinations but adds runtime costs and may hide inlining opportunities. Compare build time, debugability, executable size, and application performance together; a smaller binary is not automatically a faster one.
90. Why can two logically equivalent C++20 constraints fail to order overloads as expected?
Constraint ordering uses the language's normalization and subsumption rules, not a theorem prover that recognizes all mathematically equivalent Boolean expressions. Atomic constraints carry identity tied to their originating expressions and parameter mappings. Reusing a named concept in a stronger concept can preserve the relationship that overload ordering needs, whereas independently spelling similar requirements may create distinct atomic constraints and yield ambiguity. When diagnosing an overload set, examine its normalized structure and create a minimal compile test rather than relying on how the English requirements sound. Keep concepts focused on meaningful operations and semantics; syntactic satisfaction alone cannot prove runtime laws such as ordering consistency.
91. What lifetime risks accompany std::pmr containers and a monotonic buffer resource?
A C++17 polymorphic allocator refers to a memory resource; it does not generally own that resource. The resource must outlive containers and other objects that may allocate or deallocate through it. A monotonic buffer resource is useful for phase-based allocation because individual deallocations do not reclaim its storage; memory is reclaimed collectively by release or destruction. Calling release() while containers still use their elements invalidates their backing storage rather than clearing those containers safely. Arrange declaration and destruction order explicitly, budget for growth beyond the initial buffer, and choose an upstream resource policy. An arena improves allocation behavior only when its lifetime matches the workload.
92. How would you diagnose false sharing rather than a true data race?
False sharing occurs when threads update distinct objects that occupy a shared cache-coherence unit, creating contention despite logically independent accesses. A true data race is a language-level conflict without the required synchronization and can cause undefined behavior; padding is not a synchronization fix. First establish race freedom, then profile scaling and coherence behavior while varying layout and partitioning. Per-thread counters followed by reduction can remove frequent shared writes. Alignment or padding may help, but cache-line size and the impact of extra memory are target-dependent. Measure representative thread counts and hardware placement instead of concluding that every slowdown involving atomics is false sharing.
93. Why can a contiguous vector outperform a linked list for an insertion-heavy workload?
The full operation includes locating the insertion position, maintaining nodes, allocation, and subsequent traversal, not just relinking pointers. A vector's contiguous storage often improves locality and allows efficient bulk moves, while a linked list incurs pointer chasing and typically separate node allocations. A list can still be appropriate when stable iterators and frequent insertion at already-known positions dominate, especially for expensive-to-move elements. Benchmark actual element sizes, allocation strategy, traversal frequency, and iterator requirements. Comparing only asymptotic insertion complexity hides major costs; conversely, a favorable small benchmark does not justify ignoring vector reallocation and invalidation in the application's correctness requirements.
94. How would you design a microbenchmark that the optimizer cannot turn into a misleading result?
Make inputs and outputs representative and ensure the measured work contributes to an observable result or a benchmark framework's optimization barriers. Inspect generated code when the result is surprising; the as-if rule allows removal or transformation of work that does not affect observable behavior. Separate setup and allocation only if production also amortizes them, warm up where appropriate, and report variability across multiple runs. Test realistic working-set sizes and avoid comparing differently optimized builds. volatile is not a general-purpose benchmarking barrier and can change the workload. Validate correctness first, because timing undefined behavior or a calculation optimized away produces convincing but useless numbers.
95. Why does casting a pointer not make type-punning valid, and when is std::bit_cast useful?
A cast changes an expression's pointer type; it does not generally create an object of that type or grant permission to access storage through an incompatible type. Violating type-access rules can produce undefined behavior even if the machine instruction appears to work. C++20 std::bit_cast creates a value from another object's representation subject to equal-size and trivially-copyable requirements, without dereferencing a reinterpreted pointer. It still requires care about representations, padding, and whether the resulting bits represent a valid destination value. For portable serialization, encode fields and byte order explicitly: copying native representation does not define a cross-platform wire format.
96. What must be true before constructing an object in manually managed storage?
The storage must have sufficient size and alignment, and construction must begin the intended object's lifetime before ordinary member access. Allocating raw bytes is not a universal substitute for constructing nontrivial objects. Use an allocator or standard container when possible; when manual construction is necessary, pair successful constructions with exactly one destruction and release storage through the matching mechanism. C++20 std::construct_at and C++17 std::destroy_at can make the intent clearer. Reusing storage introduces additional rules about old pointers, transparent replacement, and sometimes std::launder; laundering a pointer does not repair undersized storage or skipped construction. Test exceptional partial-construction paths as carefully as the successful path.
97. How can you check signed addition without first triggering signed-overflow undefined behavior?
Compare against the type's limits before performing the addition. Checking whether an already-overflowed signed result became negative is too late because the overflow itself is undefined behavior. The following C++17 example handles both signs without overflowing the guard expressions. The API reports failure explicitly rather than silently wrapping or saturating; callers must choose the appropriate policy. Similar reasoning is needed for multiplication, allocation sizes, and narrowing conversions, but those operations need their own correctly derived checks. Compiler overflow builtins can be useful when portability requirements permit them, provided their documented semantics are followed.
98. How do you reason about expressions whose argument evaluation order is unspecified?
Separate sequencing guarantees from a particular compiler's observed order. In C++17, evaluations of function arguments are indeterminately sequenced relative to one another: one completes before another, but their order is not generally specified. This differs from unsequenced conflicting accesses, which can produce undefined behavior. An expression can therefore be valid yet produce different allowed results across implementations. Prefer explicit statements when correctness or readability depends on the order of side effects, particularly when callbacks or ownership transfers are involved. Do not generalize the function-call rules to every operator, and state the language version when analyzing older examples because sequencing rules have changed.
99. When is relaxed atomic ordering sufficient, and what does it fail to publish?
Relaxed ordering is suitable when an atomic value needs indivisible access but does not convey readiness of other memory, such as an independent statistical counter. It preserves atomic modification ordering for that object but supplies no acquire-release synchronization for unrelated non-atomic state. Incrementing a relaxed counter after filling a payload does not by itself make a reader's payload access safe. First describe the required happens-before relationship, then select synchronization that establishes it. If readers only consume the counter after joining all workers, thread joining may provide the needed broader synchronization. Avoid weakening ordering merely because tests pass on one processor.
100. How does a release-acquire handoff safely publish non-atomic data?
The producer writes the payload and then performs a release store to an atomic flag. A consumer that reads that stored value with an acquire load synchronizes with the release, making the preceding payload write happen before its later payload read. The example is a single-publication handoff: the producer does not modify the payload again while the consumer reads it. Reusing the flag for repeated publications requires a fuller protocol to prevent overlapping reads and writes. The loop is deliberately simple demonstration code, not a recommendation for an unbounded production busy-wait; blocking primitives or C++20 atomic waiting may suit the workload better.
101. Does sequential consistency eliminate the need to reason about a concurrent protocol?
No. Sequentially consistent atomic operations participate in a single total order subject to the language's consistency requirements, which often makes a protocol easier to reason about. They do not combine several operations into an indivisible transaction, prevent lost updates from a separate load and store, or protect non-atomic data accessed without an appropriate happens-before relationship. A check-then-act sequence can still race logically even if each individual atomic operation is sequentially consistent. Start with clear invariants, ownership, and linearization points; choose a mutex when the invariant spans multiple pieces of state. Stronger ordering is a useful default, not a substitute for an algorithmic correctness argument.
102. Why must compare-exchange loops handle failure and sometimes recompute their desired value?
Compare-exchange updates the atomic only if its current value matches the expected value; otherwise it reports failure and updates the expected argument with the observed value. Weak compare-exchange may additionally fail spuriously, so it is normally used in a retry loop. If the desired value depends on the expected value, recompute it after failure instead of repeatedly submitting a stale result. Choose valid success and failure memory orders and account for any work repeated by retries. Keep externally visible side effects outside speculative attempts unless the algorithm explicitly permits duplication. Passing a stress test does not establish progress guarantees or solve lifetime hazards around pointer-based state.
103. What is the difference between a lock-free atomic and a wait-free algorithm?
A lock-free atomic implementation performs its operation without relying on a conventional blocking lock, but that property alone does not make an entire algorithm wait-free. Informally, lock-free algorithms guarantee system-wide progress despite contention, while wait-free algorithms give each operation a bounded completion guarantee under their model. A compare-exchange retry loop may repeatedly lose and starve one thread even while other threads succeed. Allocation, reclamation, callbacks, or logging inside the operation can introduce additional blocking. Inspect is_lock_free() where relevant, then evaluate the whole algorithm and its assumptions; marketing a data structure as nonblocking based on one atomic member is insufficient.
104. What is the ABA problem, and why does it make reclamation difficult?
ABA occurs when a compared value changes from A to something else and back to A, so a compare-exchange sees the original representation even though the logical state changed. In a lock-free linked structure, an address may be removed, freed, and reused for a different node, making a successful pointer comparison misleading. Version tags can help detect some changes but need their own width and atomicity analysis. Safe reclamation mechanisms, such as hazard-pointer or epoch-based designs, prevent premature reuse under documented protocols. Do not free a node simply because it was unlinked: another reader may still hold its address. Prefer a well-reviewed implementation over an improvised reclamation scheme.
105. What does C++20 atomic shared_ptr protect, and what remains the caller's responsibility?
std::atomic<std::shared_ptr<T>> coordinates concurrent access to the shared pointer value and the associated ownership acquisition. It is useful for publishing replacement snapshots without letting a reader observe a torn owner. It does not automatically synchronize arbitrary mutations of the pointed-to T, and its operations are not required to be lock-free. Publishing std::shared_ptr<const T> can make an immutable-snapshot design easier to enforce, provided no other alias mutates the same object. Also consider destruction cost: releasing the last owner may perform expensive cleanup on a reader or writer path. Measure both access latency and reclamation behavior rather than only the atomic load.
106. How would you prevent deadlocks in code that acquires several locks and invokes callbacks?
Define a consistent lock order across the subsystem and avoid invoking unknown code while holding a lock whenever practical. A callback can reenter the component or acquire another lock in an incompatible order, creating a cycle that local inspection misses. C++17 std::scoped_lock can acquire a known group of mutexes using deadlock-avoidance mechanisms, but it cannot fix all surrounding lock-order inversions or semantic reentrancy problems. Copy or extract the needed state under the lock, release it, and call external code with a documented snapshot. Verify object lifetime across that gap and decide how concurrent changes affect the callback's meaning.
107. How would you design shutdown for a worker pool without losing tasks or hanging?
Specify whether shutdown drains queued tasks or cancels them, reject new submissions at a defined point, and make waiting workers observe the transition through the same synchronization protocol as the queue. Wake blocked workers after changing state, join threads before destroying shared resources, and define what happens to futures for canceled tasks. Never join a worker while holding a mutex it needs to exit. Test empty queues, in-flight submissions, exceptions, and repeated shutdown requests. Stop tokens are useful for cooperative cancellation but do not interrupt arbitrary blocking operations automatically; every wait and external operation needs an explicit strategy for reaching the stopping condition.
108. How can member declaration order make a class with jthread unsafe during construction or destruction?
If a worker accesses a queue and mutex belonging to its owner, those members must be initialized before the worker can use them and remain alive until it finishes. Members initialize in declaration order and are destroyed in reverse order, so placing the C++20 std::jthread member after its dependencies lets its destructor request stop and join before those dependencies are destroyed. That ordering is necessary but not sufficient: a worker started in a member initializer can run before the constructor body establishes the remaining invariant. Start it only after its required state is ready. Likewise, a destructor body runs before member destruction, so explicitly stop and join before that body tears down worker-visible state. Do not hold a mutex the worker needs while joining.
109. Why do coroutine suspension points create unusual lifetime bugs?
A C++20 coroutine can preserve execution state beyond the original call, but references and pointers stored in that state still refer to external objects whose lifetimes may end. A coroutine taking a reference parameter does not automatically copy the referenced object into its frame. Capturing coroutine lambdas are especially subtle because the closure can die while the suspended computation still depends on its captures. Prefer explicit owned parameters or a documented owner that outlives completion, and inspect both initial and later suspension points. Holding a mutex across suspension can also block unrelated work or resume on an unsuitable thread; suspension is a control-flow and ownership boundary, not just syntactic convenience.
110. What does the C++20 coroutine machinery provide, and what must a library supply?
The language supplies a transformation involving a promise object, coroutine state, suspension points, and interactions with awaiters. It does not inherently choose a thread pool, schedule network I/O, or guarantee parallel execution. A library's return type, promise, and awaiters define when execution starts, how results and exceptions are stored, how resumption happens, and who destroys the coroutine state. Review cancellation and completion races in that library's ownership model, particularly when an operation finishes after its consumer disappears. Avoid assuming that co_await means a new thread or that destroying a handle is safe while another thread might resume the same coroutine.
111. Why can std::async code unexpectedly execute serially or block at scope exit?
With the default policy, std::async may select asynchronous execution or deferred execution. A deferred operation runs when an appropriate non-timed wait or get() triggers it, so concurrency is not guaranteed. A future associated with asynchronous execution can also wait when its last reference to the shared state is released under the specified conditions; discarding temporary futures can therefore serialize apparently concurrent calls. Choose std::launch::async when that execution policy is required and retain futures until the intended synchronization point. Still plan for resource exhaustion, exception retrieval, and bounded concurrency: launching one task per input is not automatically a scalable pool.
112. What changes when you add a standard execution policy to an algorithm?
The policy changes permitted execution behavior and imposes constraints on user-provided operations; it is not a promise that the implementation will use multiple threads or run faster. For standard execution-policy overloads, an uncaught exception from a user-invoked function generally causes std::terminate, including with std::execution::seq; this differs from ordinary non-policy overloads. Temporary-resource allocation failure has separate specified behavior. Parallel callbacks must avoid data races, and unsequenced policies require additional care about operations such as locking. Validate iterator requirements, backend support, and exception handling before enabling a policy. Benchmark the complete workload because scheduling and memory traffic can outweigh parallel speedup.
113. How would you investigate a production-only use-after-free without guessing at the fix?
Preserve the failing build, symbols, inputs, and crash evidence, then trace the object's ownership and every route that invalidates its storage. Reproduce with AddressSanitizer where the environment permits, using representative optimization and workload variations; instrumented behavior may differ from production. Inspect asynchronous callbacks, container reallocation, moved owners, and shutdown order rather than simply adding a mutex near the crash. The crashing access can occur long after the lifetime error. Reduce the failure to a small ownership sequence, fix the underlying contract, and add a regression test. A sanitizer-clean test run increases confidence but does not prove that all unexercised lifetime paths are safe.
114. How do AddressSanitizer, UndefinedBehaviorSanitizer, and ThreadSanitizer complement each other?
They target different classes of runtime mistakes rather than serving as interchangeable correctness proofs. AddressSanitizer detects many memory-access errors such as use-after-free and out-of-bounds accesses. UndefinedBehaviorSanitizer checks selected undefined-behavior categories, depending on enabled options. ThreadSanitizer tracks executed concurrency interactions to detect data races. Build supported configurations separately where sanitizer combinations are incompatible, retain debug information, and interpret each diagnostic against the actual source and execution. Coverage, platform limitations, suppressions, and uninstrumented libraries affect what can be observed. Keep static analysis, warnings, code review, and stress tests alongside sanitizers; the absence of a report is not proof of race freedom or defined behavior.
115. How would you plan a C++17-to-C++20 or C++23 migration across a large codebase?
Inventory compiler and standard-library versions, platform baselines, third-party binaries, build tools, and ABI commitments before changing the language flag. Language features and library facilities can arrive on different schedules, so use appropriate feature-test macros and compile probes for the actual facilities required. Establish warning, sanitizer, and regression-test baselines, then migrate bounded components while preserving a reproducible rollback path. Check overload-resolution changes, deprecated or removed facilities, generated code, and tool support. Adopt features because they solve a concrete problem, not to maximize modernization count. Treat deployment compatibility and supported downstream consumers as acceptance criteria alongside successful local compilation.
116. Why can returning by value outperform returning a reference or output parameter?
Returning a value gives the result a clear owner and can benefit from C++17 guaranteed elision in eligible prvalue cases, optional named return value optimization, or a move when applicable. Returning a reference avoids copying only if its referent remains valid; it can force shared storage, aliasing, or awkward caller lifetimes. An output parameter may allow allocation reuse but can complicate failure guarantees and optimization reasoning. Compare the actual types and repeated-call pattern. Avoid gratuitous std::move on a named local in a return statement because it can inhibit NRVO. A simple value-returning API is often a strong starting point, not a universal performance guarantee.
117. How would you design a zero-copy parser without creating dangling views?
Define which object owns the input bytes and ensure every returned view's documented lifetime is bounded by that owner. A parser returning std::string_view fields into a temporary input string creates dangling references even though parsing itself copied no bytes. An owning parsed-document object can keep the buffer and expose short-lived views, or the caller can explicitly retain the input. Account for buffer mutation and reallocation as well as destruction. For asynchronous consumers or long-lived small fields, selective copying may reduce retention cost and simplify safety. Measure total retained memory and lifecycle complexity rather than treating zero copies as an unconditional design goal.
118. How would you analyze initialization-order problems involving global objects?
Identify dependencies between dynamically initialized non-local objects, especially across translation units, where relying on an assumed startup order is fragile. A function-local static can defer initialization until first use and provides thread-safe initialization in modern C++, but recursive initialization and dependencies during destruction still need care. Prefer explicit application-owned construction for services with complex startup and shutdown requirements. Do not solve an order bug by accidentally leaking resources unless process-lifetime allocation is a deliberate documented trade-off. Test startup, normal shutdown, and error exits separately; a design that initializes safely can still fail when one global object's destructor accesses another object already destroyed.
119. How do you evaluate a custom allocator or object pool proposed as a performance fix?
Start with allocation profiles and the actual object lifetime distribution, then define the problem the pool must solve: latency variance, fragmentation, locality, or allocation throughput. Include synchronization, bookkeeping, peak retained memory, alignment, and destruction costs in comparisons. A pool that helps repeated same-size allocations may retain too much memory or contend under a mixed workload. Ensure allocation and deallocation pairing, exception safety, and sanitizer visibility remain understandable. Use standard facilities such as C++17 memory resources when they fit the requirements, but do not assume a custom resource is automatically faster. Keep the simpler allocator if the measured application-level benefit is not material.
120. What should a senior C++ reviewer verify before accepting a performance-oriented API redesign?
Verify correctness and contract clarity first: ownership, lifetime, invalidation, thread safety, exception guarantees, and version requirements must survive the redesign. Then require representative evidence for the claimed benefit, including workload, build flags, hardware, latency distribution, memory use, and regression risks. Inspect whether savings come from genuine reduced work or from shifting costs to callers, retaining memory longer, or weakening guarantees. Consider ABI and source compatibility, diagnostics, maintainability, and fallback behavior. A useful review outcome may be a narrower optimization behind the existing API. Accept a trade-off when it is explicit and justified, not because the implementation uses more advanced language features.
C++ Documentation and Further Reading
These primary references cover language rules, library contracts, implementation support, and diagnostics. The freely available working draft is a living document and may contain features newer than the article baseline; consult the applicable standard edition and toolchain documentation for a particular project. The Core Guidelines are design guidance, not normative language rules.
Similar Posts