Inheritance

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

Inheritance

A derived class reuses and extends a base class — the "is-a" relationship, with three access modes and one famous trap.

🌍 Where this lives: inheritance is what every GUI framework is built from. A Qt QPushButton inherits QAbstractButton inherits QWidget inherits QObject — four levels, and that is why every widget can be positioned, painted and given a parent without each class reimplementing it. The C++ standard library uses it too: std::ifstream inherits std::istream, which is why getline(file, line) and getline(cin, line) are the same function. But inheritance is also the most overused feature in OOP — search "composition over inheritance" after this page. It is the single most valuable design lesson in the whole subject, and it will make your project work better.

Syntax and the three access modes

class Derived : access-specifier Base { ... }; class Car : public Vehicle { }; /* the normal case */ HOW THE MODE TRANSFORMS INHERITED ACCESS: Base member is: public protected private ───────────────────────────────────────────────────────── : public public protected inaccessible : protected protected protected inaccessible : private private private inaccessible Read the table as: "what does this member become inside Derived, and who outside can reach it?" Three facts that follow: 1. A base's PRIVATE members are NEVER accessible in the derived class, whatever the mode. They are inherited (they occupy space in the object) but not reachable. 2. public inheritance preserves the interface — this is the ONLY mode that models "is-a". 3. private/protected inheritance model "implemented-in- terms-of", which composition usually expresses better. DEFAULT if you omit the specifier: class D : Base { }; → PRIVATE inheritance struct D : Base { }; → PUBLIC inheritance That mismatch surprises people; always write it explicitly.

access_modes.cpp

#include <iostream>

class Base {
private:
    int priv = 1;
protected:
    int prot = 2;
public:
    int publ = 3;
    void show() const {
        std::cout << "  Base: " << priv << " " << prot
                  << " " << publ << "\n";
    }
};

class PubDerived : public Base {
public:
    void test() {
        /* std::cout << priv;   ✗ private in Base */
        std::cout << "  PubDerived sees prot=" << prot
                  << " publ=" << publ << "\n";
    }
};

class PrivDerived : private Base {
public:
    void test() {
        /* accessible INSIDE, but publ is now private,
           so outsiders cannot reach it through PrivDerived */
        std::cout << "  PrivDerived sees prot=" << prot
                  << " publ=" << publ << "\n";
    }
};

class GrandChild : public PubDerived {
public:
    void test() {
        /* protected survives one more level */
        std::cout << "  GrandChild sees prot=" << prot << "\n";
    }
};

int main() {
    PubDerived  a;  a.test();
    PrivDerived b;  b.test();
    GrandChild  c;  c.test();

    std::cout << "outside: a.publ = " << a.publ << "\n";
    /* std::cout << b.publ;  ✗ publ became private
                             in PrivDerived            */
    a.show();          /* public method inherited */
    /* b.show();  ✗ also private now */
    return 0;
}
Output:
  PubDerived sees prot=2 publ=3
  PrivDerived sees prot=2 publ=3
  GrandChild sees prot=2
outside: a.publ = 3
  Base: 1 2 3

Types of inheritance

SINGLE MULTILEVEL HIERARCHICAL A A A | | / | \ B B B C D | C MULTIPLE HYBRID (multiple + hierarchical) A B A \ / / \ C B C \ / D ← the "diamond" C++ supports all five. Java allows only single inheritance of classes (multiple inheritance of interfaces only) — precisely to avoid the diamond problem below. class C : public A, public B { }; /* multiple */ The order matters for construction: A's constructor runs before B's, following the declaration order in the base list.

shapes.cpp

#include <iostream>
#include <string>
#include <cmath>

/* BASE: what every shape has in common */
class Shape {
protected:
    std::string name;
public:
    Shape(std::string n) : name(std::move(n)) {}
    /* virtual so derived versions are called through a
       Shape* — covered fully in the next section */
    virtual double area() const { return 0.0; }
    virtual double perimeter() const { return 0.0; }
    void describe() const {
        std::cout << "  " << name
                  << ": area=" << area()
                  << " perim=" << perimeter() << "\n";
    }
    virtual ~Shape() = default;
};

class Rectangle : public Shape {
protected:
    double w, h;
public:
    Rectangle(double a, double b)
        : Shape("Rectangle"), w(a), h(b) {}
    double area()      const override { return w * h; }
    double perimeter() const override { return 2*(w+h); }
};

/* MULTILEVEL: Square from Rectangle from Shape */
class Square : public Rectangle {
public:
    explicit Square(double s) : Rectangle(s, s) {
        name = "Square";        /* protected: reachable */
    }
};

