C++ Interview Questions

"A reference is another name for an existing object. It has to be bound when it's declared, it can't be made to refer to something else later, and in valid code there's no such thing as a null reference. A pointer is its own variable that holds an address, so it can be null, it can be pointed at a different object, and you can do arithmetic on it. In function signatures I use a const reference for inputs that must exist and are too big to copy, a plain reference when the function has to modify the caller's object, and a pointer only when 'nothing' is a valid answer, like an optional output. For ownership I don't use raw pointers at all, I use smart pointers, so a raw pointer or reference in my code just means 'I'm borrowing this'."

"The trick is to read it right to left. const int* p is a pointer to a const int: I can make p point somewhere else, but I can't change the value through it. int* const p is a const pointer to an int: p is stuck on one address, but I can change the value. A member function with const after the parameter list promises not to change the object's state, and that matters a lot in practice, because if I pass an object by const reference, which I do all the time, I can only call its const member functions. So if someone forgets to mark a getter const, it can't be used on const objects. If a member really needs to change inside a const function, like a cache or a mutex, it gets marked mutable."

"The basic guarantee says that if an operation throws, nothing leaks and every object is still valid, though the state may have changed. The strong guarantee says it either succeeds completely or leaves everything exactly as it was, like a transaction. Copy-and-swap is the usual way to get it: do the risky work on a copy, then swap it in with an operation that can't throw. The no-throw guarantee means the operation never throws, and that's what destructors, swap and move operations should give, because the other guarantees are built on them. Destructors are implicitly noexcept since C++11, so if an exception escapes one, std::terminate is called. Even without that, a destructor that throws while another exception is already unwinding the stack terminates the program. So if cleanup can fail, like a flush on close, I offer an explicit close function that can report errors, and the destructor only does a best effort and swallows or logs."

"A lambda expression creates an unnamed object, a closure, and each captured variable becomes a member of it. Capture by value copies the variable when the lambda is created. Capture by reference stores a reference, so it sees later changes but depends on the original still being alive. The bug happens when the lambda outlives the scope it was made in. If a function returns a lambda that captured a local by reference, or hands it to a thread or an event queue, the local is gone by the time the lambda runs, and it reads a dangling reference. That's undefined behaviour and often shows up as random values. Capturing this has the same risk if the object is destroyed first. So when a lambda escapes its scope I capture by value, use an init capture to move things in, or capture a shared_ptr or weak_ptr to keep the object alive or check it."

"I understand the reaction, a crash in production is painful. But catching everything in every function and carrying on is usually worse than the crash. The code after a swallowed exception runs on state that may be half updated, so we trade a loud crash for silent wrong results, and we lose the stack context that tells us what happened. I'd suggest two things. First, find out what actually threw and fix that. Second, catch at the few boundaries where we can really do something: the top of each request handler, where we can log with context and return an error, each thread's entry function, since an exception escaping a thread calls std::terminate, and main. Inside the code we rely on RAII so unwinding leaves everything clean, and we only catch specific exceptions where there's a real recovery, like retrying a network call."

"A local object has automatic lifetime. It's created where it's declared and its destructor runs when it goes out of scope, whether the function returns normally or an exception leaves it. An object created with new has dynamic lifetime: it lives on the free store until someone calls delete on it, and if nobody does, that's a leak. The pairing rule is strict. new goes with delete and new[] goes with delete[], because the array form has to run the destructor for every element and may track the count differently. Mixing them is undefined behaviour, which can mean a crash, heap corruption, or silently skipping destructors. In modern code I rarely write new or delete at all. I use locals where I can, std::vector instead of new[], and make_unique when I really need heap lifetime."

"RAII means tying a resource's lifetime to an object's lifetime. The constructor acquires the resource, the destructor releases it, and because C++ guarantees destructors run when an object goes out of scope, including during stack unwinding from an exception, the cleanup can't be forgotten. It's not just memory. A lock_guard locks a mutex in its constructor and unlocks it in its destructor, so an early return or an exception can't leave the mutex locked. An fstream closes its file, a unique_ptr frees its object. Compared to manual cleanup, the big win is that correctness doesn't depend on every code path remembering to release things. Add a new early return next year and it's still correct. When I write a class that wraps a handle from a C library, I make it an RAII wrapper so the rest of the code never sees the raw close call."

"My first suspicion is undefined behaviour, not a compiler bug. Debug builds often hide it: memory gets filled with patterns, variables stay on the stack, and code runs in the order it's written. The optimiser is allowed to assume undefined behaviour never happens, so things like an uninitialised variable, reading past the end of an array, using freed memory, signed overflow in a loop or a data race between threads can suddenly break. So I'd get a reliable reproduction, then build with optimisation plus AddressSanitizer and UndefinedBehaviorSanitizer, and ThreadSanitizer if threads are involved. I'd turn warnings up and read them. I'd also build the release configuration with debug symbols so I can see a real stack trace from the crash. If that still doesn't find it, I'd bisect recent commits. Only after all of that would I suspect the compiler itself, and I'd want a tiny reproducer before claiming it."

