Memory Layout in Multiple Inheritance

1. The Memory Layout of Multiple Base Classes

Let's start with a straightforward case: a class C that inherits from two unrelated base classes, A and B, both of which have virtual functions.

class A {
public:
    virtual void funcA() { /* ... */ }
    // ... members of A
};

class B {
public:
    virtual void funcB() { /* ... */ }
    // ... members of B
};

class C : public A, public B {
public:
    // ... members of C
};

Since a C object "is an" A and "is a" B, the compiler constructs the memory for a C object by simply placing the subobjects for its base classes one after another. The layout will look like this:

1. The A subobject (containing A's vptr and data members).
2. The B subobject (containing B's vptr and data members).
3. C's own data members.

Notice the immediate consequence: an object of type C now contains two virtual pointers (vptr)—one for each base class that has a vtable.

To see a detailed walkthrough of this layout and the construction process, let's watch a segment from a CppCon talk.

2. The this Pointer and Thunks

As the video explained, the existence of multiple subobjects introduces a crucial complexity: pointer adjustment.

Consider an object c_obj of type C:

C c_obj;
C* c_ptr = &c_obj;

• A pointer to its A subobject (A* a_ptr = c_ptr;) will have the same address as c_ptr, because A is the first base class and is located at the beginning of the C object.
• However, a pointer to its B subobject (B* b_ptr = c_ptr;) will have a different address. The compiler automatically adds an offset to c_ptr to point to the beginning of the B subobject inside c_obj.

This is straightforward for data access, but it creates a challenge for virtual function calls. Imagine C overrides a virtual function from B:

class C : public A, public B {
public:
    void funcB() override { /* ... uses members of C ... */ }
    int c_data;
};

When you call b_ptr->funcB(), the vtable lookup directs the call to C::funcB(). However, the this pointer inside C::funcB() must point to the beginning of the entire C object so it can access c_data and any members from A, not just the B subobject that b_ptr points to.

How does the compiler fix this? It uses a clever mechanism called a thunk (or trampoline). The vtable entry for funcB within the B subobject of C doesn't point directly to C::funcB. Instead, it points to a tiny piece of auto-generated code—the thunk—whose only job is to adjust the this pointer (by subtracting the offset) and then jump to the actual C::funcB implementation.

For a deep dive into how this is implemented at the assembly level, the following resources are excellent. Your background in C and memory will make the assembly and diagrams here very insightful.

To reinforce this, let's look at another resource that provides clear ASCII-art diagrams of the vtables and the thunk mechanism.

The image below shows a more complex but realistic example of an object layout with multiple inheritance, clearly labeling the multiple vptrs and the presence of thunks in the vtables.

struct Base1 { int x = 1; virtual ~Base1() = default; };
struct Base2 { int y = 2; virtual ~Base2() = default; };
struct Derived : public Base1, public Base2 { int z = 3; };

int main() {
    Derived* d = new Derived();
    Base1* b1 = d;
    Base2* b2 = d;

    std::cout << "Address of Derived object: " << d << std::endl;
    std::cout << "Address pointed to by b1:  " << b1 << std::endl;
    std::cout << "Address pointed to by b2:  " << b2 << std::endl;

    delete d;
}

Address of Derived object: 0x55a4...
Address pointed to by b1:  0x55a4...
Address pointed to by b2:  0x55a4... + offset (e.g., 0x55a4...8 on a 64-bit system where Base1 has a vptr)

3. A Preview of the "Diamond Problem"

This exploration of multiple inheritance naturally leads us to a famous C++ conundrum: the diamond problem. This occurs when a class inherits from two other classes that both share a common base class.

What happens to the memory layout of CatDog in this scenario? Without any special handling, a CatDog object would end up containing two separate Animal subobjects: one via Cat and one via Dog. This leads to ambiguity and often isn't the desired behavior.

The following video clip introduces this problem, setting the stage for the solution we will discuss in our next lesson.

Conclusion

Today we've peeled back another layer of C++'s object model, revealing the mechanics of multiple inheritance. You are now equipped with a low-level understanding that many C++ programmers lack.

Key Takeaways:

• An object with multiple base classes contains the subobjects of its bases laid out sequentially in memory.
• If multiple base classes have virtual functions, the derived object will contain multiple vptrs, one for each base subobject with a vtable.
• Casting a derived pointer to a non-primary base class pointer requires the compiler to perform pointer adjustment.
• When a virtual function from a non-primary base is overridden, the compiler generates a thunk to adjust the this pointer back to the start of the full derived object before making the call.
• This structure can lead to the diamond problem, where a common base class is duplicated in the final object's memory layout.

In our next lesson, we will tackle the diamond problem head-on by exploring virtual inheritance, the C++ feature designed to solve it. We will analyze its implementation and the significant memory overhead and complexity it introduces.