Constructor/Destructor in Inheritance

Programming Language & Its Applications — Features of Object-Oriented Programming, NEC licence examination syllabus (Nepal Engineering Council).

Constructors and Destructors in Inheritance

Base first, derived second, destroyed in exact reverse — and one missing virtual that leaks memory.

🌍 Where this lives: the missing-virtual-destructor bug in this topic is not theoretical. It is one of the most common real memory leaks in C++ codebases, it produces no warning by default, and the program appears to work perfectly while quietly leaking on every object. Every Qt class inherits a virtual destructor from QObject; every polymorphic base in the standard library has one; std::unique_ptr<Base> holding a Derived depends on it entirely. Search "why base class destructor should be virtual" — and then compile the example below with -fsanitize=address to watch the tool print the exact bytes leaked.

The construction order

Creating a Derived object runs, IN THIS ORDER: 1. VIRTUAL base classes (if any), most-derived first 2. DIRECT base classes, in the order listed in the base-clause — NOT the order in your initialiser list 3. MEMBERS of Derived, in DECLARATION order 4. Derived's constructor BODY Destruction is EXACTLY the reverse: 1. Derived's destructor BODY 2. MEMBERS, in reverse declaration order 3. DIRECT base destructors, reverse order 4. VIRTUAL base destructors WHY THIS ORDER IS NECESSARY: Derived's body may use inherited members, so the base must be fully constructed first. On the way out, Derived's body may still need the base, so the base is destroyed last. Neither half would work the other way round. CALLING A BASE CONSTRUCTOR: class Derived : public Base { int extra; public: Derived(int a, int b) : Base(a), extra(b) { } ^^^^^^^ must be in the initialiser list — you cannot call Base(a) in the body }; If you do NOT name the base, its DEFAULT constructor is called. If it has none, that is a compile error: error: no matching function for call to 'Base::Base()'

order.cpp

#include <iostream>
#include <string>

class Member {
    std::string tag;
public:
    Member(std::string t) : tag(std::move(t)) {
        std::cout << "      +member " << tag << "\n";
    }
    ~Member() { std::cout << "      -member " << tag << "\n"; }
};

class Base {
    Member bm{"base-member"};
public:
    Base()  { std::cout << "    +Base body\n"; }
    ~Base() { std::cout << "    -Base body\n"; }
};

class Middle : public Base {
    Member mm{"middle-member"};
public:
    Middle()  { std::cout << "  +Middle body\n"; }
    ~Middle() { std::cout << "  -Middle body\n"; }
};

class Derived : public Middle {
    Member d1{"derived-1"};
    Member d2{"derived-2"};
public:
    Derived()  { std::cout << "+Derived body\n"; }
    ~Derived() { std::cout << "-Derived body\n"; }
};

int main() {
    std::cout << "constructing:\n";
    { Derived d;
      std::cout << "--- object alive ---\ndestroying:\n"; }
    return 0;
}
Output:
constructing:
      +member base-member
    +Base body
      +member middle-member
  +Middle body
      +member derived-1
      +member derived-2
+Derived body
--- object alive ---
destroying:
-Derived body
      -member derived-2
      -member derived-1
  -Middle body
      -member middle-member
    -Base body
      -member base-member

Read the two halves side by side — they are exact mirrors: CONSTRUCTION DESTRUCTION base-member Derived body Base body derived-2 middle-member derived-1 Middle body Middle body derived-1 middle-member derived-2 Base body Derived body base-member Line 1 of construction is line 7 of destruction, line 2 is line 6, and so on. Perfect symmetry, guaranteed by the standard. Two details worth extracting: · within each class, MEMBERS are built before that class's BODY runs — so the body can safely use them · derived-2 is destroyed before derived-1 (reverse declaration order), which matters if d2 depends on d1

The virtual destructor — the critical rule

virtual_dtor.cpp

#include <iostream>

/* BROKEN: non-virtual destructor in a polymorphic base */
class BadBase {
public:
    BadBase()  { std::cout << "  +BadBase\n"; }
    ~BadBase() { std::cout << "  -BadBase\n"; }
};
class BadDerived : public BadBase {
    int *buffer;
public:
    BadDerived() : buffer(new int[1000]) {
        std::cout << "  +BadDerived (4000 bytes)\n";
    }
    ~BadDerived() {
        delete[] buffer;
        std::cout << "  -BadDerived (freed)\n";
    }
};

/* CORRECT: virtual destructor */
class GoodBase {
public:
    GoodBase()  { std::cout << "  +GoodBase\n"; }
    virtual ~GoodBase() { std::cout << "  -GoodBase\n"; }
};
class GoodDerived : public GoodBase {
    int *buffer;
public:
    GoodDerived() : buffer(new int[1000]) {
        std::cout << "  +GoodDerived (4000 bytes)\n";
    }
    ~GoodDerived() override {
        delete[] buffer;
        std::cout << "  -GoodDerived (freed)\n";
    }
};

