Виртуальные таблицы: vptr/vtableVirtual tables: vptr/vtable

vtable (virtual table) — это статический массив указателей на функции, по одному указателю на каждую виртуальную функцию класса. Он генерируется компилятором один раз на класс (не на объект) и живёт в бинарнике как обычные данные только для чтения. vptr (virtual pointer) — скрытое поле, которое компилятор добавляет в начало каждого объекта полиморфного типа; оно указывает на vtable того класса, которым объект реально является.vtable (the virtual table) is a static array of function pointers, one per virtual function the class declares. The compiler generates it once per class (not per object), and it lives in the binary as ordinary read-only data. vptr (the virtual pointer) is a hidden field the compiler inserts at the start of every object of a polymorphic type; it points at the vtable of whatever class the object actually is.

В Itanium C++ ABI (GCC, Clang, все не-Windows платформы) vptr указывает не на самое начало массива указателей, а сразу на первую виртуальную функцию — служебные поля (смещение до вершины иерархии для множественного наследования и указатель на type_info для RTTI/dynamic_cast) лежат перед тем местом, куда указывает vptr, по отрицательным смещениям. MSVC ABI устроен немного иначе: RTTI-информация хранится не в самой vtable, а в отдельной Complete Object Locator структуре, на которую указывает ячейка перед vtable.In the Itanium C++ ABI (GCC, Clang, every non-Windows platform), the vptr doesn't point at the very start of the pointer array — it points straight at the first virtual function; the housekeeping fields (the offset to the top of the hierarchy, needed for multiple inheritance, and a pointer to type_info for RTTI/dynamic_cast) sit before where the vptr points, at negative offsets. The MSVC ABI is laid out slightly differently: RTTI information isn't stored in the vtable itself but in a separate Complete Object Locator structure, pointed to by a slot just before the vtable.

struct Shape {
    virtual double area() const = 0;
    virtual void draw() const {}
    virtual ~Shape() = default;
};
struct Circle : Shape {
    double r;
    double area() const override { return 3.14159 * r * r; }
    // draw() не переопределён — слот в vtable Circle указывает на Shape::draw// draw() isn't overridden — Circle's vtable slot for it points at Shape::draw
};

Компилятор присваивает каждой виртуальной функции класса стабильный индекс слота (по порядку объявления: area=0, draw=1, ~Shape=2). Этот индекс — контракт между базовым классом и всеми его наследниками: Circle обязан положить свою area в тот же слот 0. Если Circle не переопределяет draw, компилятор просто копирует в слот 1 указатель на Shape::draw — переопределение не обязательно для каждого слота.The compiler assigns each virtual function a stable slot index (by declaration order: area=0, draw=1, ~Shape=2). That index is the contract between the base class and every descendant: Circle must place its own area in that same slot 0. If Circle doesn't override draw, the compiler simply copies a pointer to Shape::draw into slot 1 — overriding isn't required for every slot.

Именно фиксированный индекс слота и есть весь механизм разрешения виртуального вызова: shape->area() компилируется в «прочитать vptr объекта, взять слот 0, вызвать по этому адресу» — компилятору вообще не нужно знать, что такое Circle, чтобы сгенерировать этот код в totalArea(). Отсюда и требование override в C++11 — оно не меняет ABI, а лишь просит компилятор проверить на этапе компиляции, что сигнатура действительно совпадает с какой-то виртуальной функцией базы.That fixed slot index is the entire mechanism behind resolving a virtual call: shape->area() compiles down to "read the object's vptr, grab slot 0, call through that address" — the compiler doesn't need to know anything about Circle to generate that code inside totalArea(). That's also why C++11's override exists — it doesn't change the ABI at all, it just asks the compiler to check at compile time that the signature genuinely matches some virtual function in a base.

Если класс наследует от нескольких полиморфных базовых классов, объект получает по одному vptr на каждую базу (кроме первой — она использует общий с производным классом vptr в начале объекта). Это прямое следствие того, что каждая база должна допускать корректный виртуальный вызов через указатель именно на неё.When a class inherits from several polymorphic base classes, the object gets one vptr per base (except the first one, which shares the vptr at the start of the object with the derived class). This is a direct consequence of the fact that each base must support a correct virtual call through a pointer to exactly that base.

struct Drawable { virtual void draw() const = 0; virtual ~Drawable() = default; };
struct Serializable { virtual std::string serialize() const = 0; virtual ~Serializable() = default; };