/* HIERARCHICAL: Circle also derives from Shape */
class Circle : public Shape {
    double r;
public:
    explicit Circle(double rad) : Shape("Circle"), r(rad) {}
    double area()      const override { return M_PI * r * r; }
    double perimeter() const override { return 2 * M_PI * r; }
};

int main() {
    Rectangle a(4, 6);
    Square    b(5);
    Circle    c(3);
    a.describe(); b.describe(); c.describe();

    /* a Square IS-A Rectangle IS-A Shape */
    Shape *shapes[] = { &a, &b, &c };
    double total = 0;
    for (Shape *s : shapes) total += s->area();
    std::cout << "  total area = " << total << "\n";
    return 0;
}
Output:
  Rectangle: area=24 perim=20
  Square: area=25 perim=20
  Circle: area=28.2743 perim=18.8496
  total area = 77.2743

Checking: Rectangle 4×6 : area 24, perimeter 2(4+6) = 20 ✔ Square 5 : area 25, perimeter 2(5+5) = 20 ✔ Circle r=3 : area π×9 = 28.2743 perimeter 2π×3 = 18.8496 ✔ total = 24 + 25 + 28.2743 = 77.2743 ✔ Notice Square reuses Rectangle's area() unchanged — it needs no code of its own beyond passing s for both sides. That IS the reuse benefit of inheritance. Also notice both Rectangle 4×6 and Square 5 have perimeter 20 but different areas. For a fixed perimeter the square maximises area — a genuine geometric fact, and a useful sanity check that the code is right.

The classic trap — Square is not a Rectangle

The code above compiles and works, but it hides a real design flaw known as an LSP violation (Liskov Substitution Principle): anywhere a Rectangle is expected, a Square must behave correctly. void stretch(Rectangle &r) { r.setWidth(10); r.setHeight(4); assert(r.area() == 40); /* obviously true for a Rectangle */ } Square s(5); stretch(s); /* if Square::setWidth also changes the height to stay square, then area() == 16, and the assert FAILS */ Mathematically a square IS a rectangle. In code, a mutable Square is NOT a substitutable Rectangle, because Rectangle's contract allows width and height to vary independently and Square's invariant forbids it. THE RESOLUTION — three valid options: 1. Make both IMMUTABLE (no setters). Then Square really is substitutable, because nothing can violate the invariant after construction. 2. Give them a common base (Shape) as SIBLINGS rather than making one derive from the other. 3. Use COMPOSITION: Square HAS-A side length and computes what it needs. THE TEST for whether inheritance is right: · "is-a" and fully substitutable → public inheritance · "has-a" or "uses-a" → composition (a member) · "implemented-in-terms-of" → composition, or private inheritance

This matters beyond exams. The square/rectangle problem is the standard illustration that compiling is not the same as correct. Public inheritance is a promise to every future caller that your derived class can stand in for the base — and the compiler cannot check that promise. You can.

Worked example — the diamond problem

diamond.cpp

#include <iostream>

class Person {
protected:
    std::string name;
public:
    Person(std::string n) : name(std::move(n)) {
        std::cout << "    Person(" << name << ")\n";
    }
    void greet() const {
        std::cout << "    I am " << name << "\n";
    }
};

/* NON-virtual inheritance -> TWO Person copies in Assistant */
class Student : public Person {
public:
    Student(std::string n) : Person(n + "/student") {}
};
class Teacher : public Person {
public:
    Teacher(std::string n) : Person(n + "/teacher") {}
};
class Assistant : public Student, public Teacher {
public:
    Assistant(std::string n) : Student(n), Teacher(n) {}
};

/* VIRTUAL inheritance -> ONE shared Person */
class VPerson {
protected:
    std::string name;
public:
    VPerson(std::string n = "?") : name(std::move(n)) {
        std::cout << "    VPerson(" << name << ")\n";
    }
    void greet() const {
        std::cout << "    I am " << name << "\n";
    }
};
class VStudent : virtual public VPerson {
public:
    VStudent(std::string n) : VPerson(std::move(n)) {}
};
class VTeacher : virtual public VPerson {
public:
    VTeacher(std::string n) : VPerson(std::move(n)) {}
};
class VAssistant : public VStudent, public VTeacher {
public:
    /* the MOST DERIVED class initialises the virtual base */
    VAssistant(std::string n)
        : VPerson(n), VStudent(n), VTeacher(n) {}
};