"The initialiser list is the part after the colon. It constructs each member directly with its value. If I assign in the body instead, each member is first default-constructed and then assigned, which is wasted work for something like a string, and it doesn't work at all for const members, reference members, or members with no default constructor. One trap: members are always initialised in the order they're declared in the class, not the order I write them in the list. So if one initialiser reads a member that's declared later, it reads an uninitialised value. Compilers warn about a mismatched order, and I keep that warning on. explicit goes on constructors that take one argument, so the compiler won't use them for implicit conversions. Without it, a function that takes a Temperature would quietly accept a plain double, and that kind of bug is easy to miss in review."

"The rule of three says that if a class needs a hand-written destructor, copy constructor or copy assignment, it almost certainly needs all three, because it's managing a resource directly. If you write only the destructor, the compiler's copy does a shallow copy of the pointer and you get a double delete. C++11 added move construction and move assignment, which makes it the rule of five. A detail people miss is that declaring a destructor or a copy operation stops the compiler from generating the move operations, so moves silently become copies. In new code I aim for the rule of zero. I put resources into members that already manage themselves, like std::vector, std::string or std::unique_ptr, and then the compiler-generated versions are correct and I write none of them. Only a small, dedicated resource-wrapper class should ever need the full five."

"The default copy just copies the pointer, so two objects would own one array and both destructors would delete it. That's a double free. The copy constructor allocates its own array of the same size and copies the elements. For assignment I use copy-and-swap: the parameter is taken by value, so the copy constructor does the allocation, then I swap my contents with the parameter's and let its destructor free my old array. It handles self-assignment for free and it's exception safe: if the allocation throws, it throws before my object has changed at all. The swap is marked noexcept, because the whole guarantee rests on that last step never failing. In real code I'd just use std::vector and write none of this, but it's a good test of whether you understand ownership."

"An rvalue reference, written T&&, binds to things that are about to go away, like temporaries, which lets a class write a move constructor that steals their resources instead of copying them. std::move doesn't move anything. It's just a cast that says 'treat this as an rvalue'. The actual move happens only if that cast makes overload resolution pick a move constructor or move assignment. If the type has no move operations, you get a copy. If the object is const, you also get a copy, because a const rvalue can't bind to a non-const T&&. After a move, standard library objects are left valid but in an unspecified state, so I can assign to them or destroy them but shouldn't read their value. One more trap: a named rvalue reference parameter is itself an lvalue, so inside the function you need std::move again to pass it on as an rvalue."

"The move constructor takes the other object's pointer and size and leaves the other one empty, with a null pointer, so its destructor does nothing harmful. std::exchange makes that neat. Move assignment does the same, but first frees my own buffer, and I guard against moving an object into itself. The noexcept part really matters. When a vector runs out of capacity, it allocates a bigger array and transfers the elements. It promises that if something throws halfway through, the original vector is unchanged. It can only keep that promise with moves if the move can't throw, because a half-finished move can't be undone. So if the move constructor isn't marked noexcept and the type can be copied, the vector copies every element on growth instead. That's a silent performance hit I've seen in real code. Since these moves only swap pointers, they genuinely can't throw, so marking them noexcept is honest."

"If I have Base* p = new Derived and later call delete p, the compiler needs to know the real type to destroy it properly. With a virtual destructor, the call goes through virtual dispatch, the Derived destructor runs first, then the Base one. Without it, the behaviour is undefined by the standard. What usually happens is that only the Base destructor runs, so anything Derived owns, like a file, a buffer or a socket, never gets released. The same applies to a unique_ptr of Base holding a Derived. So my rule is: if a class has any virtual functions and is meant to be deleted through a base pointer, it gets a public virtual destructor, usually just virtual ~Base() = default. If a base isn't meant to be deleted that way, I make its destructor protected and non-virtual so the mistake won't compile."

"The standard doesn't say how, but every major compiler uses the same idea. For each class with virtual functions, the compiler builds a table of function pointers, one slot per virtual function, pointing at that class's version. Each object gets a hidden pointer to its class's table, set by the constructor. When I call p->draw() through a base pointer, the generated code loads the object's table pointer, picks the draw slot, and calls through it. So the cost is one extra pointer in every object, a couple of loads and an indirect call, and more importantly the compiler usually can't inline the call. In most code that's irrelevant. In a tight loop over millions of small objects it can matter, and then I look at marking classes final so the compiler can devirtualise, or at grouping objects by type."

