Top 60 C++ Interview Questions (2026)

C++ is a compiled, statically typed language built as an extension of C that supports procedural, object-oriented, and generic styles. It adds classes, templates, exceptions, and a standard library while keeping C's direct access to memory and hardware.

It's used where performance and control matter: game engines, web browsers, databases, operating systems, embedded firmware, and low-latency trading. The design principle is zero-overhead abstraction, so you don't pay at runtime for features you don't use.

C is a procedural language with no built-in classes, inheritance, or exceptions. C++ adds object-oriented programming, templates, RAII, references, function and operator overloading, and a much larger standard library, while staying mostly compatible with C so that most C code compiles as C++ with minor changes.

The practical difference is abstraction. C gives you functions and structs; C++ gives you classes with automatic cleanup, generic code through templates, and safer resource handling, all without giving up low-level control.

C++ is compiled: source goes through preprocessing, compilation to object code, and linking into a native executable that the CPU runs directly. There's no interpreter or virtual machine sitting between your program and the hardware, unlike Python or Java. That direct-to-machine model is what gives C++ its speed and its predictable performance.

That's why C++ is fast and why errors show up at compile time instead of runtime. The cost is a build step and platform-specific binaries, but for performance-sensitive work that trade is the point.

The fundamental types are int, char, bool, float, and double, plus void for no value. Modifiers like short, long, signed, and unsigned change the size and range, so long long int holds a wider range than int. The exact sizes are implementation-defined with minimum guarantees the standard sets.

For fixed-width needs, use the types from <cstdint> like int32_t and uint64_t, because relying on int always being 32 bits is a portability bug waiting to happen.

A pointer is a variable that stores the memory address of another object. You get an address with &, and you access the pointed-to value by dereferencing with *. A pointer that points to nothing should be nullptr.

Pointers let you share and modify data without copying, build dynamic structures like linked lists, and manage heap memory. They're also the source of most C++ bugs: dangling pointers, null dereferences, and leaks, which is why modern code prefers smart pointers.

A reference is an alias for an existing object. It's bound once at initialization, can't be reseated, and can't be null in well-defined code. A pointer is a separate variable holding an address that can be reassigned, set to nullptr, and dereferenced.

Prefer references when the thing must always refer to a valid object and never changes target, like a function parameter you don't want copied. Use pointers when you need to represent absence (nullptr) or rebind to different objects.

Pass by value copies the argument, so the function works on its own copy and the caller's variable is untouched. Pass by reference gives the function an alias to the caller's object, so changes are visible and nothing is copied. Pass by pointer is similar but the argument can be nullptr and must be dereferenced.

For large objects you don't intend to modify, pass by const reference: no copy, no accidental mutation. That's the default choice the question expects for anything bigger than a machine word.

new allocates an object on the heap and returns a pointer to it; delete frees that memory and runs the destructor. For arrays you use new[] and the matching delete[]. Every new needs exactly one delete, or you leak memory.

In modern C++ you rarely call these directly. Smart pointers and containers manage heap memory for you, so raw new/delete in application code is usually a sign the ownership design needs work.

Stack memory holds local variables and function call frames. It's fast, automatically reclaimed when a scope ends, and limited in size. Heap memory is allocated on demand with new (or malloc), lives until you free it, and is much larger but slower to allocate.

Prefer the stack: objects clean themselves up and there's nothing to leak. Reach for the heap when an object must outlive the scope that created it or when the size isn't known at compile time.

const marks something as read-only and lets the compiler enforce it. It applies to variables (const int max = 10), function parameters (const T&), member functions that promise not to modify the object, and pointers in two positions with different meanings.

const int* p is a pointer to a const int (can't change the value); int* const p is a const pointer (can't reseat it). Const-correctness catches accidental mutation at compile time and documents intent, which reviewers read as care.

A reference is declared with & in the type and must be initialized to an existing object: int& r = x;. From then on r is just another name for x, so reading or writing r reads or writes x. There's no separate reference object to reseat.

The common uses are function parameters (avoid copies, allow modification) and return values (return a reference to an existing object, never to a local). Returning a reference to a local variable is a classic dangling-reference bug.