int main() {
    std::cout << "  non-virtual Assistant:\n";
    Assistant a("Ram");
    /* a.greet();   ✗ error: request for member 'greet'
                     is ambiguous — two Person copies  */
    a.Student::greet();
    a.Teacher::greet();
    std::cout << "  sizeof(Assistant) = " << sizeof(Assistant)
              << "\n\n";

    std::cout << "  virtual VAssistant:\n";
    VAssistant v("Sita");
    v.greet();          /* ✔ unambiguous: ONE VPerson */
    std::cout << "  sizeof(VAssistant) = " << sizeof(VAssistant)
              << "\n";
    return 0;
}
Output:
  non-virtual Assistant:
    Person(Ram/student)
    Person(Ram/teacher)
    I am Ram/student
    I am Ram/teacher
  sizeof(Assistant) = 64

  virtual VAssistant:
    VPerson(Sita)
    sizeof(VAssistant) = 48

The output makes the problem concrete: NON-VIRTUAL: Person's constructor ran TWICE. The Assistant object contains two complete Person sub-objects with two separate `name` fields holding different values. So: · a.greet() is AMBIGUOUS — which Person? · a.name is ambiguous too · you must disambiguate with a.Student::greet() · the object is larger (two names stored) VIRTUAL: VPerson's constructor ran ONCE. There is exactly one shared sub-object, so greet() is unambiguous and the object is smaller. WHY the most-derived class initialises the virtual base: with one shared VPerson, VStudent and VTeacher cannot each construct it — they would fight over the value. So C++ makes VAssistant responsible. If VAssistant omitted VPerson(n), the DEFAULT VPerson constructor would run and name would be "?" — which is why a virtual base almost always needs a default constructor as a safety net. THE COST of virtual inheritance: · an extra pointer per virtual base for the offset lookup · member access through a virtual base is one indirection slower · construction order becomes harder to reason about Java avoided all of this by banning multiple inheritance of classes. C++ kept it and gave you `virtual` to manage it — which is powerful and genuinely tricky. Use it rarely.

Overriding, hiding, and `using`

hiding.cpp

#include <iostream>

class Base {
public:
    void f()        { std::cout << "  Base::f()\n"; }
    void f(int x)   { std::cout << "  Base::f(" << x << ")\n"; }
    void g()        { std::cout << "  Base::g()\n"; }
};

class Bad : public Base {
public:
    /* declaring ANY f() HIDES every Base::f overload */
    void f(double d) { std::cout << "  Bad::f(" << d << ")\n"; }
};

class Good : public Base {
public:
    using Base::f;      /* bring the base overloads back */
    void f(double d) { std::cout << "  Good::f(" << d << ")\n"; }
};

int main() {
    Bad b;
    b.f(2.5);
    b.f(7);            /* int -> double: Bad::f(7), NOT
                          Base::f(int)! */
    /* b.f();   ✗ error: no matching function — Base::f()
                  is HIDDEN                             */
    b.Base::f();       /* explicit qualification works */

    std::cout << "  --- with using Base::f ---\n";
    Good g;
    g.f(2.5);          /* Good::f(double) */
    g.f(7);            /* Base::f(int) — exact match wins */
    g.f();             /* Base::f()      */
    return 0;
}
Output:
  Bad::f(2.5)
  Bad::f(7)
  Base::f()
  --- with using Base::f ---
  Good::f(2.5)
  Base::f(7)
  Base::f()

NAME HIDING, precisely: when the compiler looks up a name in a derived class and finds ANY declaration of it, it STOPS. It does not continue into the base class to gather more overloads. So one f(double) in Bad hides f() and f(int) entirely. Look at the difference for b.f(7) vs g.f(7): Bad : only f(double) is visible → 7 converts to 7.0 → prints "Bad::f(7)". Silent, lossy, surprising. Good: using Base::f made all three visible → f(int) is an EXACT match and wins → prints "Base::f(7)". Hiding is NOT overriding. Three distinct things: OVERLOADING same scope, different parameters HIDING derived name hides base name (no virtual) OVERRIDING derived redefines a VIRTUAL base function with the SAME signature — runtime dispatch, covered in the next section Use `override` on every intended override; the compiler then rejects a signature mismatch instead of silently creating a hidden function.

🌍 Go further: the industry has largely moved away from deep inheritance hierarchies, and the reason is testability and coupling — a change in a base class ripples into every descendant, a problem called the fragile base class. Modern designs favour composition plus interfaces: Go has no inheritance at all, Rust has traits instead, and even Java's own guidance now says "favour composition". C++'s answer is that you have all the tools and must choose. Search "fragile base class problem" and "strategy pattern vs inheritance" — the second shows the composition alternative in working code.

💡 Exam angle: the access-mode table (public/protected/private inheritance × public/protected/private members) is a guaranteed question — memorise it and know that base privates are never accessible. Name and draw the five inheritance types. The diamond problem with virtual inheritance as its solution is a standard long answer: explain the duplicate sub-object, the ambiguity, and that the most-derived class initialises a virtual base. Also distinguish overloading, hiding and overriding.

Syllabus points

Single, multiple, multilevel
Hybrid, multipath inheritance

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.