C++ Inheritance — Missing Virtual Destructor Leak

Every large C++ codebase you'll ever work in — game engines, OS drivers, financial systems — uses inheritance somewhere. It's not a fancy academic trick. It's the practical answer to a real problem: when multiple things in your program share common behaviour, you shouldn't copy-paste that behaviour into each one. Code duplication is the silent killer of maintainability, and inheritance is one of the sharpest tools for defeating it.

Without inheritance, you'd write a 'save to disk' function separately for every class that needs it — User, Order, Product, Session. Change one detail of how saving works, and you're hunting through five files making the same edit. Inheritance lets you write that logic once in a base class and have every derived class pick it up automatically. It also enables polymorphism — the ability to treat different objects through a common interface — which is what makes plugin architectures, game entity systems, and GUI frameworks possible.

By the end of this article you'll be able to model real inheritance hierarchies yourself, understand the critical difference between public and private inheritance, dodge the two bugs that catch almost every intermediate C++ developer off guard, and answer the inheritance questions that come up in system-design interviews. Let's build something real.

Why Inheritance Without a Virtual Destructor Leaks

Inheritance in C++ lets a derived class reuse and extend the interface and implementation of a base class. The core mechanic is that a derived object contains a base class subobject, and access control, virtual functions, and destructor dispatch are all governed by the base class design. The critical detail: if you delete a derived object through a base pointer, the destructor must be virtual to invoke the derived destructor; otherwise, only the base destructor runs, leaking derived resources.

When you declare a base class with a non-virtual destructor and derive from it, the compiler generates a static call to the base destructor for any delete on a base pointer. This is correct only if the dynamic type matches the static type. In practice, polymorphic hierarchies (e.g., Shape* s = new Circle(...)) rely on virtual dispatch to call ~Circle(). Without virtual ~Shape(), the Circle destructor never executes, leaking heap memory, file handles, or other resources held by the derived part.

Use virtual destructors in any base class that is intended for polymorphic deletion — that is, any class with at least one virtual function. If a class is not meant to be deleted polymorphically (e.g., a mixin or a sealed hierarchy), mark it final or document the constraint. In real systems, this rule prevents silent resource leaks that are invisible in valgrind until the derived class adds a std::vector or a raw pointer.

Single Inheritance — Building Your First Base Class

Single inheritance is the simplest form: one class derives from exactly one parent. The derived class gets all public and protected members of the base class as if they were its own. Private members still exist in memory but are off-limits directly — they're the base class's internal secrets.

Why does the distinction between public, protected, and private members matter here? Because it defines the contract. Public members are the class's API — things it promises the outside world. Protected members are shared within the family but hidden from strangers. Private members belong to this class alone, full stop.

Here's a concrete scenario: you're building a simple vehicle management system. Every vehicle has a make, model, and a way to display its details. A Car adds the number of doors. Instead of writing the make/model logic twice, you put it in a base Vehicle class and let Car inherit it.

#include <iostream>
#include <string>

// Base class — contains everything common to ALL vehicles
class Vehicle {
public:
    std::string make;
    std::string model;
    int year;

    // Constructor: initialises the core vehicle data
    Vehicle(const std::string& make, const std::string& model, int year)
        : make(make), model(model), year(year) {}

    // Any vehicle can display its basic identity
    void displayInfo() const {
        std::cout << year << " " << make << " " << model;
    }
};

// Derived class — inherits Vehicle publicly, then extends it
class Car : public Vehicle {
public:
    int numberOfDoors;

    // We call Vehicle's constructor via the initialiser list
    // — the base part is constructed FIRST, always
    Car(const std::string& make, const std::string& model,
        int year, int doors)
        : Vehicle(make, model, year), numberOfDoors(doors) {}

    // Car-specific display — reuses the base method then adds its own info
    void displayCarInfo() const {
        displayInfo();  // inherited from Vehicle — no duplication needed
        std::cout << " | Doors: " << numberOfDoors << "\n";
    }
};

int main() {
    Vehicle genericVehicle("Generic", "Transport", 2020);
    genericVehicle.displayInfo();
    std::cout << "\n";

    Car familyCar("Toyota", "Camry", 2023, 4);
    familyCar.displayCarInfo();

    // Car inherits make/model/year directly — no extra code needed
    std::cout << "Make accessed directly: " << familyCar.make << "\n";

    return 0;
}

