Множественное и виртуальное наследование: layout объекта в памятиMultiple & virtual inheritance: object layout in memory

Прежде чем усложнять, зафиксируем базовый случай. При одиночном наследовании подобъект базового класса просто кладётся в начало объекта производного класса — их адреса совпадают.Before adding complexity, let's fix the baseline case. Under single inheritance, the base class's subobject is simply placed at the start of the derived class's object — their addresses coincide.

struct A { int a; };            // sizeof(A) == 4// sizeof(A) == 4
struct B : A { int b; };       // sizeof(B) == 8// sizeof(B) == 8

Именно поэтому static_cast<A*>(bPtr) при одиночном наследовании — это буквально no-op на уровне машинного кода: значение указателя не меняется, меняется только его тип для компилятора.This is exactly why static_cast<A*>(bPtr) under single inheritance is literally a no-op at the machine-code level: the pointer's value doesn't change, only its type does, for the compiler's bookkeeping.

struct Base1 { int x; };
struct Base2 { int y; };
struct Derived : Base1, Base2 { int z; };   // sizeof(Derived) == 12// sizeof(Derived) == 12

Здесь уже видна первая практическая деталь: static_cast<Base2*>(derivedPtr) — это НЕ no-op. Компилятор обязан прибавить к адресу смещение Base2 (здесь — 4 байта), иначе указатель будет указывать на Base1::x, а не на Base2::y. Это смещение известно на этапе компиляции (нет виртуального наследования — нет неопределённости), поэтому подставляется прямо в код как константа.Here the first practical detail already shows up: static_cast<Base2*>(derivedPtr) is NOT a no-op. The compiler must add Base2's offset (4 bytes here) to the address, otherwise the pointer would point at Base1::x instead of Base2::y. That offset is known at compile time (no virtual inheritance means no uncertainty), so it's baked into the code as a constant.

struct A  { int a; };            // sizeof(A)  == 4// sizeof(A)  == 4
struct B1 : A { int b1; };      // sizeof(B1) == 8// sizeof(B1) == 8
struct B2 : A { int b2; };      // sizeof(B2) == 8// sizeof(B2) == 8
struct D  : B1, B2 { int d; };   // sizeof(D)  == 20 — два A целиком!// sizeof(D)  == 20 — two whole A's!

Ошибка компиляции «d.a неоднозначен» — не искусственное ограничение языка, а прямое следствие layout: по смещению 0 лежит один int, по смещению 8 — другой, оба одинаково валидны, и компилятор физически не может «угадать», какой из двух байтовых участков памяти имелся в виду.The "d.a is ambiguous" compile error isn't an artificial language restriction — it's a direct consequence of the layout: one int sits at offset 0, another at offset 8, both equally valid, and the compiler physically cannot "guess" which of the two memory regions was meant.

Когда B1 и B2 наследуют от A виртуально, компилятор физически перестраивает объект: единственная копия A перемещается в конец объекта D (после всех невиртуальных частей), а на её место, в начале подобъектов B1 и B2, встают скрытые указатели на таблицу смещений виртуальной базы (vbase offset, хранится в структуре, похожей на vtable, — см. страницу про виртуальные таблицы).When B1 and B2 inherit from A virtually, the compiler physically restructures the object: the single copy of A moves to the end of D's object (after every non-virtual part), and in its place, at the start of the B1 and B2 subobjects, hidden pointers to the virtual base offset table appear (stored in a vtable-like structure — see the virtual tables page).

struct A  { int a; };
struct B1 : virtual A { int b1; };
struct B2 : virtual A { int b2; };
struct D  : B1, B2 { int d; };
// на x86-64, GCC/Clang: sizeof(D) == 32 (не 20!) — но A теперь только одна копия// on x86-64, GCC/Clang: sizeof(D) == 32 (not 20!) — but there's only one A now

Обратите внимание, что размер объекта вырос (32 байта против 20 без virtual) — экономия на дублировании A (4 байта) съедена двумя новыми vbase-указателями (по 8 байт каждый на x86-64). Виртуальное наследование выгодно семантически (единый общий подобъект, никакой неоднозначности), но не по чистому размеру объекта — реальная выгода в том, что d.a теперь однозначен и логически корректен, а не в экономии памяти.Notice the object's size actually grew (32 bytes vs. 20 without virtual) — the savings from not duplicating A (4 bytes) are eaten up by two new vbase pointers (8 bytes each on x86-64). Virtual inheritance pays off semantically (one shared subobject, no ambiguity), not in raw object size — the real win is that d.a is now unambiguous and logically correct, not memory saved.

Доступ к d.a теперь компилируется примерно так: прочитать vbase-указатель из B1-части (или из vtable объекта — конкретный механизм зависит от компилятора), получить смещение виртуальной базы, прибавить его к адресу объекта — то самое «одно дополнительное разыменование», упомянутое на странице про наследование, здесь видно буквально как одна лишняя инструкция чтения из памяти на пути к полю a.Accessing d.a now compiles roughly to: read the vbase pointer from the B1 portion (or from the object's vtable — the exact mechanism is compiler-dependent), fetch the virtual base's offset, add it to the object's address — that "one extra dereference" mentioned on the inheritance page shows up here literally as one extra memory-read instruction on the way to field a.

• Itanium C++ ABI — Class Layout
• Itanium C++ ABI — Virtual Table Layout