int main() {
    std::cout << "non-virtual base:\n";
    BadBase *p = new BadDerived();
    delete p;          /* only ~BadBase runs: LEAK */

    std::cout << "\nvirtual base:\n";
    GoodBase *q = new GoodDerived();
    delete q;          /* both destructors run */

    std::cout << "\nno pointer involved (both fine):\n";
    { BadDerived direct; }
    return 0;
}
Output:
non-virtual base:
  +BadBase
  +BadDerived (4000 bytes)
  -BadBase
                       <-- ~BadDerived NEVER RAN: 4000 bytes leaked

virtual base:
  +GoodBase
  +GoodDerived (4000 bytes)
  -GoodDerived (freed)
  -GoodBase

no pointer involved (both fine):
  +BadBase
  +BadDerived (4000 bytes)
  -BadDerived (freed)
  -BadBase

THE MECHANISM: delete p; where p is BadBase* pointing at a BadDerived Without virtual, the destructor call is resolved STATICALLY from the pointer's type: the compiler emits a call to ~BadBase and nothing else. ~BadDerived is never invoked, so `delete[] buffer` never runs. With virtual, the call goes through the vtable and finds the ACTUAL object's destructor, ~GoodDerived, which then chains automatically to ~GoodBase. Note the last case: `BadDerived direct;` on the stack works fine, because there is no pointer — the compiler knows the exact type. That is exactly why this bug hides so well: it only appears when you delete through a base pointer, which is precisely what polymorphic code does. THE RULE, stated as a decision: Does anyone delete objects of this class through a base pointer, or store them in unique_ptr<Base>? YES → the base destructor MUST be virtual NO, and the class is not meant for inheritance → mark the class `final` to make that explicit Formally: the standard says deleting a derived object through a base pointer with a non-virtual destructor is UNDEFINED BEHAVIOUR — not merely a leak. In practice it leaks; in principle anything may happen. Enable the warning: g++ -Wall -Wextra -Wdelete-non-virtual-dtor

Notice that the leak is 4000 bytes per object with no crash, no warning, and correct-looking output. Ten thousand objects in a long-running server is 40 MB gone. This is the profile of the worst kind of bug: invisible in testing, fatal in production.

Worked example — a hierarchy done correctly

employees.cpp

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

class Employee {
protected:
    std::string name;
    double      basic;
public:
    Employee(std::string n, double b)
        : name(std::move(n)), basic(b) {}

    /* virtual destructor: this class IS a polymorphic base */
    virtual ~Employee() = default;

    virtual double salary() const { return basic; }
    virtual std::string role() const { return "Employee"; }

    void payslip() const {
        std::cout << "  " << role() << " " << name
                  << ": Rs " << salary() << "\n";
    }
};

class Manager : public Employee {
    double allowance;
public:
    Manager(std::string n, double b, double a)
        : Employee(std::move(n), b), allowance(a) {}
    double salary() const override { return basic + allowance; }
    std::string role() const override { return "Manager  "; }
};

class Engineer : public Employee {
    int overtimeHours;
    static constexpr double RATE = 250.0;
public:
    Engineer(std::string n, double b, int h)
        : Employee(std::move(n), b), overtimeHours(h) {}
    double salary() const override {
        return basic + overtimeHours * RATE;
    }
    std::string role() const override { return "Engineer "; }
};

/* MULTILEVEL: a lead engineer is an engineer */
class LeadEngineer : public Engineer {
    double leadBonus;
public:
    LeadEngineer(std::string n, double b, int h, double bonus)
        : Engineer(std::move(n), b, h), leadBonus(bonus) {}
    double salary() const override {
        return Engineer::salary() + leadBonus;   /* reuse */
    }
    std::string role() const override { return "Lead Eng "; }
};

int main() {
    std::vector<std::unique_ptr<Employee>> staff;
    staff.push_back(std::make_unique<Employee>("Ram", 40000));
    staff.push_back(std::make_unique<Manager>("Sita", 60000, 15000));
    staff.push_back(std::make_unique<Engineer>("Hari", 55000, 12));
    staff.push_back(std::make_unique<LeadEngineer>(
                        "Gita", 70000, 8, 20000));

    double payroll = 0;
    for (const auto &e : staff) { e->payslip(); payroll += e->salary(); }
    std::cout << "  ---------------------------------\n";
    std::cout << "  monthly payroll: Rs " << payroll << "\n";
    std::cout << "  annual payroll : Rs " << payroll * 12 << "\n";
    /* unique_ptr deletes through Employee* — safe only
       because ~Employee is virtual */
    return 0;
}
Output:
  Employee Ram: Rs 40000
  Manager   Sita: Rs 75000
  Engineer  Hari: Rs 58000
  Lead Eng  Gita: Rs 92000
  ---------------------------------
  monthly payroll: Rs 265000
  annual payroll : Rs 3.18e+06