All Five Types of Inheritance in C++

C++ supports five forms of inheritance: single, multiple, multilevel, hierarchical, and hybrid. Understanding which one fits your problem is critical to keeping your codebase maintainable.

The diagram below shows how these types relate:

Public vs Protected vs Private Inheritance — The Bit Everyone Gets Wrong

When you write `class Car : public Vehicle, that public` keyword isn't about Vehicle's members — it's about how those members are re-exposed through Car to the outside world. This is the single most misunderstood concept in C++ inheritance, and getting it wrong leads to bizarre access errors.

Here's the mental model: the inheritance access specifier acts like a filter that can only make things more restrictive, never less. With public inheritance, public stays public and protected stays protected. With protected inheritance, public members become protected in the derived class. With private inheritance, everything from the base becomes private — completely locked away.

public inheritance models an IS-A relationship: a Car IS-A Vehicle. This is the form you'll use 90% of the time. private inheritance models HAS-A or IMPLEMENTED-IN-TERMS-OF — it's an implementation detail, not a conceptual relationship. If you catch yourself writing private inheritance, ask whether composition (just storing a member) would be cleaner.

#include <iostream>
#include <string>

class Engine {
public:
    void start() { std::cout << "Engine started\n"; }
    void stop()  { std::cout << "Engine stopped\n"; }
protected:
    int horsepower = 150;
private:
    std::string serialNumber = "ENG-XZ99"; // nobody outside Engine touches this
};

// PUBLIC inheritance — Car IS-A Engine (conceptually makes sense to expose API)
class PublicCar : public Engine {
public:
    void drive() {
        start();             // OK — public inherited, stays public
        std::cout << "Driving with " << horsepower << " HP\n"; // OK — protected
        // serialNumber;     // COMPILE ERROR — private is always off-limits
    }
};

// PRIVATE inheritance — ElectricBooster uses Engine internally
// The world outside ElectricBooster cannot call start() or stop()
class ElectricBooster : private Engine {
public:
    void activate() {
        start();  // OK inside the class — but outsiders can't call booster.start()
        std::cout << "Booster running at " << horsepower << " HP\n";
    }
};

int main() {
    PublicCar sportsCar;
    sportsCar.start();   // Fine — public inheritance keeps it public
    sportsCar.drive();
    sportsCar.stop();

    std::cout << "---\n";

    ElectricBooster booster;
    booster.activate();  // Fine — activate() is public
    // booster.start();  // COMPILE ERROR — start() is now private via private inheritance

    return 0;
}

Virtual Functions and Polymorphism — Where Inheritance Gets Its Superpower

Inheriting data and functions is useful, but inheritance really earns its keep when you combine it with virtual functions. A virtual function says: 'I'm providing a default, but derived classes can replace me — and the RIGHT version will be called at runtime based on what the object actually is, not what pointer type you're using.'

This is runtime polymorphism — one of the core pillars of object-oriented design. Without it, you'd need a giant switch statement to check object types and call the right method. With it, you write code against the base class pointer and the system figures out which derived implementation to invoke automatically.

The virtual keyword on the base method opts into this mechanism. The override keyword on derived methods (C++11 onwards) makes the compiler confirm you're actually overriding something — it catches typos in function signatures that would otherwise silently create a new, unrelated function. Always use override. The = 0 syntax makes a function pure virtual, turning the class into an abstract base — it can't be instantiated and forces every derived class to provide an implementation.

#include <iostream>
#include <vector>
#include <memory>
#include <string>

// Abstract base class — cannot be instantiated directly
// Any class that forgets to implement fuelCost() won't compile
class Vehicle {
public:
    std::string make;
    int milesDriven;

    Vehicle(const std::string& make, int miles)
        : make(make), milesDriven(miles) {}

    // Pure virtual — every vehicle MUST define how fuel cost is calculated
    virtual double fuelCost() const = 0;

    // Virtual with a default — derived classes CAN override but don't have to
    virtual std::string fuelType() const {
        return "Unknown";
    }

