{"title":"Types of Inheritance","description":null,"content":"C++ lets one class inherit from another in several different shapes. The rules of inheritance themselves are always the same, but the structure of \"who derives from whom\" changes the design. This lesson surveys the five common shapes you'll see in C++ code: single, multilevel, hierarchical, multiple, and hybrid inheritance. For each one, you get a class diagram, a short executable example built from the same product/cart/order domain, and a sentence on when that shape shows up in real code.\n\nTwo of the five shapes (multiple and hybrid) get their own dedicated chapters next, so this lesson keeps them at preview level. By the end, you should be able to look at any class hierarchy and name which shape it is.\n\n---\n\n# Why the Shape Matters\n\nBefore getting into the shapes, it helps to be clear about what we're naming. Every inheritance relationship in C++ is the same mechanic: a derived class gets the public and protected members of its base class, and an object of the derived type \"is a\" base. What changes between the five shapes is the overall structure of those relationships across multiple classes.\n\nThe shape matters for three reasons. First, it tells you how the constructors and destructors run, because longer chains mean more constructor calls. Second, it tells you whether ambiguity is even possible, because some shapes (like multiple inheritance) introduce name conflicts that simpler shapes never have. Third, it shapes how you think about the design: a long single chain says \"specialization\", while a wide hierarchical layout says \"variants of one concept\". Naming the shape early makes the rest of the design conversation easier.\n\nThe running example uses a small slice of an online store: a base `Product` class and several kinds of products (digital downloads, physical goods, subscriptions). Each shape uses the same domain so you can focus on the structure, not on learning a new example each time.\n\n\n```mermaid\nflowchart LR\n A[Single]:::cyan\n B[Multilevel]:::orange\n C[Hierarchical]:::green\n D[Multiple]:::red\n E[Hybrid]:::teal\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe five labels above are the five shapes this lesson covers, in the order they appear. They progress from the simplest (one base, one derived) to the most complex (combinations that produce the diamond pattern).\n\n---\n\n# Single Inheritance\n\nSingle inheritance is the simplest shape: one base class, one derived class. The derived class gets everything `public` and `protected` from the base, then adds its own members on top. This is by far the most common shape you'll see in C++ codebases, and it's the one you've already met in the earlier lessons of this section.\n\n\n```mermaid\nclassDiagram\n Product <|-- DigitalProduct\n class Product {\n +string name\n +double price\n +print() void\n }\n class DigitalProduct {\n +string downloadUrl\n +int sizeMB\n +download() void\n }\n\n style Product fill:#00ceff,stroke:#000,color:#000\n style DigitalProduct fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe arrow with the open triangle points from the derived class to the base. Read it as \"DigitalProduct is a Product\".\n\nHere's the same shape in code. `DigitalProduct` adds a download URL and size on top of the base `Product` fields, and gains a new `download()` method, while still being usable wherever a `Product` is expected.\n\n\n```cpp\n#include \n#include \n\nclass Product {\npublic:\n std::string name;\n double price;\n\n void print() {\n std::cout << name << \" - $\" << price << std::endl;\n }\n};\n\nclass DigitalProduct : public Product {\npublic:\n std::string downloadUrl;\n int sizeMB;\n\n void download() {\n std::cout << \"Downloading \" << name << \" (\" << sizeMB << \" MB) from \" << downloadUrl << std::endl;\n }\n};\n\nint main() {\n DigitalProduct ebook;\n ebook.name = \"C++ Primer\";\n ebook.price = 29.99;\n ebook.downloadUrl = \"store.example.com/files/cpp-primer.pdf\";\n ebook.sizeMB = 18;\n\n ebook.print();\n ebook.download();\n return 0;\n}\n```\n\n\nThe `ebook` object has all four fields (`name`, `price`, `downloadUrl`, `sizeMB`) and both functions. The base members come from `Product`, the new ones come from `DigitalProduct`, and they coexist in one object. Single inheritance shows up whenever you want to take an existing type and add capability to it without restructuring the rest of the codebase.\n\n---\n\n# Multilevel Inheritance\n\nMultilevel inheritance is single inheritance extended into a chain of three or more classes. Each link in the chain inherits from the one above it, and the bottom class transitively gets everything from every ancestor. Think of it as \"B is an A, C is a B, so C is also an A\".\n\n\n```mermaid\nclassDiagram\n Product <|-- DigitalProduct\n DigitalProduct <|-- Ebook\n class Product {\n +string name\n +double price\n +print() void\n }\n class DigitalProduct {\n +string downloadUrl\n +int sizeMB\n +download() void\n }\n class Ebook {\n +string author\n +int pageCount\n +preview() void\n }\n\n style Product fill:#00ceff,stroke:#000,color:#000\n style DigitalProduct fill:#ffa94d,stroke:#000,color:#000\n style Ebook fill:#69db7c,stroke:#000,color:#000\n```\n\n\nReading top to bottom: `Product` is the most general, `DigitalProduct` is a specialization of `Product`, and `Ebook` is a specialization of `DigitalProduct`. An `Ebook` object has every member from all three classes.\n\nThe code mirrors the diagram. Notice how `Ebook` doesn't list `Product` in its base; it inherits from `DigitalProduct`, which already inherits from `Product`. The chain handles the rest.\n\n\n```cpp\n#include \n#include \n\nclass Product {\npublic:\n std::string name;\n double price;\n\n void print() {\n std::cout << name << \" - $\" << price << std::endl;\n }\n};\n\nclass DigitalProduct : public Product {\npublic:\n std::string downloadUrl;\n int sizeMB;\n\n void download() {\n std::cout << \"Downloading \" << name << \" (\" << sizeMB << \" MB)\" << std::endl;\n }\n};\n\nclass Ebook : public DigitalProduct {\npublic:\n std::string author;\n int pageCount;\n\n void preview() {\n std::cout << \"Preview of \" << name << \" by \" << author << \" (\" << pageCount << \" pages)\" << std::endl;\n }\n};\n\nint main() {\n Ebook book;\n book.name = \"Effective Modern C++\";\n book.price = 34.99;\n book.downloadUrl = \"store.example.com/files/emc.pdf\";\n book.sizeMB = 12;\n book.author = \"Scott Meyers\";\n book.pageCount = 320;\n\n book.print();\n book.download();\n book.preview();\n return 0;\n}\n```\n\n\nThe `book` object contains six fields and three methods, sourced from three different classes, and all of them are reachable through one variable. The constructor order, when constructors are defined, runs from the most-base class downward: `Product` first, then `DigitalProduct`, then `Ebook`. Destructors run in the reverse order.\n\n\n> **INFO**\n>\n> **Cost:** Each link in the chain adds another constructor and destructor call when the object is built and torn down. For a three-level chain, that's three pairs of calls per object, though the cost is usually small unless the constructors do real work.\n\n\nMultilevel inheritance shows up in libraries that model \"general kind, specific kind, very specific kind\" relationships: an exception hierarchy where `runtime_error` derives from `exception` and your custom `DatabaseError` derives from `runtime_error` is a textbook case. Just be careful not to overdo the chain; a four- or five-level deep hierarchy quickly becomes hard to follow.\n\n---\n\n# Hierarchical Inheritance\n\nHierarchical inheritance is when one base class has many siblings deriving from it. Instead of going deeper, the tree fans out. Each derived class is a separate variant of the base, with its own additional members, but all of them share the base's common contract.\n\n\n```mermaid\nclassDiagram\n Product <|-- DigitalProduct\n Product <|-- PhysicalProduct\n Product <|-- SubscriptionProduct\n class Product {\n +string name\n +double price\n +print() void\n }\n class DigitalProduct {\n +int sizeMB\n +download() void\n }\n class PhysicalProduct {\n +double weightKg\n +ship() void\n }\n class SubscriptionProduct {\n +int billingCycleDays\n +renew() void\n }\n\n style Product fill:#00ceff,stroke:#000,color:#000\n style DigitalProduct fill:#ffa94d,stroke:#000,color:#000\n style PhysicalProduct fill:#69db7c,stroke:#000,color:#000\n style SubscriptionProduct fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nAll three children inherit from the same `Product` base, but they're independent of each other. A `DigitalProduct` is not a `PhysicalProduct`; they're siblings, not a chain.\n\nThe code below defines all three siblings and uses them side by side in `main`.\n\n\n```cpp\n#include \n#include \n\nclass Product {\npublic:\n std::string name;\n double price;\n\n void print() {\n std::cout << name << \" - $\" << price << std::endl;\n }\n};\n\nclass DigitalProduct : public Product {\npublic:\n int sizeMB;\n\n void download() {\n std::cout << \"Downloading \" << name << \" (\" << sizeMB << \" MB)\" << std::endl;\n }\n};\n\nclass PhysicalProduct : public Product {\npublic:\n double weightKg;\n\n void ship() {\n std::cout << \"Shipping \" << name << \" (\" << weightKg << \" kg)\" << std::endl;\n }\n};\n\nclass SubscriptionProduct : public Product {\npublic:\n int billingCycleDays;\n\n void renew() {\n std::cout << \"Renewing \" << name << \" every \" << billingCycleDays << \" days\" << std::endl;\n }\n};\n\nint main() {\n DigitalProduct ebook;\n ebook.name = \"C++ Cookbook\";\n ebook.price = 24.99;\n ebook.sizeMB = 14;\n\n PhysicalProduct mug;\n mug.name = \"Coffee Mug\";\n mug.price = 9.99;\n mug.weightKg = 0.35;\n\n SubscriptionProduct news;\n news.name = \"Daily Newsletter\";\n news.price = 4.99;\n news.billingCycleDays = 30;\n\n ebook.print(); ebook.download();\n mug.print(); mug.ship();\n news.print(); news.renew();\n return 0;\n}\n```\n\n\nAll three derived classes share the `print()` behavior from `Product` but specialize differently. This is the shape you reach for when there's a single concept (a product, a payment method, a shipping option) with several distinct variants that don't need to know about each other.\n\nHierarchical inheritance pairs naturally with polymorphism. If `print()` were `virtual`, you could store all three in a `std::vector` and call `print()` on each without knowing which variant it is. Virtual functions and runtime polymorphism are covered in the next section of the course.\n\n---\n\n# Multiple Inheritance (Preview)\n\nMultiple inheritance is a derived class with two or more base classes. The derived class inherits members from each base, and an object of the derived type \"is a\" each of its bases. C++ supports this directly, unlike Java or C#, which restrict it to a single class plus interfaces.\n\n\n```mermaid\nclassDiagram\n Product <|-- BundleOffer\n Discountable <|-- BundleOffer\n class Product {\n +string name\n +double price\n }\n class Discountable {\n +double discountPercent\n +applyDiscount() double\n }\n class BundleOffer {\n +int itemCount\n +describe() void\n }\n\n style Product fill:#00ceff,stroke:#000,color:#000\n style Discountable fill:#ffa94d,stroke:#000,color:#000\n style BundleOffer fill:#69db7c,stroke:#000,color:#000\n```\n\n\n`BundleOffer` derives from both `Product` and `Discountable`. The arrows go from the derived class up to each base.\n\nA small example of the syntax: list each base after the colon, separated by commas, with its own access specifier.\n\n\n```cpp\n#include \n#include \n\nclass Product {\npublic:\n std::string name;\n double price;\n};\n\nclass Discountable {\npublic:\n double discountPercent = 0.0;\n\n double applyDiscount(double basePrice) {\n return basePrice * (1.0 - discountPercent / 100.0);\n }\n};\n\nclass BundleOffer : public Product, public Discountable {\npublic:\n int itemCount;\n\n void describe() {\n double finalPrice = applyDiscount(price);\n std::cout << name << \" (\" << itemCount << \" items) - $\" << finalPrice\n << \" after \" << discountPercent << \"% off\" << std::endl;\n }\n};\n\nint main() {\n BundleOffer holiday;\n holiday.name = \"Holiday Bundle\";\n holiday.price = 99.99;\n holiday.discountPercent = 20.0;\n holiday.itemCount = 5;\n\n holiday.describe();\n return 0;\n}\n```\n\n\n`holiday` has access to `name` and `price` from `Product`, `discountPercent` and `applyDiscount` from `Discountable`, and `itemCount` and `describe` from `BundleOffer`. Inside `describe`, the call to `applyDiscount(price)` works because the function comes from one base and the data comes from the other; both are part of the same object.\n\nThis is just a preview. Multiple inheritance becomes interesting when both bases happen to have a member with the same name, or when you want to use it for mixin-style composition. For this survey, the takeaway is that the syntax is a comma-separated list of bases, and an object simply gets the members of all of them.\n\n---\n\n# Hybrid Inheritance and the Diamond (Preview)\n\nHybrid inheritance is what you get when you combine the previous shapes in the same hierarchy. The most famous combination is the **diamond**: one common base, two intermediate classes that each inherit from it, and one bottom class that inherits from both intermediates. Drawn out, the four classes form a diamond shape.\n\n\n```mermaid\nclassDiagram\n Product <|-- DigitalProduct\n Product <|-- Discountable\n DigitalProduct <|-- DiscountedEbook\n Discountable <|-- DiscountedEbook\n class Product {\n +string name\n +double price\n }\n class DigitalProduct {\n +int sizeMB\n }\n class Discountable {\n +double discountPercent\n }\n class DiscountedEbook {\n +string author\n }\n\n style Product fill:#00ceff,stroke:#000,color:#000\n style DigitalProduct fill:#ffa94d,stroke:#000,color:#000\n style Discountable fill:#69db7c,stroke:#000,color:#000\n style DiscountedEbook fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe diamond is the canonical hybrid case: a class that picks up the same ancestor through two different paths. Without special handling, a `DiscountedEbook` ends up with two separate copies of the `Product` part, one through each path.\n\nA short code sketch shows the shape, with the warning that this version still carries two copies of `Product`. The detail of why that happens, what goes wrong, and how to fix it lives in the next two chapters.\n\n\n```cpp\n#include \n#include \n\nclass Product {\npublic:\n std::string name;\n double price;\n};\n\nclass DigitalProduct : public Product {\npublic:\n int sizeMB;\n};\n\nclass Discountable : public Product {\npublic:\n double discountPercent = 0.0;\n};\n\nclass DiscountedEbook : public DigitalProduct, public Discountable {\npublic:\n std::string author;\n};\n\nint main() {\n DiscountedEbook book;\n\n // To set \"the\" name, you have to pick which Product copy.\n // Both paths bring in their own copy of Product's members.\n book.DigitalProduct::name = \"Modern C++\";\n book.DigitalProduct::price = 34.99;\n book.Discountable::name = \"Modern C++\";\n book.Discountable::price = 34.99;\n\n book.sizeMB = 12;\n book.discountPercent = 15.0;\n book.author = \"Scott Meyers\";\n\n std::cout << book.author << \" wrote \" << book.DigitalProduct::name\n << \" ($\" << book.DigitalProduct::price << \", \" << book.discountPercent\n << \"% off)\" << std::endl;\n return 0;\n}\n```\n\n\nThe `book.DigitalProduct::name` and `book.Discountable::name` syntax is what tells the compiler which copy of the inherited member you mean. If you tried to write just `book.name = \"Modern C++\"`, the compiler would refuse with an ambiguity error, because there's no single `name` to assign to. This is the diamond pattern in its raw form, and it's exactly the situation that the next two chapters work through. The first explains why the duplication happens, and the second introduces `virtual` inheritance as the standard fix.\n\nFor now, the takeaway: any inheritance hierarchy that mixes the earlier shapes (multiple plus multilevel, in particular) is \"hybrid\", and any time two of those paths converge on a common ancestor, you've got a diamond.\n\n---\n\n# Comparing the Five Shapes\n\nThe table below summarizes the five shapes you've seen, with the diagram pattern, where the shape tends to show up, and the main thing to watch out for. Use it as a quick reference when you're reading or designing a class hierarchy.\n\n\n| Name | Diagram shape | Typical use | Pitfalls to watch |\n| -------------- | ---------------------------------------- | ---------------------------------------------------------- | --------------------------------------------------------------------------------------- |\n| Single | Two boxes, one arrow | Adding capability to an existing type | Hierarchies grow over time, so plan for change |\n| Multilevel | Vertical chain of three or more | Modeling \"general, specific, very specific\" relationships | Long chains become hard to follow; favor flatter designs when possible |\n| Hierarchical | One base, multiple siblings under it | Variants of one concept that share a common contract | Variants drift apart over time; the base contract has to stay genuinely shared |\n| Multiple | One derived, two or more bases | Combining unrelated capabilities | Name conflicts between bases require disambiguation |\n| Hybrid/Diamond | Multiple plus multilevel converging | Combining shapes; the diamond is the classic case | Common ancestor gets duplicated; virtual inheritance fixes the diamond |\n\n\nThe first three shapes (single, multilevel, hierarchical) are the everyday ones you'll write and read constantly. Multiple inheritance shows up less often but is genuinely useful for certain patterns. Hybrid hierarchies usually arise by accident as a codebase grows, and the diamond in particular is a signal to step back and ask whether the design is right or whether `virtual` inheritance is needed.\n\n\n> **INFO**\n>\n> **Design tip:** When you're designing from scratch, prefer single or hierarchical inheritance over the more complex shapes. Multiple inheritance solves real problems, but it's also easy to misuse, and many C++ style guides ask you to justify it before reaching for it.\n\n\nA useful mental check: when you see a class hierarchy in code, name the shape out loud. If you can't, the design probably has too many moving parts and would benefit from being simplified before any new feature is added.\n\n---\n\n# A Cart That Holds Multiple Shapes\n\nTo pull a few shapes together, here's a small example that uses single and hierarchical inheritance side by side. The cart stores plain `Product` pointers but actually holds two different derived types. This is a hint at runtime polymorphism, which the next section covers in full.\n\n\n```cpp\n#include \n#include \n#include \n\nclass Product {\npublic:\n std::string name;\n double price;\n\n void show() {\n std::cout << \" \" << name << \" - $\" << price << std::endl;\n }\n};\n\nclass DigitalProduct : public Product {\npublic:\n int sizeMB;\n};\n\nclass PhysicalProduct : public Product {\npublic:\n double weightKg;\n};\n\nint main() {\n DigitalProduct ebook;\n ebook.name = \"C++ Primer\";\n ebook.price = 29.99;\n ebook.sizeMB = 18;\n\n PhysicalProduct mug;\n mug.name = \"Coffee Mug\";\n mug.price = 9.99;\n mug.weightKg = 0.35;\n\n std::vector cart;\n cart.push_back(&ebook);\n cart.push_back(&mug);\n\n double total = 0.0;\n std::cout << \"Cart contents:\" << std::endl;\n for (Product* item : cart) {\n item->show();\n total = total + item->price;\n }\n std::cout << \"Total: $\" << total << std::endl;\n return 0;\n}\n```\n\n\nNotice three things. First, the cart's element type is `Product*`, but the actual objects pointed to are derived types. Second, calling `item->show()` calls the base function, because `show()` isn't `virtual`. With `virtual`, each derived class could provide its own `show()` and the cart would call the right one for each item. Third, the `sizeMB` and `weightKg` fields are not reachable through `Product*` even though the underlying objects have them; reaching derived-only members through a base pointer requires a cast or a redesign. Both of those, the virtual dispatch and the casting, are covered in the polymorphism section.\n\nThe cart-of-base-pointers pattern is the natural payoff of hierarchical inheritance: one collection holds many variants of the same concept, and code that processes the collection works against the common contract.\n\n---\n\n# Summary\n\n- C++ inheritance comes in five named shapes: single, multilevel, hierarchical, multiple, and hybrid. The mechanic is the same in every case; what changes is the structure across multiple classes.\n- Single inheritance has one base and one derived class. It's by far the most common shape, used to add capability to an existing type.\n- Multilevel inheritance is a chain of three or more classes. Each link adds another constructor and destructor call to the lifecycle. Long chains become hard to follow, so prefer flatter designs when possible.\n- Hierarchical inheritance has one base with many siblings deriving from it. It pairs naturally with runtime polymorphism, where a base pointer or reference can refer to any sibling.\n- Multiple inheritance lists more than one base after the colon, separated by commas. The derived class gets the members of all bases. Name conflicts and disambiguation are the main complication, covered in the next chapter.\n- Hybrid inheritance combines the previous shapes. The diamond, where a common ancestor is reached through two paths, is the canonical hybrid case and the source of duplicate-subobject issues.\n- When you read a hierarchy, naming the shape out loud is a useful design check. If you can't, the design probably has too many moving parts.\n\nIn the next lesson, we'll look at **Multiple Inheritance** in depth, including how to handle name conflicts between bases and when this shape is genuinely the right tool for the job.","pageType":"cpp"}

Types of Inheritance

Get Premium