Verifying each salary: Ram plain : 40000 = 40000 Sita manager : 60000 + 15000 = 75000 Hari engineer : 55000 + 12 × 250 = 55000+3000 = 58000 Gita lead : 70000 + 8 × 250 + 20000 = 70000 + 2000 + 20000 = 92000 payroll = 40000 + 75000 + 58000 + 92000 = 265000 ✔ annual = 265000 × 12 = 3,180,000 ✔ Two techniques worth noting: 1. LeadEngineer::salary() calls Engineer::salary() with an explicit qualification, then ADDS to it. That is how you EXTEND behaviour rather than replacing it — and it means changing the overtime rate updates leads automatically. 2. std::unique_ptr<Employee> holds derived objects. When the vector is destroyed, each unique_ptr calls `delete` on an Employee* — which dispatches correctly ONLY because ~Employee is virtual. Remove that one keyword and this program leaks every Manager's and Engineer's members.

Inheriting and delegating constructors

C++11 gave two ways to avoid repetitive constructors. 1. INHERITING CONSTRUCTORS — reuse the base's set: class Base { public: Base(int); Base(int, int); Base(const std::string&); }; class Derived : public Base { public: using Base::Base; /* all three now available */ /* Derived's own members still need initialisers or default member initialisers */ }; 2. DELEGATING CONSTRUCTORS — one calls another: class Point { int x, y; public: Point(int a, int b) : x(a), y(b) { validate(); } Point(int a) : Point(a, a) { } /* delegates */ Point() : Point(0, 0) { } /* delegates */ }; Validation lives in ONE place. Before C++11 you needed a private init() helper. WHAT IS NOT INHERITED, ever: · constructors (unless you write `using Base::Base`) · the destructor · the assignment operator (operator=) · friend declarations Each derived class gets its own, generated or written.

delegating.cpp

#include <iostream>
#include <stdexcept>

class Rect {
    double w, h;
    void validate() const {
        if (w <= 0 || h <= 0)
            throw std::invalid_argument("non-positive side");
    }
public:
    Rect(double a, double b) : w(a), h(b) { validate(); }
    Rect(double s) : Rect(s, s) { }      /* delegates */
    Rect()          : Rect(1, 1) { }     /* delegates */
    double area() const { return w * h; }
};

class Base {
public:
    Base(int a)          { std::cout << "  Base(int " << a << ")\n"; }
    Base(int a, int b)   { std::cout << "  Base(" << a << ","
                                     << b << ")\n"; }
};
class Derived : public Base {
    int extra = 99;              /* default member init */
public:
    using Base::Base;            /* inherit both ctors */
    int getExtra() const { return extra; }
};

int main() {
    Rect a(4, 5), b(3), c;
    std::cout << "  areas: " << a.area() << " "
              << b.area() << " " << c.area() << "\n";

    try { Rect bad(-2); }
    catch (const std::invalid_argument &e) {
        std::cout << "  caught: " << e.what()
                  << "  (validated once, in one place)\n";
    }

    Derived d1(7);
    Derived d2(3, 4);
    std::cout << "  inherited ctors work; extra = "
              << d1.getExtra() << "\n";
    return 0;
}
Output:
  areas: 20 9 1
  caught: non-positive side  (validated once, in one place)
  Base(int 7)
  Base(3,4)
  inherited ctors work; extra = 99

Note that Rect bad(-2) threw even though the validation lives only in the two-argument constructor — the delegation routes through it. And extra was still initialised to 99 by its default member initialiser, because inherited constructors do not know about the derived class's own members.

🌍 Go further: there is a subtle rule that catches everyone eventually: never call a virtual function from a constructor or destructor. During Base's constructor the object is not yet a Derived — the vtable still points at Base — so a virtual call resolves to Base's version, not the override you expected. Java behaves the opposite way and calls the override on a half-initialised object, which is arguably worse. Search "calling virtual functions from constructors"; both languages have a trap here and knowing which is which prevents a genuinely baffling debugging session.

💡 Exam angle: state the full construction order (virtual bases → direct bases in base-clause order → members in declaration order → body) and that destruction is the exact reverse — expect a trace question with printed output. The virtual destructor rule is the highest-value item here: explain that deleting a derived object through a non-virtual base pointer skips the derived destructor and leaks. Know that constructors, destructors and operator= are never inherited, and that a base constructor must be called from the initialiser list, not the body.

Syllabus points

Order of constructor/destructor calls

Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.