    // Non-virtual: this behaviour should NEVER change per subtype
    void printSummary() const {
        std::cout << make
                  << " | Fuel: " << fuelType()
                  << " | Cost for " << milesDriven
                  << " miles: $" << fuelCost() << "\n";
    }

    // ALWAYS declare the destructor virtual in a polymorphic base class
    // (see Gotchas section — this one bites hard)
    virtual ~Vehicle() = default;
};

class PetrolCar : public Vehicle {
    double milesPerGallon;
    double pricePerGallon;
public:
    PetrolCar(const std::string& make, int miles,
              double mpg, double pricePerGallon)
        : Vehicle(make, miles),
          milesPerGallon(mpg),
          pricePerGallon(pricePerGallon) {}

    // override keyword tells the compiler: "check that I'm actually overriding"
    double fuelCost() const override {
        return (milesDriven / milesPerGallon) * pricePerGallon;
    }

    std::string fuelType() const override { return "Petrol"; }
};

class ElectricCar : public Vehicle {
    double milesPerKWh;
    double pricePerKWh;
public:
    ElectricCar(const std::string& make, int miles,
                double milesPerKWh, double pricePerKWh)
        : Vehicle(make, miles),
          milesPerKWh(milesPerKWh),
          pricePerKWh(pricePerKWh) {}

    double fuelCost() const override {
        return (milesDriven / milesPerKWh) * pricePerKWh;
    }

    std::string fuelType() const override { return "Electric"; }
};

int main() {
    // Store different vehicle types through a common base pointer
    // This is the power: the vector doesn't care which subtype it holds
    std::vector<std::unique_ptr<Vehicle>> fleet;

    fleet.push_back(std::make_unique<PetrolCar>("Ford F-150", 300, 20.0, 3.50));
    fleet.push_back(std::make_unique<ElectricCar>("Tesla Model 3", 300, 4.0, 0.13));
    fleet.push_back(std::make_unique<PetrolCar>("Honda Civic", 300, 35.0, 3.50));

    std::cout << "=== Fleet Cost Report ===\n";
    for (const auto& vehicle : fleet) {
        vehicle->printSummary(); // correct fuelCost() called automatically
    }

    return 0;
}

VTable and VPointer: Memory Layout of Virtual Functions

When a class has at least one virtual function, the compiler generates a static array called the virtual table (vtable). Each virtual function has a function pointer slot in this table. Every object of that class also gets a hidden vpointer (vptr) that points to its class's vtable.

Here's the memory layout: on the left is the object memory (stack/heap), which contains data members plus the vptr. The vptr points to the vtable, which stores pointers to the actual function implementations. When you call a virtual function through a base pointer, the generated assembly reads the vptr from the object, indexes into the vtable, and jumps to the correct derived implementation.

The diagram below shows the layout for a Derived object when Base has a virtual function foo() that Derived overrides:

Rules for Virtual Functions in C++

Follow these rules to avoid common pitfalls when using virtual functions:

Multiple Inheritance and the Diamond Problem — When Families Get Complicated

C++ allows a class to inherit from more than one base class. This is powerful but introduces a notorious hazard: the Diamond Problem. It occurs when two base classes both inherit from the same grandparent. Without a fix, the grandparent's data gets duplicated into the final class — two copies of the same members, ambiguous access, and logic bugs.

The fix is virtual inheritance on the intermediate classes. Virtual inheritance tells the compiler: 'even if multiple paths lead to this base, instantiate it exactly once.' The virtual base is then constructed by the most-derived class directly, which is why the most-derived constructor must call the virtual base constructor explicitly.

A practical rule: reach for multiple inheritance only when the extra base classes are pure interfaces (abstract classes with only pure virtual functions and no data). Mixing data-carrying base classes via multiple inheritance quickly turns into a maintenance nightmare — favour composition instead.

#include <iostream>
#include <string>

// Grandparent — the single shared root
class Device {
public:
    std::string deviceId;
    Device(const std::string& id) : deviceId(id) {
        std::cout << "Device constructed: " << id << "\n";
    }
    virtual ~Device() = default;
};

// virtual inheritance ensures only ONE Device sub-object exists
class NetworkDevice : virtual public Device {
public:
    NetworkDevice(const std::string& id) : Device(id) {}
    void sendPacket() { std::cout << deviceId << " sending packet\n"; }
};

