Objects in Memory — The Compiler's View

To a compiler, an object is simply a contiguous block of memory containing its data members (fields) in declaration order. Consider:

1class Point {
2    int x;    // offset 0
3    int y;    // offset 4
4};            // total size: 8 bytes
5
6class ColorPoint : public Point {
7    int color; // offset 8
8};             // total size: 12 bytes

The compiler assigns each field a fixed byte offset from the start of the object. For Point, x is at offset 0 and y at offset 4. For ColorPoint, x remains at offset 0, y at 4, and the new field color at offset 8.

When the code accesses obj.color, the compiler generates a memory access at base_address + 8 — a compile-time offset with zero runtime overhead. This is fundamentally identical to how struct field access works in C.

The hidden cost: the this pointer. Every non-static member call obj.method(arg) is rewritten by the compiler as:

Class::method(&obj, arg)

The address of obj is passed as a hidden first parameter called this. Inside the method, every unqualified field access x becomes this->x, which the compiler resolves to this + offset_of_x.

Compiling Single Inheritance

Single inheritance is the simplest case to compile. The subclass layout is a strict extension of the superclass layout:

1class Animal {
2    int age;           // offset 0
3    void speak();
4};
5
6class Dog : public Animal {
7    int breedCode;     // offset 4 (after age)
8    void fetch();
9};

Key compilation rules for single inheritance:

1. Field layout: The superclass fields come first, then the subclass fields. This means a Dog* and an Animal* pointing to the same object share the same base address — no pointer adjustment is needed during an upcast.

2. Inherited methods: Methods defined in Animal can operate on a Dog object because Dog's layout starts with all Animal fields at their expected offsets. The inherited speak() method accesses this + 0 for age, and this works correctly whether this points to an Animal or a Dog.

3. Method calls for non-virtual methods are resolved at compile time through name mangling — identical to regular function calls:

obj.speak()  →  Animal::speak(&obj)

4. Constructor compilation: The compiler generates a constructor that first calls the superclass constructor (to initialize inherited fields), then initializes its own fields. Destructors run in reverse order.

Polymorphism and the Virtual Function Table (vtable)

When a method is declared virtual in C++ (or methods are virtual by default in Java), the compiler cannot simply call it by name — the correct method depends on the runtime type of the object, not the static type of the pointer.

Consider:

1class Animal {
2    int age;
3    virtual void speak();       // Virtual
4};
5
6class Dog : public Animal {
7    int breedCode;
8    void speak() override;      // Overrides Animal::speak()
9};
10
11void makeItSpeak(Animal* a) {
12    a->speak();   // Compiler: should this call Animal::speak or Dog::speak?
13}                 // Answer: depends on what a actually points to — RUNTIME decision!

The compilation challenge: In makeItSpeak, the static type is Animal* but the dynamic type could be Dog, Cat, or any subclass. The compiler must emit code that selects the right method at runtime.

The solution: virtual function tables (vtables).

For every class with at least one virtual method, the compiler creates a vtable — a static array of function pointers, one per virtual method, shared by all instances of that class. Additionally, every object of such a class gets a hidden field at offset 0: the vptr (vtable pointer), which points to its class's vtable.

Note: If the vptr takes 8 bytes (64-bit system), all field offsets shift by 8. age moves from offset 0 to offset 8, etc.

Virtual Destructors — A Critical Design Rule

In C++, when you delete a derived object through a base pointer, the destructor must be virtual — or only the base destructor runs:

1Animal* a = new Dog();
2delete a;    // If ~Animal() is NOT virtual: only ~Animal() runs → Dog::breedCode LEAKED
3             // If ~Animal() IS virtual: vtable dispatch → Dog::~Dog() → Animal::~Animal()

How the compiler handles virtual destruction:

1. The vtable entry for the destructor points to the most-derived destructor
2. The most-derived destructor runs, then automatically chains to the base destructor
3. Each destructor resets the vptr to its own class vtable before returning (prevents calling a method on a half-destroyed object)

Exam rule of thumb: If a class has any virtual method, its destructor should be virtual. This ensures correct cleanup during polymorphic deletion.