A C-style array has a fixed size known at compile time and no built-in size tracking or bounds safety. std::vector is a dynamic array from the standard library that manages its own memory, grows as you add elements, knows its own size, and frees itself when it goes out of scope.

Prefer std::vector in almost all C++ code. It gives you RAII, .size(), .at() with bounds checking, and iterators, while raw arrays leave you managing length and lifetime by hand.

std::string is the standard library's dynamic string type. It manages its own memory, resizes automatically, knows its length, and offers methods for concatenation, searching, and substrings. A char array (C-string) is a fixed buffer terminated by a null character with none of that safety.

Use std::string for anything but the lowest-level code. It removes buffer-overflow risk and manual length tracking, and it converts to a C-string with .c_str() when a legacy API needs one.

std::cout writes to standard output using the insertion operator <<, and std::cin reads from standard input using the extraction operator >>. They're defined in <iostream> and live in the std namespace. std::endl inserts a newline and flushes the buffer.

Chaining works because each << and >> returns the stream. For performance in loops, prefer '\n' over std::endl to skip the flush, and check the stream state after reading to catch bad input.

The only language-level difference is default access: struct members are public by default, while class members are private by default. The same default applies to inheritance, public for struct and private for class. Everything else, methods, constructors, inheritance, access specifiers, is available to both, so the choice is really about convention.

By convention, struct is used for plain data aggregates with public fields, and class is used when there's encapsulation and behavior. That convention communicates intent even though the compiler treats them almost identically.

A constructor runs when an object is created and sets up its initial state; it has the class name and no return type, and can be overloaded. A destructor runs when the object is destroyed and releases resources; it's the class name prefixed with ~ and takes no arguments.

Destructors are the heart of RAII: acquire a resource in the constructor, release it in the destructor, and cleanup happens automatically on scope exit, even during an exception. That pairing is why C++ rarely needs try/finally.

Encapsulation means bundling data with the functions that operate on it and hiding the internal state behind a controlled interface. C++ supports it with access specifiers: private members are hidden, public members form the interface, and protected members are visible to derived classes.

The point is that callers depend on the public interface, not the internal representation, so you can change the internals later without breaking them. Getters and setters, or better, meaningful methods, guard invariants that raw public fields can't.

public members are accessible from anywhere that can see the object. private members are accessible only inside the class itself and its declared friends. protected members are accessible inside the class and its derived classes, but not from outside code. The specifier applies to every member listed under it until the next one.

Default to private for data and expose behavior through public methods. Use protected sparingly, because it couples derived classes to the base's internals and makes the base harder to change.

Function overloading lets several functions share a name as long as their parameter lists differ in number or types. The compiler picks the right one at compile time based on the arguments you pass. Return type alone can't distinguish overloads.

It's useful for operations that make sense on different types, like a print that takes an int, a double, or a string. Overload resolution is a compile-time mechanism, so there's no runtime cost.

A default argument is a value the compiler supplies when the caller omits that parameter. They're declared in the function declaration and must come after all non-default parameters, because arguments are matched left to right.

Put the default in the declaration (usually the header), not the definition, to avoid duplicate-default errors. Defaults reduce overload count, but too many can hide which parameters callers actually care about.

A namespace groups related names to prevent collisions, so two libraries can both define a Timer without clashing. The standard library lives in namespace std, which is why you write std::cout or bring specific names in.

Avoid using namespace std; at file scope, especially in headers, because it dumps every standard name into your scope and can silently pick the wrong overload or cause ambiguities. Qualify names or pull in only what you use.

static has a few related meanings by context. A static local variable keeps its value between calls and is initialized once. A static member belongs to the class, not any instance, and is shared across all objects. A static function or variable at file scope has internal linkage, so it's private to that translation unit.

The unifying idea is a single, persistent instance rather than one per object or per call. Interviewers often ask you to distinguish these three uses, so The context each time.

Header files (.h or .hpp) declare interfaces: class definitions, function prototypes, templates. Source files (.cpp) hold the implementations. Other files include the header to see the interface, and the linker connects those uses to the compiled definitions.