"Overloading is several functions with the same name but different parameter lists, and the compiler picks one at compile time from the argument types. Overriding is when a derived class provides its own version of a base class virtual function with the same signature, and the choice happens at runtime based on the object's real type. The override keyword matters because without it a tiny mismatch, like a missing const or an int where the base takes a long, silently creates a new function instead of overriding. The code compiles, and the base version gets called at runtime. With override, that's a compile error. There's also a related trap called name hiding: if the derived class declares any function named draw, it hides all the base class overloads of draw, and you need a using declaration to bring them back."

"A class is abstract if it has at least one pure virtual function, which is a virtual function declared with = 0. You can't create an object of an abstract class, but you can have pointers and references to it. A derived class is still abstract until it overrides every pure virtual function it inherits. To get what other languages call an interface, I write a class with only pure virtual functions and a virtual destructor, no data members. Code then depends on that interface through a reference or a smart pointer, which makes it easy to swap implementations or pass a fake one in a unit test. One detail that surprises people is that a pure virtual function can still have a body, which derived classes can call explicitly, but it doesn't make the class concrete."

"It calls the base class version. While the base constructor is running, the object's dynamic type is the base class, because the derived part hasn't been constructed yet. That's deliberate: if C++ dispatched to the derived override, that function could read derived members that haven't been initialised, which would be far worse. The same thing happens in reverse in destructors, since by the time the base destructor runs, the derived part is already gone. If the function is pure virtual in the base, calling it from the constructor is undefined behaviour, and many implementations abort with a 'pure virtual function called' message. When I need derived-specific setup, I either pass the needed values into the base constructor as arguments, or I use a factory function that constructs the object fully and then calls an init step."

"Slicing happens when a derived object is copied into a variable of the base type. Only the base part is copied, the derived data is cut off, and the new object really is a Base, so virtual calls on it go to the base versions. The common places it sneaks in are a function that takes Shape by value instead of by reference, and a std::vector of Shape where people push Circles. Everything compiles, but every draw call does the base behaviour. The fixes are to pass polymorphic objects by reference or pointer, and to store them as std::vector of std::unique_ptr of Shape. On polymorphic base classes I often delete or protect the copy operations so that an accidental by-value copy doesn't compile at all. Catching exceptions by value is another place it bites, which is why I always catch by const reference."

"unique_ptr means exactly one owner. It can't be copied, only moved, and when it goes out of scope the object is deleted. With the default deleter it costs about the same as a raw pointer. shared_ptr is for when several parts of the program really share ownership and nobody knows who'll be last. It keeps a reference count in a separate control block, and copying it updates that count atomically, so there's a real cost in memory and in every copy. I default to unique_ptr because it makes ownership obvious from the type, it's cheaper, and it's easy to turn into a shared_ptr later if needed, while going the other way isn't possible. Most of the time, a function that just uses an object shouldn't take a smart pointer at all. It takes a reference or a raw pointer, because it's only borrowing."

"shared_ptr frees an object when its count reaches zero. If a parent holds a shared_ptr to its child and the child holds a shared_ptr back to its parent, then even when the rest of the program drops them, each keeps the other's count at one and both leak. weak_ptr fixes that. It points at an object managed by shared_ptr without adding to its owner count. So I decide which direction is ownership, here parent owns child, and make the back link a weak_ptr. To use it, I call lock(), which gives me a shared_ptr if the object still exists or an empty one if it's gone, and I check that before using it. It's also useful for caches and observer lists, where I want to know about an object without keeping it alive."

"shared_ptr needs a control block for the counts. With shared_ptr<T>(new T), that's two allocations: one for the object, one for the control block. make_shared does a single allocation holding both, which is faster and friendlier to the cache. It also means there's no bare new in the code, and before C++17 it avoided a real leak when a shared_ptr was built inside a function call alongside another argument that could throw. There are cases where it's worse. You can't give make_shared a custom deleter. And because the object and control block share one allocation, the object is destroyed when the last shared_ptr goes, but the memory isn't returned until the last weak_ptr goes too. So for a large object watched by long-lived weak_ptrs, the separate allocation can be the better choice."

"I'd start by agreeing with the goal, because raw owning pointers really do cause leaks and crashes. But I'd explain that shared_ptr everywhere doesn't remove the need to think about ownership, it hides it. Every copy updates an atomic count, which costs something in hot paths. Objects live as long as anyone holds a copy, so lifetimes become hard to predict, which is bad for things like file handles or locks. And any two objects pointing at each other form a cycle that leaks, which is exactly the bug we were trying to kill. I'd suggest a simple rule instead: unique_ptr by default, shared_ptr only when several owners genuinely share the object and we can say why, and plain references or raw pointers for functions that only borrow. I'd offer to write that up as a short guideline and pair on converting one module so we can compare."