struct Widget : Drawable, Serializable {
    void draw() const override {}
    std::string serialize() const override { return ""; }
};
// sizeof(Widget) содержит 2 vptr: один для Drawable-части, один для Serializable-части// sizeof(Widget) holds 2 vptrs: one for the Drawable slice, one for the Serializable slice

Отсюда важное следствие: static_cast<Serializable*>(&w) — это не «просто перетолкование того же адреса», а реальная арифметика указателя (this-adjustment): компилятор прибавляет к адресу w смещение второго подобъекта. Это же смещение зашито в специальные thunk-функции — крошечные обёртки в vtable, которые перед прыжком к настоящей реализации корректируют this обратно на начало полного объекта Widget.This has an important consequence: static_cast<Serializable*>(&w) isn't "just reinterpreting the same address" — it's real pointer arithmetic (a this-adjustment): the compiler adds the second subobject's offset to w's address. That same offset is baked into special thunk functions — tiny wrapper stubs inside the vtable that adjust this back to the start of the full Widget object before jumping to the real implementation.

При виртуальном наследовании (см. страницу про наследование и ромбовидную проблему) смещение общего виртуального базового подобъекта не фиксировано — оно зависит от того, кто именно наследуется от класса дальше. Поэтому это смещение (vbase offset) хранится прямо в vtable, рядом с указателями на функции, и читается в рантайме при каждом обращении к полю виртуальной базы или при dynamic_cast к ней.Under virtual inheritance (see the inheritance page and the diamond problem), the offset of the shared virtual base subobject isn't fixed — it depends on whoever ends up inheriting from the class further down. So that offset (the vbase offset) is stored right in the vtable, alongside the function pointers, and read at runtime on every access to a virtual base's field or every dynamic_cast to it.

Это именно то, что делает виртуальное наследование измеримо дороже обычного: не просто «ещё один указатель», а лишнее чтение из памяти на каждое обращение к данным виртуальной базы, потому что компилятор физически не может подставить константное смещение во время компиляции промежуточного класса.This is precisely what makes virtual inheritance measurably more expensive than ordinary inheritance: not just "one more pointer," but an extra memory read on every access to the virtual base's data, because the compiler is physically unable to bake in a constant offset while compiling the intermediate class.

vtable — это статические данные только для чтения, известные полностью на этапе компиляции (адреса функций разрешает линковщик). Поэтому она попадает в ту же секцию, что и другие константы: .rdata в PE (Windows) или .rodata в ELF (Linux) — подробный разбор секций на странице про PE-файл.The vtable is static, read-only data, fully known at compile time (the linker resolves the function addresses). So it lands in the same section as other constants: .rdata in PE (Windows) or .rodata in ELF (Linux) — see the PE file page for the full section breakdown.

Важная деталь про то, что vptr — не константа: сама vtable статична и лежит в файле, но значение vptr (адрес этой vtable) — это указатель на область памяти, которая из-за ASLR (см. страницу про PE) на каждом запуске процесса разная. Поэтому запись vptr в поле объекта происходит не «сама собой» — за неё явно отвечает код конструктора, сгенерированный компилятором: каждый конструктор класса с виртуальными функциями начинается с присваивания vptr, прежде чем выполнится тело, написанное программистом.One subtlety about vptr not being a constant: the vtable itself is static and lives in the file, but the vptr's value (that vtable's address) is a pointer into memory that, because of ASLR (see the PE page), differs on every process launch. So writing the vptr into an object's field doesn't happen "automatically" — it's explicitly handled by compiler-generated constructor code: every constructor of a class with virtual functions begins by assigning the vptr, before the programmer-written body runs.

Это прямое объяснение, почему виртуальный вызов из конструктора базы не виртуален (см. грабли на странице про полиморфизм): к моменту выполнения тела конструктора Shape vptr объекта уже установлен конструктором Shape на vtable именно Shape, а перезапишет его на vtable Circle только конструктор Circle, который выполнится позже.This directly explains why a virtual call from a base constructor isn't virtual (see the gotcha on the polymorphism page): by the time Shape's constructor body runs, the object's vptr has already been set by Shape's own constructor to Shape's vtable — it only gets overwritten with Circle's vtable by Circle's constructor, which runs afterward.

• Itanium C++ ABI — Virtual Table Layout
• cppreference — RTTI
• Shahar Mike — Vtables: how C++ implements polymorphism (article series)