class StorageDevice : virtual public Device {
public:
    StorageDevice(const std::string& id) : Device(id) {}
    void writeData() { std::cout << deviceId << " writing data\n"; }
};

// SmartRouter inherits from BOTH — classic diamond shape
// Because both parents used virtual inheritance, Device is constructed ONCE
// The most-derived class (SmartRouter) MUST call Device's constructor directly
class SmartRouter : public NetworkDevice, public StorageDevice {
public:
    SmartRouter(const std::string& id)
        : Device(id),            // required: most-derived calls virtual base
          NetworkDevice(id),
          StorageDevice(id) {}

    void status() {
        // No ambiguity — there's only one deviceId
        std::cout << "Router " << deviceId << " is operational\n";
    }
};

int main() {
    std::cout << "--- Without virtual inheritance, Device would construct TWICE ---\n";
    std::cout << "--- With virtual inheritance, it constructs exactly once:      ---\n\n";

    SmartRouter router("RTR-001");
    router.sendPacket();
    router.writeData();
    router.status();

    return 0;
}

Inheritance vs Composition — The Real Trade-off

One of the most common design debates is whether to model a relationship with inheritance or composition. The rule of thumb: inheritance is for polymorphic substitution (you need to treat objects through a common interface), composition is for code reuse (you just need the functionality). In production, composition almost always wins for reuse because it's less coupled, easier to test, and doesn't force you into a class hierarchy. However, inheritance is indispensable when you need to build plugin systems, framework callbacks, or any code that must operate on unknown types.

Here's a concrete example: instead of inheriting from a Logger to reuse logging behaviour, store a Logger member and delegate to it. This lets you swap loggers at runtime (file, network, mock) without changing the class hierarchy.

#include <iostream>
#include <memory>
#include <string>

// ---- Inheritance approach ----
class Logger {
public:
    virtual void log(const std::string& msg) const {
        std::cout << "[Inheritance] " << msg << "\n";
    }
    virtual ~Logger() = default;
};

class ServiceWithInheritance : public Logger {
public:
    void doWork() {
        // 'log' is inherited, but the relationship is now IS-A Logger
        log("Working...");
    }
};

// ---- Composition approach ----
class ServiceWithComposition {
    std::shared_ptr<Logger> logger_; // can be any Logger implementation
public:
    explicit ServiceWithComposition(std::shared_ptr<Logger> logger)
        : logger_(std::move(logger)) {}
    void doWork() {
        // delegation: uses logger, not inherits
        logger_->log("Working...");
    }
};

class FileLogger : public Logger {
public:
    void log(const std::string& msg) const override {
        std::cout << "[File] " << msg << "\n";  // pretend file I/O
    }
};

int main() {
    // Inheritance: fixes the Logger type at compile time
    ServiceWithInheritance svc_inherit;
    svc_inherit.doWork();

    // Composition: can swap logger at runtime
    auto fileLogger = std::make_shared<FileLogger>();
    ServiceWithComposition svc_compose(fileLogger);
    svc_compose.doWork();

    // Composition also works with the default Logger
    auto defaultLogger = std::make_shared<Logger>();
    ServiceWithComposition svc_compose2(defaultLogger);
    svc_compose2.doWork();

    return 0;
}

Advantages and Disadvantages of Inheritance in C++

Inheritance is a powerful tool, but like any tool it has trade-offs. Use this table to decide when to lean in and when to pull back.

In production, use inheritance sparingly. When you do use it, keep the hierarchy shallow, mark overrides with override, and always consider whether composition would serve better.

Practice Problems: C++ Inheritance

Apply what you've learned with these hands-on problems. Focus on understanding the concepts rather than memorising syntax.

Problem 1: Virtual Destructor Detection Given the following code, will there be a memory leak? If so, why? ``cpp class Base { public: ~Base() {} }; class Derived : public Base { int data = new int[100]; }; int main() { Base p = new Derived(); delete p; } ` Answer: Yes – leak. Base destructor is non-virtual, so ~Derived() never runs. Fix: add virtual ~Base() = default;`.