"A template isn't code by itself, it's a recipe. When I use max<int> or vector<Order>, the compiler instantiates the template for those arguments and generates real functions or classes. To do that it needs to see the whole definition in the file it's compiling. If I put a template's definition in a .cpp file and only the declaration in the header, other files compile fine but nothing generates the code for their types, so the build fails at link time with undefined symbols. That's why templates live in headers. There's an alternative, explicit instantiation, where the .cpp lists the exact types to generate, which works when the set of types is known. The costs of templates are compile time, since every file that uses them does the work, larger binaries from many instantiations, and hard error messages, which C++20 concepts improve by stating requirements up front."

"Specialization lets me give a template a different definition for particular arguments. A full specialization covers one exact type. A partial specialization covers a pattern, like any pointer type, but that's only allowed for class templates. For function templates I use an overload instead. A very common real use is hashing. unordered_map needs to hash its keys and compare them for equality. For my own struct there's no hash, so I either specialise std::hash for it, which the standard allows for user-defined types, or pass a hasher as a template argument to the map. I also need operator== so the map can tell apart keys that hash to the same bucket. The hash doesn't need to be perfect, but it should spread keys well, because a bad hash puts everything into a few buckets and lookups slow down towards linear."

"A vector keeps its elements in one contiguous block, with a size and a capacity. When push_back finds size equal to capacity, it allocates a bigger block, usually growing by a multiple so the average cost of push_back stays constant, moves or copies the elements across and frees the old block. At that point every iterator, pointer and reference into the vector is invalid, because the elements live somewhere else now. If there's no reallocation, insert and erase invalidate things only at and after the position you changed, since those elements shift. The classic bug is taking a pointer to an element, pushing more items, and then using the pointer. If I know the final size, reserve avoids the reallocations, and if I need stable addresses while adding, I store indexes, or use std::list, or std::deque if I only add at the ends, since that keeps references to existing elements valid."

"The naive loop erases at it and then does ++it, but erase invalidates it, so incrementing is undefined behaviour. It often skips elements or runs past the end. The fix in a loop is to use the return value of erase, which is an iterator to the element after the one removed, and only increment when I didn't erase. That's correct but slow for a vector, because every erase shifts the rest of the elements, so it can be quadratic. The idiomatic version is erase-remove. std::remove_if walks once, moves the elements I want to keep to the front and returns the new logical end, then one erase call chops off the tail. That's a single linear pass. In C++20 std::erase_if wraps the whole thing in one call, and it's what I'd write today."

"std::map is a balanced binary search tree, in practice a red-black tree. Keys stay sorted, lookups, inserts and erases are logarithmic, and I can iterate in order or ask for ranges with lower_bound and upper_bound. It needs a less-than comparison on the key. std::unordered_map is a hash table. Lookups are constant time on average, but with a bad hash or many collisions they degrade towards linear, and iteration order is unspecified and can change after a rehash. It needs a hash function and equality. So I pick map when order matters, like a price ladder sorted by price or 'give me everything between these two times', and unordered_map for pure lookups by key, like a cache by ID. For small collections or hot paths I measure, because a sorted vector is sometimes faster than both thanks to contiguous memory."

"At my last company a service that parsed market data crashed maybe once a day, always in a different place, which usually means memory corruption. I couldn't reproduce it locally, so I built it with AddressSanitizer and replayed a recorded day of traffic. Within an hour it reported a heap use-after-free. A handler kept a raw pointer to an element inside a vector, and a later message added elements, the vector reallocated, and the handler wrote through the stale pointer. The fix was to store an index instead of a pointer. Afterwards I added a sanitizer build to our CI, ran the replay test nightly, and wrote a short guideline for the team about not holding pointers into containers that can grow. We didn't see that crash again, and the sanitizer job caught two similar bugs in review within the next few months."

"In my last role we had a large codebase full of raw new and delete, and most of our crash reports were leaks or double frees. Rather than a big rewrite, I proposed doing it one module at a time. First we raised the compiler to a newer standard with warnings turned up and fixed what that showed. Then for each module I added tests around the public behaviour, replaced owning raw pointers with unique_ptr, and left non-owning ones as raw pointers or references, so the types finally said who owned what. We ran every change through AddressSanitizer in CI. Some places had genuinely shared lifetimes and got shared_ptr, but only after we'd argued about it in review. Over a few months the leak reports mostly stopped. I deliberately left one old, stable module alone, because nothing was failing there and the risk wasn't worth it."

"In a project that processed large sensor logs, one stage was taking minutes. First I wrote a benchmark on a fixed input so I had a number to compare. Then I ran it under perf, and the surprise was that most of the time wasn't in the maths at all. It was in memory allocation and string copies. A function took a std::string by value in a hot loop, and we built a small temporary vector for every record. I changed the parameter to a string_view, reused one vector across iterations with clear and a reserved capacity, and added a missing reserve on the output vector. The stage went from minutes to under twenty seconds. I added the benchmark to our CI with a threshold, so a later change that brought the allocations back would be caught before release."