{"title":"Multiple Inheritance","description":null,"content":"C++ lets a single class inherit from more than one base at the same time. This is called **multiple inheritance**, and it's a feature most other mainstream object-oriented languages either restrict or refuse outright. The reason C++ keeps it is that, used carefully, it lets you compose small, reusable behaviors (logging, serialization, discount handling) into a single type without the boilerplate of wrapping or delegating. This lesson covers the syntax, the construction order, the ambiguity problems that come with it, the scope-resolution syntax that fixes them, the memory layout that explains why casting between the bases changes the pointer's address, and the mixin pattern, which is the one use case that almost everyone agrees is legitimate.\n\n---\n\n# Syntax\n\nA class declares multiple bases by listing them after the colon, separated by commas, each with its own access specifier.\n\n\n```cpp\n#include \n#include \n\nclass Loggable {\npublic:\n void log(const std::string& message) {\n std::cout << \"[log] \" << message << std::endl;\n }\n};\n\nclass Serializable {\npublic:\n std::string serialize() {\n return \"{...}\";\n }\n};\n\nclass Product : public Loggable, public Serializable {\npublic:\n std::string name;\n double price;\n};\n\nint main() {\n Product mouse;\n mouse.name = \"Wireless Mouse\";\n mouse.price = 24.99;\n\n mouse.log(\"created product\");\n std::cout << mouse.serialize() << std::endl;\n return 0;\n}\n```\n\n\n`Product` now inherits from two unrelated classes at once. It picks up `log()` from `Loggable` and `serialize()` from `Serializable`, and adds its own `name` and `price` fields. From the outside, calling `mouse.log(...)` looks identical to calling a method `Product` defined itself.\n\nThe pieces of the declaration:\n\n- `class Product` is the derived class being defined.\n- `: public Loggable, public Serializable` is the **base list**. Each entry has its own access specifier (`public`, `protected`, or `private`), and you must repeat the access specifier for every base. Writing `: public Loggable, Serializable` makes `Serializable` private by default for `class` (and public by default for `struct`), which is almost never what you want. Spell it out every time.\n- The bases are listed left-to-right. That order matters for two things we'll see soon: construction order and the layout of the object in memory.\n\nThere's no language limit on how many bases you can list, but in practice anything past three is a sign the design is in trouble.\n\n\n```mermaid\nclassDiagram\n class Loggable {\n +log(message)\n }\n class Serializable {\n +serialize()\n }\n class Product {\n +name\n +price\n }\n Loggable <|-- Product\n Serializable <|-- Product\n```\n\n\nThis is the standard \"two arrows in\" picture you'll see in any UML reference. The diamond head sits on each base, pointing toward `Product`, which is the derived class. `Product` has two parents that know nothing about each other.\n\n---\n\n# Construction and Destruction Order\n\nWhen you create an object of a class with multiple bases, the bases are constructed first, and they're constructed **left-to-right in the order they appear in the base list**, not in the order their initializers appear in the constructor's member-initializer list. Then the derived class's own constructor body runs. Destructors run in the reverse order: the derived class first, then the bases right-to-left.\n\n\n```cpp\n#include \n\nclass Loggable {\npublic:\n Loggable() { std::cout << \"Loggable ctor\" << std::endl; }\n ~Loggable() { std::cout << \"Loggable dtor\" << std::endl; }\n};\n\nclass Serializable {\npublic:\n Serializable() { std::cout << \"Serializable ctor\" << std::endl; }\n ~Serializable() { std::cout << \"Serializable dtor\" << std::endl; }\n};\n\nclass Product : public Loggable, public Serializable {\npublic:\n Product() { std::cout << \"Product ctor\" << std::endl; }\n ~Product() { std::cout << \"Product dtor\" << std::endl; }\n};\n\nint main() {\n Product p;\n return 0;\n}\n```\n\n\nRead the output top to bottom. `Loggable` is the first base in the list, so it's constructed first. `Serializable` is next. Once both base subobjects exist, the derived `Product` constructor runs. At end of `main`, `p` goes out of scope and the destructors fire in the exact reverse order: derived first, then the bases from right to left.\n\nThe order is fixed by the **base list**, not by the **member-initializer list**. If you write the constructor like this:\n\n\n```cpp\nProduct() : Serializable(), Loggable() { }\n```\n\n\nthe bases still construct in the order `Loggable`, then `Serializable`, because that's the order the base list declares. Most compilers warn about the mismatch. With g++ you'll see:\n\n\n```shell\nwarning: base 'Loggable' will be initialized after [-Wreorder]\nwarning: base 'Serializable' [-Wreorder]\n```\n\n\nThe fix is to write the initializer list in the same order as the base list. It's a stylistic and a correctness-of-intent issue: if your initializer order doesn't match construction order, you may end up assuming a base is ready when it isn't.\n\n\n> **INFO**\n>\n> **Cost:** Construction order is a compile-time decision baked into the generated code. There's no runtime cost to having multiple bases beyond the bytes each base subobject occupies. The constructors run back-to-back, just like inlined function calls.\n\n\n---\n\n# Member-Name Ambiguity\n\nThe trouble starts when two bases happen to have a member with the same name. The compiler doesn't have a rule for picking one, so it refuses to guess and reports an error.\n\n\n```cpp\n#include \n#include \n\nclass Loggable {\npublic:\n void print() {\n std::cout << \"Loggable::print\" << std::endl;\n }\n};\n\nclass Discountable {\npublic:\n void print() {\n std::cout << \"Discountable::print\" << std::endl;\n }\n};\n\nclass Product : public Loggable, public Discountable {\npublic:\n std::string name;\n double price;\n};\n\nint main() {\n Product mouse;\n mouse.print(); // which print?\n return 0;\n}\n```\n\n\nThis does not compile. Both `Loggable` and `Discountable` define `print()`, and `Product` inherits both of them, so the call `mouse.print()` is genuinely ambiguous. With g++ the message is:\n\n\n```shell\nerror: request for member 'print' is ambiguous\n 24 | mouse.print();\n | ^~~~~\nnote: candidates are: 'void Discountable::print()'\nnote: 'void Loggable::print()'\n```\n\n\nThe compiler is telling you it found two candidates and refuses to pick. The same kind of error happens for data members: if both bases have a field called `id`, then `mouse.id` is also ambiguous.\n\nA common surprise is that the ambiguity is detected at the **lookup** stage, not at the **call** stage. Even if the two functions had different signatures (one took an `int`, one took nothing), the lookup would still find both names and stop. The compiler doesn't try overload resolution across multiple bases.\n\nThe fix is to disambiguate explicitly, which the next section covers.\n\n---\n\n# Disambiguation with Scope Resolution\n\nThe way to call a specific base's member is to qualify the name with the base class and the scope-resolution operator `::`.\n\n\n```cpp\n#include \n#include \n\nclass Loggable {\npublic:\n void print() {\n std::cout << \"Loggable::print\" << std::endl;\n }\n};\n\nclass Discountable {\npublic:\n void print() {\n std::cout << \"Discountable::print\" << std::endl;\n }\n};\n\nclass Product : public Loggable, public Discountable {\npublic:\n std::string name;\n double price;\n};\n\nint main() {\n Product mouse;\n mouse.Loggable::print(); // explicitly call the Loggable version\n mouse.Discountable::print(); // explicitly call the Discountable version\n return 0;\n}\n```\n\n\n`mouse.Loggable::print()` reads as \"on the object `mouse`, call the `print` member that lives in `Loggable`\". The same form works inside `Product`'s own member functions, where the receiver is the implicit `this`.\n\n\n```cpp\n#include \n\nclass Loggable {\npublic:\n void print() {\n std::cout << \"Loggable::print\" << std::endl;\n }\n};\n\nclass Discountable {\npublic:\n void print() {\n std::cout << \"Discountable::print\" << std::endl;\n }\n};\n\nclass Product : public Loggable, public Discountable {\npublic:\n void printAll() {\n Loggable::print(); // unambiguous inside Product\n Discountable::print();\n }\n};\n\nint main() {\n Product mouse;\n mouse.printAll();\n return 0;\n}\n```\n\n\nInside `printAll`, the bare name `print` would still be ambiguous (the same two candidates show up), so each call needs the `Base::` prefix to pick a side.\n\nA second, cleaner option is to add a `using` declaration in the derived class to pull one specific base's member into scope as the unqualified name. That removes the ambiguity for callers, at the cost of saying \"this `print` is the one we mean\":\n\n\n```cpp\nclass Product : public Loggable, public Discountable {\npublic:\n using Loggable::print; // 'print' on a Product means Loggable::print\n};\n```\n\n\nAfter that, `mouse.print()` compiles and calls `Loggable::print`. `mouse.Discountable::print()` is still available for the other one. The `using`-declaration approach is most useful when one of the two `print` functions is the obvious \"default\" for the derived class and you want callers to have a clean one-word call.\n\nA handy mental model: `Base::name` always works. The unqualified `name` works only when lookup finds exactly one candidate. When in doubt, qualify it.\n\n---\n\n# Memory Layout: Two Base Subobjects Side by Side\n\nA multiple-inheritance object isn't magic. The derived object contains one **subobject** for each base, laid out in the same order as the base list, followed by the derived class's own data members. Each base subobject is a fully-formed instance of that base class, sitting at its own offset inside the bigger derived object.\n\n\n```cpp\n#include \n\nclass Loggable {\npublic:\n int loggableTag = 1; // 4 bytes\n};\n\nclass Discountable {\npublic:\n double discountRate = 0.0; // 8 bytes\n};\n\nclass Product : public Loggable, public Discountable {\npublic:\n int stock = 0; // 4 bytes\n};\n\nint main() {\n Product mouse;\n\n std::cout << \"sizeof(Loggable) = \" << sizeof(Loggable) << std::endl;\n std::cout << \"sizeof(Discountable) = \" << sizeof(Discountable) << std::endl;\n std::cout << \"sizeof(Product) = \" << sizeof(Product) << std::endl;\n\n Product* p = &mouse;\n Loggable* l = &mouse;\n Discountable* d = &mouse;\n\n std::cout << \"address of Product* = \" << static_cast(p) << std::endl;\n std::cout << \"address of Loggable* = \" << static_cast(l) << std::endl;\n std::cout << \"address of Discountable* = \" << static_cast(d) << std::endl;\n return 0;\n}\n```\n\n\n**Sample output (typical 64-bit Linux, g++):**\n\n\n```shell\nsizeof(Loggable) = 4\nsizeof(Discountable) = 8\nsizeof(Product) = 24\naddress of Product* = 0x7ffd5b3a5b40\naddress of Loggable* = 0x7ffd5b3a5b40\naddress of Discountable* = 0x7ffd5b3a5b48\n```\n\n\nTwo things stand out. First, `sizeof(Product)` is `24`, not `4 + 8 + 4 = 16`. The compiler inserts padding so that `Discountable`'s `double` lands on an 8-byte boundary, and the trailing `int stock` adds 4 bytes plus 4 more bytes of tail padding so an array of `Product` keeps every element 8-byte aligned.\n\nSecond, and this is the key part, the three pointers don't all hold the same address. `Loggable*` and `Product*` point at the start of the object (offset 0), because `Loggable` is the first base. `Discountable*` points 8 bytes deeper into the same object, because the `Discountable` subobject sits after the `Loggable` one. The compiler **adjusts the pointer value** when you cast between the derived type and a non-leading base.\n\n\n```mermaid\nflowchart LR\n subgraph Mem[\"Product object in memory\"]\n L[Loggable subobject
loggableTag
offset 0]:::cyan\n PAD1[padding]:::orange\n D[Discountable subobject
discountRate
offset 8]:::green\n S[stock
offset 16]:::teal\n PAD2[tail padding]:::orange\n end\n\n PP[Product* p]:::red -->|points to offset 0| L\n LP[Loggable* l]:::red -->|points to offset 0| L\n DP[Discountable* d]:::red -->|points to offset 8| D\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 diagram shows all three pointers reaching into the same single object, but at different starting addresses. The compiler does the offset arithmetic for you whenever a cast happens, including the implicit casts that happen when you pass a `Product*` to a function expecting a `Discountable*`.\n\nThis adjustment is silent and correct, but it does mean two things to keep in mind:\n\n- Comparing pointers with `==` after casting between unrelated bases of the same object can give \"different\" answers because the addresses really are different.\n- Casting a `Discountable*` back to `Product*` with a `static_cast` works only because the compiler knows the offset to subtract. A `reinterpret_cast` skips the adjustment and produces a broken pointer. This is one reason raw casts in code with multiple inheritance are risky.\n\n\n> **INFO**\n>\n> **Cost:** Casting a derived pointer to a base subobject pointer is one integer addition (or subtraction) at runtime when the offset is non-zero. For the leading base, the compiler doesn't need to adjust at all. This cost is negligible for normal code, but it is the reason `reinterpret_cast` is unsafe across multiple inheritance.\n\n\n---\n\n# The Mixin Pattern\n\nThe one use of multiple inheritance that almost every C++ style guide tolerates is the **mixin pattern**. A mixin is a small class that adds a single, focused capability (logging, serialization, discount handling, equality) to whatever class inherits from it. Mixins typically have no data of their own, or just one or two fields, and they don't model an \"is-a\" relationship in the domain. They model a \"can-do\" capability.\n\nThe pattern works because mixins are designed not to clash with each other. They use distinct method names, hold no overlapping data, and don't try to be standalone types.\n\nHere's a worked example. `Loggable` adds a `log` method, `Discountable` adds discount-rate handling, and `Product` mixes both into a domain type that already has its own `name` and `price`.\n\n\n```cpp\n#include \n#include \n\nclass Loggable {\npublic:\n void log(const std::string& message) const {\n std::cout << \"[log] \" << message << std::endl;\n }\n};\n\nclass Discountable {\npublic:\n double discountRate = 0.0;\n\n void setDiscount(double rate) {\n if (rate < 0.0) rate = 0.0;\n if (rate > 1.0) rate = 1.0;\n discountRate = rate;\n }\n\n double applyDiscount(double price) const {\n return price * (1.0 - discountRate);\n }\n};\n\nclass Product : public Loggable, public Discountable {\npublic:\n std::string name;\n double price;\n\n void describe() const {\n log(\"describing \" + name);\n std::cout << name\n << \" | list $\" << price\n << \" | final $\" << applyDiscount(price)\n << std::endl;\n }\n};\n\nint main() {\n Product mouse;\n mouse.name = \"Wireless Mouse\";\n mouse.price = 24.99;\n mouse.setDiscount(0.20);\n\n mouse.describe();\n mouse.log(\"ready to ship\");\n return 0;\n}\n```\n\n\nA few things this example shows about why mixins compose cleanly:\n\n- Method names don't collide. `Loggable::log` and `Discountable::setDiscount`/`applyDiscount` are deliberately distinct, so calls like `mouse.log(...)` are unambiguous without scope-resolution syntax.\n- Each mixin is small and self-contained. `Loggable` has no data members, so it adds essentially nothing to the object's size. `Discountable` adds one `double`. The cost of mixing them in is the cost of those bytes plus their methods.\n- The capabilities are orthogonal. `Loggable` doesn't depend on `Discountable` or vice versa. You can mix them independently or together.\n\nThe same `Discountable` mixin can be added to a different domain class:\n\n\n```cpp\n#include \n#include \n#include \n\nclass Loggable {\npublic:\n void log(const std::string& message) const {\n std::cout << \"[log] \" << message << std::endl;\n }\n};\n\nclass Discountable {\npublic:\n double discountRate = 0.0;\n\n void setDiscount(double rate) {\n if (rate < 0.0) rate = 0.0;\n if (rate > 1.0) rate = 1.0;\n discountRate = rate;\n }\n\n double applyDiscount(double price) const {\n return price * (1.0 - discountRate);\n }\n};\n\nclass Cart : public Loggable, public Discountable {\npublic:\n std::vector prices;\n\n void add(double price) {\n prices.push_back(price);\n log(\"added item at $\" + std::to_string(price));\n }\n\n double total() const {\n double sum = 0.0;\n for (double p : prices) {\n sum = sum + p;\n }\n return applyDiscount(sum);\n }\n};\n\nint main() {\n Cart cart;\n cart.add(24.99);\n cart.add(89.99);\n cart.setDiscount(0.10);\n\n std::cout << \"Cart total after discount: $\" << cart.total() << std::endl;\n return 0;\n}\n```\n\n\nBoth `Product` and `Cart` get the same two capabilities, written once. That's the practical payoff of mixins. Without multiple inheritance, you'd have to either copy-paste the code into both classes or make `Loggable` and `Discountable` member fields and write forwarding calls in every container class. Multiple inheritance lets the capability sit at the language level instead of behind a wrapper.\n\nThe discipline that makes mixins safe is small:\n\n- Pick distinct names that won't collide across mixins.\n- Keep mixins capability-focused, not domain-focused. `Loggable` is fine, `Customer` is not.\n- Avoid mixins that hold large or overlapping state.\n- If two mixins ever share a common base, that's the diamond problem, which is a separate topic.\n\n---\n\n# What's Wrong With This Code?\n\nHere's a real ambiguity bug, the kind that shows up when two well-meaning mixins both happen to define a common method name.\n\n\n```cpp\n#include \n#include \n\nclass Loggable {\npublic:\n void describe() const {\n std::cout << \"Loggable says: I can log.\" << std::endl;\n }\n};\n\nclass Discountable {\npublic:\n void describe() const {\n std::cout << \"Discountable says: I can discount.\" << std::endl;\n }\n};\n\nclass Product : public Loggable, public Discountable {\npublic:\n std::string name;\n};\n\nint main() {\n Product mouse;\n mouse.name = \"Wireless Mouse\";\n mouse.describe(); // which describe?\n return 0;\n}\n```\n\n\nCompile this with `g++ -std=c++17 example.cpp` and the build fails with something like:\n\n\n```shell\nexample.cpp: In function 'int main()':\nexample.cpp:24:11: error: request for member 'describe' is ambiguous\n 24 | mouse.describe();\n | ^~~~~~~~\nexample.cpp:11:10: note: candidates are: 'void Discountable::describe() const'\n 11 | void describe() const {\n | ^~~~~~~~\nexample.cpp:5:10: note: 'void Loggable::describe() const'\n 5 | void describe() const {\n | ^~~~~~~~\n```\n\n\nBoth `Loggable` and `Discountable` define `describe`, and `Product` inherits both. The compiler can't decide which one `mouse.describe()` should call, so it refuses to compile.\n\nThere are two reasonable fixes. Pick the one that fits the intent.\n\n**Fix 1: Disambiguate at the call site.** If you want both, call them by name:\n\n\n```cpp\nmouse.Loggable::describe();\nmouse.Discountable::describe();\n```\n\n\n**Fix 2: Override `describe` in `Product` and call both bases yourself.** This is cleaner if `Product` should always describe itself in a particular composite way:\n\n\n```cpp\nclass Product : public Loggable, public Discountable {\npublic:\n std::string name;\n\n void describe() const {\n std::cout << \"Product \" << name << \":\" << std::endl;\n Loggable::describe();\n Discountable::describe();\n }\n};\n```\n\n\n**Output of fix 2:**\n\n\n```shell\nProduct Wireless Mouse:\nLoggable says: I can log.\nDiscountable says: I can discount.\n```\n\n\nThe lesson is that ambiguity errors in multiple inheritance are usually a signal to rethink either the names in your mixins or the design of your derived class. The compiler is doing you a favor by refusing to guess.\n\n---\n\n# When to Avoid Multiple Inheritance\n\nMultiple inheritance has a real cost, and many teams either ban it outright or restrict it to mixins. It's worth knowing why so the limits feel like guidance, not folklore.\n\n\n| Concern | Why it matters |\n|---------|----------------|\n| Name ambiguity | Adding a new method to a base can suddenly break unrelated code that uses the derived class. |\n| Confusing pointer arithmetic | Casting between bases changes the address of the same object, which surprises readers. |\n| Constructor and destructor order | The order is fixed by the base list, not the initializer list, and it's easy to assume otherwise. |\n| Common ancestors | If two bases share a common base, you get two copies of that base in the derived object unless you use virtual inheritance, which the next chapter covers. |\n| Tooling and debugging | Stack traces and debugger views become harder to follow when the same object has multiple \"this\" pointers, one per base. |\n| Cognitive load for readers | Most C++ developers see single inheritance daily and multiple inheritance rarely. Designs with multiple inheritance take longer to read. |\n\n\nMajor C++ style guides reflect this. The Google C++ Style Guide allows multiple inheritance only when all but one of the bases have no state (are essentially mixins). The C++ Core Guidelines push the same direction, recommending interfaces (abstract classes with no data) when you need multiple bases. The pattern that survives all of these rules is mixins, which is why this lesson spent so much time on them.\n\nThe signal that you're heading into trouble is when two of your bases start to overlap: same field name, same method name, or shared ancestor. At that point the design wants to be reshaped, often into composition (holding mixins as members and forwarding to them) or into a single base with a richer interface.\n\n---\n\n# Summary\n\n- C++ supports multiple inheritance with the syntax `class Derived : public Base1, public Base2 { ... };`. Each base needs its own access specifier, and the bases are listed in the base list.\n- Bases are constructed left-to-right in the order they appear in the base list, then the derived class. Destructors run in reverse: derived first, then bases right-to-left. The base list, not the member-initializer list, controls the order.\n- When two bases have a member with the same name, the unqualified name is ambiguous and the compiler refuses to compile the call. Disambiguate with `obj.Base1::method()` from outside the class or `Base1::method()` inside it. A `using Base1::method;` declaration in the derived class can also pull one base's version into unqualified scope.\n- A derived object contains one subobject per base, laid out in base-list order, plus the derived class's own data. Casting a derived pointer to a non-leading base shifts the address by the subobject's offset. The compiler handles the adjustment for `static_cast` and implicit conversions, but `reinterpret_cast` skips it and produces a broken pointer.\n- The mixin pattern is the safe, well-accepted use of multiple inheritance: small capability classes (`Loggable`, `Discountable`, `Rateable`) with distinct names and minimal state, combined into domain types like `Product` and `Cart`.\n- Outside of mixins, multiple inheritance is widely discouraged because of name ambiguity, pointer-adjustment surprises, and the cost it adds for readers and tools. Most style guides limit multiple inheritance to interfaces and mixins.\n\nIn the next lesson, we'll look at the **Diamond Problem**, which appears when two of your bases happen to share a common ancestor and the derived class ends up with two copies of that ancestor's state.","pageType":"cpp"}

Multiple Inheritance

Get Premium