Problem 2: Multiple Inheritance Ambiguity ``cpp struct A { void foo() {} }; struct B : A {}; struct C : A {}; struct D : B, C {}; int main() { D d; d.foo(); } ` Does this compile? If not, what's the fix? Answer: No – ambiguous call to A::foo(). Fix: use virtual inheritance (class B : virtual public A, class C : virtual public A`).

Problem 3: Override vs Overload ``cpp class Base { public: virtual void print(int x) { std::cout << "Base"; } }; class Derived : public Base { public: void print(double x) { std::cout << "Derived"; } }; ` When calling Derived d; d.print(5), which version runs? Answer: Derived version because int converts to double. The function print(double) is a new function (overload), not an override. Add override` to catch this mistake. If you want to override, match signature exactly.

Problem 4: Diamond Problem without Virtual Inheritance Given the diamond shape with a data member int value in the root, how many copies of value exist in the most-derived class? Answer: Two copies – one from each path. Fix: use virtual inheritance on intermediate classes.

Problem 5: Virtual Table Construction How many vtable entries does a class with three virtual functions and no overrides have? Answer: Three entries (one per virtual function). Each derived class that overrides any of them gets its own vtable with updated pointers.

Slicing: The Silent Data Loss That Kills Polymorphism

You pass an object by value to a function expecting a base class. Compiles fine. But the derived part? Gone. Sliced off. This is C++'s version of a silent type cast that discards everything you just inherited.

The root cause is how C++ handles value semantics. When you copy a Derived object into a Base parameter, the compiler only copies the Base portion. The compiler doesn't know — and doesn't care — about the Derived's virtual table pointer or extra members. It just memcpy's the base part. Polymorphism? Dead. Destructor? Base's version runs. You just lost any extended state and behavior.

Senior teams enforce a rule: never pass polymorphic objects by value. Always use pointers or references. If someone checks in code with void process(SensorData data), you flag it. Because that function will happily slice every derived sensor type you throw at it, and nobody will notice until the temperature readings stop making sense.

// io.thecodeforge — c-cpp tutorial

#include <iostream>
class SensorData {
public:
    virtual void report() { std::cout << "Base sensor\n"; }
    virtual ~SensorData() = default;
};

class TempSensor : public SensorData {
    double temperature = 45.6;
public:
    void report() override { std::cout << "Temp: " << temperature << "\n"; }
};

void logSensor(SensorData data) {  // BAD: slices off temperature
    data.report();                  // calls Base::report, not TempSensor::report
}

int main() {
    TempSensor ts;
    logSensor(ts);
    SensorData* ptr = &ts;
    ptr->report();                  // calls TempSensor::report via vtable
}

Virtual Inheritance: Why Your Diamond Won't Kill You If You Do It Right

Everyone fears the diamond problem. Two base classes, both deriving from the same grandparent, a single derived class inheriting both. Without virtual inheritance, you get two copies of the grandparent. Ambiguity, state duplication, and headaches at the water cooler.

The fix: virtual keyword on the inheritance specifier. But here's what the tutorials won't tell you — virtual inheritance changes the memory layout and construction order drastically. The most derived class becomes responsible for constructing the virtual base. Not the intermediate classes. So if a base class in the middle tries to initialize the virtual base, it gets silently ignored. This has cost teams days of debugging.

Second pain: casting. You can't static_cast from a virtual base to a derived class. The compiler doesn't know where the derived class sits relative to the virtual base at compile time. You need dynamic_cast or a C-style cast (don't). If you have virtual inheritance, expect RTTI overhead and slightly slower cast operations.

Third: construction order. Virtual bases are always constructed first, in depth-first left-to-right order of the inheritance graph. If your virtual base constructor throws, the entire object hierarchy collapses. Protect that constructor like it's hosting the king.

// io.thecodeforge — c-cpp tutorial

#include <iostream>
struct Logger {
    Logger() { std::cout << "Logger ctor\n"; }
};
struct Networked : virtual public Logger {
    Networked() { std::cout << "Networked ctor\n"; }
};
struct FileBased : virtual public Logger {
    FileBased() { std::cout << "FileBased ctor\n"; }
};
struct HybridLogger : public Networked, public FileBased {
    HybridLogger() { std::cout << "HybridLogger ctor\n"; }
};

int main() {
    HybridLogger hl;
}