C++ Interview Questions and Answers

RAII, Resource Acquisition Is Initialisation, binds a resource's lifetime to an object's lifetime: acquire in the constructor and release in the destructor. Because destructors run on scope exit, including during stack unwinding from an exception, resources cannot leak.

void write(const std::string& path) {
    std::ofstream out(path);          // opened in ctor
    std::lock_guard<std::mutex> lock(m);
    out << "data\n";
}   // lock released, file closed, even if << throws

The standard library is built on RAII: std::string, std::vector, std::fstream, std::lock_guard and std::unique_ptr. Writing a small RAII wrapper for a C API handle, socket or mutex is idiomatic and gives exception safety.

The alternative, manual cleanup with goto or duplicated error paths, is error-prone and leaks on early returns. The "rule of zero" extends RAII: compose members that manage their own resources so your class needs no custom destructor or copy/move operations at all.

Raw new and delete are error-prone, so C++11 introduced smart pointers in <memory> that express ownership.

• std::unique_ptr<T>: exclusive ownership, cannot be copied, is movable, and has essentially zero overhead versus a raw pointer. Create with std::make_unique.
• std::shared_ptr<T>: shared ownership through an atomic control block with a reference count; the object is destroyed when the last owner goes away. Create with std::make_shared. Heavier, and the count is thread-safe but the object is not.
• std::weak_ptr<T>: a non-owning observer of a shared object, used to break cycles. lock() yields a shared_ptr or null.

auto a = std::make_unique<Widget>();
auto b = std::make_shared<Widget>();
std::weak_ptr<Widget> w = b;

if (auto s = w.lock()) {
    s->use();
}

Prefer unique_ptr by default, upgrade to shared_ptr only for genuine shared ownership, and never create two shared pointers from the same raw pointer, which causes a double free.

A virtual function enables runtime polymorphism. Each polymorphic class gets a vtable of function pointers and each object stores a hidden vptr. A call through a base pointer looks up the most-derived override at runtime.

struct Base {
    virtual ~Base() = default;
    virtual void speak() const { std::cout << "base"; }
};

struct Derived : Base {
    void speak() const override { std::cout << "derived"; }
};

Base* p = new Derived();
p->speak();   // "derived"
delete p;     // needs a virtual destructor

If the base destructor is not virtual, deleting through a base pointer is undefined behaviour and derived members are not destroyed, leaking resources. Any base intended for polymorphic deletion needs a virtual destructor.

Mark overrides with override so signature mismatches become compile errors, and use final to prevent further overriding and enable devirtualisation. Virtual calls cannot be inlined and add an indirection, so do not make everything virtual; keep interfaces small and stable.

Copying large objects is expensive. Move semantics transfer ownership of a resource from a temporary (an rvalue) instead of copying, leaving the source in a valid but unspecified state. It relies on rvalue references (T&&) plus a move constructor and move assignment operator.

std::vector<std::string> make();

std::vector<std::string> v = make();  // move, not copy

std::string s = "long text";
std::vector<std::string> w;
w.push_back(std::move(s));            // s is left empty-ish

std::move is just a cast to an rvalue reference; it does not move anything by itself. Moves of standard containers are O(1) pointer swaps, not element-by-element copies.

The "rule of five" says that if you define a destructor, copy or move operation, define or delete all of them. Mark move operations noexcept so containers such as vector prefer them during reallocation. Never use a moved-from object except to assign or destroy it.

const is a compile-time contract. A const object cannot be modified, and a const member function promises not to modify the object, so it can be called on const objects and through const references.

class Account {
public:
    double balance() const { return balance_; }
    void deposit(double x) { balance_ += x; }
private:
    double balance_ = 0;
};

void print(const Account& a) {
    std::cout << a.balance();
}

Use const T& parameters to avoid copies without allowing mutation. const can qualify the pointed-to data or the pointer itself: const char* const.

Use mutable for members that must change in a const method, such as caches or mutexes. Casting away const with const_cast is undefined behaviour if the object was originally const.

Const correctness is easiest to adopt early because it propagates through an API. It documents intent, enables compiler optimisation, and prevents accidental modification of shared data.