Derived Class Memory Layout: Single Inheritance

1. The Base Class Subobject: An "Is-A" Relationship in Memory

Let's begin with the simplest case: single inheritance without any virtual functions. The "is-a" relationship (e.g., a Dog is an Animal) is physically represented by placing the Base class's data members directly inside the Derived object's memory layout. This embedded part is called the base class subobject.

Most compilers, for efficiency and simplicity, will lay out the derived object's memory with the base class subobject first, followed by the derived class's own data members.

class Base {
public:
    int base_data;
};

class Derived : public Base {
public:
    int derived_data;
};

// Memory layout of a 'Derived' object:
// |-------------------|
// | base_data         |  <-- Base class subobject
// |-------------------|
// | derived_data      |
// |-------------------|

This layout has a critical consequence: the memory address of a Derived object is the same as the memory address of its Base subobject. This allows a Derived* to be converted to a Base* without any calculation—the pointer value remains the same. This is a fundamental optimization that makes polymorphism efficient.

2. Adding Polymorphism: The Arrival of the vptr

The memory layout we just saw is for non-polymorphic classes. The moment we introduce at least one virtual function into the base class, the compiler must add a mechanism for runtime dispatch. This mechanism introduces a new, hidden member to our objects: the virtual pointer, or vptr.

• What is it? The vptr is a hidden pointer, added by the compiler to every object of a polymorphic class.
• What does it do? It points to the virtual table (vtable) for that object's class. The vtable is a static, per-class array of function pointers for all virtual functions.
• Key Distinction: Every object gets its own vptr, but there is only one vtable per class. All Dog objects, for example, will have their own vptr, but all these pointers will point to the same Dog vtable.

Adding this vptr increases the size of the object.

The video brilliantly shows that the vptr is typically placed at the very beginning of the object's memory, at offset 0.

3. The Complete Picture: Layout of a Polymorphic Derived Class

Now let's combine these two ideas: the base class subobject and the vptr.

When a Derived class inherits from a polymorphic Base class:

1. The Base subobject is still placed at the beginning of the Derived object.
2. Since Base is polymorphic, this subobject's first member is its vptr.
3. The data members of the Base class follow the vptr.
4. Finally, the data members of the Derived class follow the Base subobject.

The memory layout of a polymorphic Derived object looks like this:

class Base {
public:
    virtual void func() {}
    int base_data;
};

class Derived : public Base {
public:
    void func() override {}
    int derived_data;
};

// Memory layout of a 'Derived' object:
// |-------------------|  \
// | vptr              |   |
// |-------------------|   |  Base class subobject
// | base_data         |   |
// |-------------------|  /
// | (padding, if any) |
// |-------------------|
// | derived_data      |
// |-------------------|
// | (padding, if any) |
// |-------------------|

Note that the vptr inside a Derived object will point to the vtable for the Derived class, not the Base class. Let's see a practical visualization of this.

The article confirms our model: the derived object is a contiguous block of memory starting with the base class subobject (which itself starts with the vptr), followed by the derived class's members.

4. A Note on Construction Order and the vptr

How does the vptr get its correct value? This happens during construction, and the order is critical. When you create a Derived object:

1. The Base constructor is called first. At this stage, the object is considered a Base object. The vptr is set to point to the Base vtable.
2. After the Base constructor completes, the Derived constructor runs.
3. The Derived constructor then overwrites the vptr to point to the Derived vtable. The object is now fully a Derived object.

This step-by-step "promotion" is why calling a virtual function from within a base class constructor will always call the base class version of that function, never the derived one. At that moment in its lifetime, the object's dynamic type is the base type.

class Vehicle {
public:
    virtual void start() {}
    int weight;
};

class Car : public Vehicle {
public:
    void start() override {}
    int num_doors;
};

Conclusion

Today, we peeled back the abstraction of inheritance to see its physical representation in memory. This is the bedrock upon which the entire C++ object-oriented system is built.

Key Takeaways:

• Single inheritance is implemented by embedding a base class subobject within the derived class object's memory.
• In a non-polymorphic class, this subobject contains only the base class's data members.
• In a polymorphic class, the first element of the subobject is the hidden vptr, which points to the class's vtable.
• The layout is typically: vptr, followed by base class data, followed by derived class data, with padding inserted by the compiler for alignment.
• The vptr is set during construction, starting with the base class vtable and being overwritten by each successive derived class constructor.

We now understand the structure of a polymorphic object. In our next lesson, we will analyze that structure in action. We will trace a virtual function call through the vptr and vtable to see exactly how dynamic dispatch works at runtime and analyze its overhead compared to a regular function call.