Include guards (or #pragma once) stop a header from being included twice in one translation unit, which would cause redefinition errors. Without them, any header included transitively more than once breaks the build.

A C++ build runs in four stages. The preprocessor expands #include, #define, and conditional directives into a single translation unit. The compiler turns that into object code and reports syntax and type errors. The assembler produces machine code, and the linker joins all object files and libraries into one executable, resolving symbols across files.

Knowing these stages explains real errors: a missing header is a preprocessor or compile error, while a missing definition of a declared function is a linker error. Those are different failures with different fixes.

A macro is a preprocessor text substitution done before compilation with #define. Because it's blind text replacement, macros ignore scope and types, so a function-like macro can evaluate arguments twice or bind operators wrong without parentheses. They also don't show up in the debugger as themselves.

Modern C++ replaces most macros: const or constexpr for constants (they're typed and scoped), and inline functions or function templates for macro-like helpers (they respect types and evaluate arguments once). Reserve macros for include guards and conditional compilation, where there's no real alternative.

RAII, Resource Acquisition Is Initialization, ties a resource's lifetime to an object's scope. You acquire the resource in the constructor and release it in the destructor, so when the object goes out of scope the resource is freed automatically, even if an exception unwinds the stack.

It's the reason C++ can be safe without a garbage collector. Files, locks, memory, and sockets all become self-managing objects. Smart pointers, std::lock_guard, and std::vector are RAII types you already use.

Smart pointers are RAII wrappers around raw pointers that free memory automatically. std::unique_ptr is sole ownership with zero overhead: it can't be copied, only moved. std::shared_ptr allows shared ownership with a reference count and frees the object when the last owner dies. std::weak_ptr is a non-owning observer of a shared_ptr that breaks reference cycles.

Default to unique_ptr; it covers most cases and costs nothing over a raw pointer. Reach for shared_ptr only when ownership is genuinely shared, and use weak_ptr to point back without keeping the object alive.

A memory leak happens when you allocate with new and never delete, so the memory is never reclaimed. A dangling pointer points to memory that's already been freed, and dereferencing it is undefined behavior. Both come from manual lifetime management going wrong.

Prevent both by not managing raw memory by hand. Use smart pointers for ownership, containers for collections, and RAII for every resource. When you do hold a raw pointer, treat it as a non-owning observer and never delete through it.

A derived class inherits the members of its base class and can add or override behavior. Public inheritance models an is-a relationship, so a Dog is-an Animal. The derived class gets the base's public and protected members and can call the base constructor in its initializer list.

C++ also allows multiple inheritance, which brings power and the diamond problem when two bases share a common ancestor. That's solved with virtual inheritance, but many designs avoid the situation by preferring composition.

A virtual function lets a derived class override a base class method so that calling through a base pointer or reference runs the most-derived version. This is runtime polymorphism, and it's resolved through a per-class table of function pointers called the vtable.

Each polymorphic object carries a hidden pointer to its class's vtable; a virtual call looks up the right override at runtime. That indirection has a small cost, which is why not every function is virtual by default in C++.

When you delete a derived object through a base class pointer, the destructor call is dispatched like any function. If the base destructor isn't virtual, only the base part is destroyed, the derived destructor never runs, and you leak whatever the derived class owned. That's undefined behavior.

The rule is simple: if a class has any virtual function, or is meant to be used through base pointers, give it a virtual destructor. Making it = default keeps it free to write.

A pure virtual function is declared with = 0 and has no implementation in the base class. Any class with at least one pure virtual function is abstract and can't be instantiated; it exists to define an interface that derived classes must implement.

This is how C++ expresses interfaces. A class of only pure virtual functions plus a virtual destructor is the C++ equivalent of a Java interface. Derived classes become concrete once they override every pure virtual.

Compile-time (static) polymorphism is resolved by the compiler: function overloading and templates pick the right code based on types known at compile time, with no runtime cost. Runtime (dynamic) polymorphism is resolved while the program runs, through virtual functions and the vtable.

Use static polymorphism when the types are known at compile time and you want zero overhead. Use dynamic polymorphism when you need to treat different concrete types uniformly through a common base interface at runtime.

Templates let you write code once that works for many types. The compiler generates a concrete version for each type you actually use, so you get generic code with no runtime cost. A function template parameterizes a function; a class template parameterizes a whole class, like std::vector<T>.

The standard library's containers and algorithms are templates. The trade-offs to mention are longer compile times and error messages that can get dense, though concepts in C++20 make those messages far clearer.

The Standard Template Library is the part of the C++ standard library built on templates. Its three pillars are containers (vector, map, set, list, and more), algorithms (sort, find, accumulate, transform), and iterators, which the two by giving algorithms a uniform way connects to traverse any container.

The design lets one algorithm work on any container: std::sort works on a vector or a deque because both provide the iterators it needs. Knowing which container fits which access pattern is exactly what intermediate interviews probe.

std::vector is a contiguous dynamic array: fast index access and iteration, cheap push_back at the end. std::list is a doubly linked list: fast insert and erase anywhere, but no random access and poor cache behavior. std::map is an ordered tree with O(log n) lookup; std::unordered_map is a hash table with average O(1) lookup but no ordering.

The default is vector, because contiguous memory is cache-friendly and wins in practice more often than big-O suggests. Use unordered_map for fast key lookup, map when you need keys sorted, and list rarely, only when you insert and erase in the middle constantly.

An iterator is an object that points into a container and knows how to move to the next element, generalizing the idea of a pointer. Algorithms operate on iterator ranges (begin, end) rather than specific containers, which is what makes the STL composable.

The categories, from weakest to strongest, are input, output, forward, bidirectional, and random-access. A vector gives random-access iterators (jump anywhere in O(1)); a list gives bidirectional ones (step forward or back only). An algorithm's requirements tell you which containers it supports.

A copy constructor creates a new object as a copy of an existing one. Its signature takes a const reference to the same class: MyClass(const MyClass& other). It's called when you initialize one object from another, pass an object by value, or return one by value (subject to elision).

The compiler generates a member-wise copy for you. That's fine until the class owns a raw resource like heap memory, where a shallow copy leaves two objects pointing at the same buffer, a double-free waiting to happen. That case needs a hand-written deep copy.

Rule of Three: if a class needs a custom destructor, copy constructor, or copy assignment, it almost certainly needs all three, because it's managing a resource. Rule of Five extends that to the move constructor and move assignment once move semantics enter the picture.

Rule of Zero is the modern goal: design classes so they need none of these by holding resources in types that already manage themselves (smart pointers, containers). Then the compiler-generated special members just work, and you write less error-prone code.

Operator overloading lets you define what operators like +, ==, or << mean for your own types, so a Vector2 can support v1 + v2 or a Money type can compare with ==. You implement them as member or free functions with special names like operator+.

Use it only when the operator's meaning is obvious for your type, math types, string-like types, comparisons. Overloading operators to do something surprising hurts readability, so the test is whether a reader would guess the behavior correctly.

You throw an exception with throw, catch it with try/catch, and the runtime unwinds the stack from the throw point to the matching handler, running destructors along the way. That stack unwinding is why RAII makes exceptions safe: resources release automatically as scopes exit.

Catch by const reference to avoid slicing and copying (catch (const std::exception& e)), throw by value, and derive custom exceptions from std::exception. Destructors should not throw, because an exception escaping a destructor during unwinding terminates the program.

auto tells the compiler to deduce a variable's type from its initializer at compile time. It's not dynamic typing; the type is fixed and known, you just don't spell it out. It's most useful for verbose types like iterators and for making generic code read cleanly.

Use auto to cut noise (auto it = m.begin() instead of the full iterator type) and to avoid accidental conversions. Be explicit when the exact type matters for readability, and remember auto strips references and const unless you write auto& or const auto&.

A lambda is an anonymous function object you can define inline, useful for short callbacks passed to algorithms. The capture list in square brackets controls which surrounding variables the lambda can use: [=] captures by value (a copy), [&] captures by reference, or you name specific variables.

Capture by reference only when the lambda won't outlive the captured variables, or you get a dangling reference. Lambdas that capture nothing convert to plain function pointers; those that capture become unnamed function objects the compiler generates.

const means a value won't change after initialization, but that value can be computed at runtime. constexpr means the value can be computed at compile time and can be used where a compile-time constant is required, like an array size or template argument.

Every constexpr is implicitly const, but not every const is constexpr. Prefer constexpr for true compile-time constants and functions you want evaluated during compilation; it moves work out of runtime entirely.

Move semantics let you transfer ownership of a resource instead of copying it. When an object is about to be destroyed anyway, like a temporary, its guts (a heap buffer, a file handle) can be stolen rather than duplicated. A move constructor and move assignment take an rvalue reference and leave the source in a valid but empty state.

The payoff is performance: returning a large vector or passing one through layers no longer copies megabytes. std::move casts to an rvalue reference to opt into moving. Combined with copy elision, this is why modern C++ returns big objects by value without guilt.

An lvalue is an expression that names a persistent object with an address you can take, like a variable. An rvalue is a temporary or literal that doesn't have a stable identity, like the result of a + b or the number 5. The distinction drives which overloads and reference bindings apply.

An rvalue reference (T&&) binds to rvalues and is the hook for move semantics: it lets you detect 'this thing is about to disappear, so I can steal from it.' Named rvalue references are themselves lvalues, which is why you still write std::move inside a move constructor.

Perfect forwarding passes arguments through a template function to another function while preserving their value category (lvalue vs rvalue) and const-ness. It's what lets wrappers like std::make_unique forward constructor arguments without extra copies or losing move-ability.

A template parameter written as T&& is a forwarding (universal) reference: it binds to both lvalues and rvalues, and reference collapsing decides the actual type. You forward it with std::forward<T>(arg), which casts back to the original category. Use std::forward, not std::move, in this position.

Undefined behavior means the standard places no requirements on what happens: the program might crash, produce garbage, or appear to work until it doesn't. The compiler is allowed to assume UB never happens, which is why it can silently delete code or produce baffling results.

Common causes: dereferencing a null or dangling pointer, reading uninitialized memory, out-of-bounds array access, signed integer overflow, use-after-free, and violating the one-definition rule. The senior habit is compiling with warnings, sanitizers (ASan, UBSan), and treating UB as a bug to eliminate, not a quirk to route around.

For each polymorphic class the compiler builds a vtable: an array of pointers to that class's virtual function implementations. Every object of the class stores a hidden vptr pointing at its class's vtable. A virtual call reads the vptr, indexes into the vtable, and jumps, so it's one extra indirection over a normal call.

The costs are one pointer per object (the vptr) and the missed inlining plus the indirect jump per call. For hot inner loops this matters, which is why C++ makes you opt into virtual rather than paying for it everywhere. Devirtualization can remove the cost when the compiler proves the concrete type.

Object slicing happens when you copy a derived object into a base object by value: only the base part is copied, and the derived data and behavior are sliced off. The result is a plain base object, and virtual calls on it no longer reach the derived override.

Avoid it by handling polymorphic objects through base pointers or references, never by value. Storing a std::vector<Base> slices; a std::vector<std::unique_ptr<Base>> preserves the full objects. Deleting the copy operations on a polymorphic base also makes accidental slicing a compile error.

Since C++11 the standard defines a memory model that says when writes by one thread become visible to another and what counts as a data race. A data race, two threads accessing the same memory with at least one write and no synchronization, is undefined behavior. std::atomic and mutexes provide the synchronization that makes access well-defined.

std::atomic operations take a memory order (seq_cst by default, down to relaxed) that controls how much reordering the compiler and CPU may do around them. Most code should stick with the default sequential consistency; relaxed and acquire/release orderings are for measured, well-understood hot paths.

Template metaprogramming uses templates to compute types and values at compile time: think type traits, tag dispatch, and SFINAE to enable or disable overloads based on properties of types. It made generic libraries possible but produced dense code and brutal error messages.

Modern C++ replaced much of it with clearer tools: constexpr functions run ordinary-looking code at compile time, if constexpr branches on compile-time conditions inside one function, and C++20 concepts state template requirements directly with readable errors. Knowing both the old machinery and the modern replacements is The production-ready answer.

RAII frees resources deterministically at scope exit, so you know exactly when a file closes or a lock releases, and it handles any resource, not just memory. Garbage collection reclaims memory automatically at unpredictable times and doesn't help with non-memory resources like sockets or handles.

RAII's cost is that you design ownership explicitly and can still create cycles that leak with shared_ptr. GC's cost is pause times, higher memory overhead, and no help for non-memory cleanup. C++ chooses determinism and control; that fit is why it dominates latency-sensitive systems.

Pimpl (pointer to implementation) hides a class's private members behind a pointer to a forward-declared implementation struct defined in the .cpp. The header exposes only the public interface and an opaque pointer, so changing private members doesn't force every including file to recompile.

It buys compile-time isolation and a stable ABI for libraries, at the cost of a heap allocation and an extra indirection per access. Worth it for widely-included headers and library boundaries; overkill for internal classes where the recompile cost is small.

C++11 was the big modernization: auto, range-based for, lambdas, smart pointers, move semantics, rvalue references, nullptr, and the threading library. C++14 refined it with generic lambdas and return-type deduction. C++17 added structured bindings, if constexpr, std::optional, std::variant, and std::string_view. C++20 brought concepts, ranges, coroutines, and modules.

For interviews, the through-line matters more than the checklist: each standard pushed C++ toward safer defaults and clearer generic code. Naming what you actually use, and why, reads better than reciting the full list.

If two objects hold shared_ptrs to each other, their reference counts never reach zero even after every external owner is gone, so neither is ever freed. The cycle keeps itself alive. This is the one leak that smart pointers don't solve on their own.

Break the cycle by making one direction a std::weak_ptr, typically the back-pointer (child to parent, observer to subject). weak_ptr doesn't increment the count, so when the last shared_ptr goes, the objects are destroyed, and you check the weak_ptr with lock() before use.

Copy elision lets the compiler skip copy or move constructors and build the object directly in its destination. Return value optimization (RVO) is the common case: a function returning a local object constructs it straight into the caller's storage, so no copy or move happens at all.

Since C++17, elision of a returned temporary is guaranteed, not just permitted. The practical rule: return by value freely; don't write return std::move(local), because that actually blocks RVO by turning a named object into an rvalue expression the compiler can't elide the same way.

static_cast does compile-time-checked conversions between related types (numeric conversions, up/down the hierarchy without runtime check). dynamic_cast does a runtime-checked downcast in a polymorphic hierarchy, returning nullptr (or throwing for references) on failure. const_cast adds or removes const. reinterpret_cast reinterprets the bit pattern, the sharpest and least safe tool.

Prefer static_cast for ordinary conversions and dynamic_cast when you genuinely need to test a runtime type. Reach for const_cast and reinterpret_cast rarely and with a comment, because they're where UB tends to hide. C-style casts are discouraged precisely because they silently pick whichever of these applies.

Reproduce or observe first: capture the core dump and open it in a debugger for the stack at the crash, and pull logs around the failure. If it's intermittent memory corruption, rebuild with AddressSanitizer and UBSan and run the workload, because they catch use-after-free, buffer overflows, and UB that a normal build hides.

Then narrow: valgrind or ASan for the exact bad access, correlate with recent changes, and check the usual suspects, dangling references, ownership handed to two owners, iterator invalidation after a container mutation, and threading races. Fix at the right layer and confirm with the sanitizer clean. The method matters more than any single tool: observe, isolate, hypothesize, verify.

Clarify capacity and the required operations first, then reach for the standard pattern: a doubly linked list to track recency order plus a hash map from key to the list node. get moves the node to the front and returns its value; put inserts at the front and evicts the back node when over capacity. Both operations are O(1).

In C++ that's std::list for the order and std::unordered_map<Key, std::list<...>::iterator> for the lookup, since list iterators stay valid across other insertions and erasures. The closing step is the edges: thread safety (wrap with a mutex if shared), and whether eviction needs a callback. Structuring the answer, clarify, data structures, complexity, edges, is what's really being evaluated.