виртуальная таблица и схема хранения _vptr

Первое, что нужно иметь в виду, это отказ от ответственности: на самом деле ничего из этого не гарантируется стандартом. Стандарт говорит о том, как должен выглядеть код и как он должен работать, но на самом деле не указывает, каким именно образом компилятор должен это делать.

Тем не менее, практически все компиляторы C ++ работают в этом отношении одинаково.

Итак, начнем с не виртуальных функций. Они бывают двух классов: статические и нестатические.

Более простыми из них являются статические функции-члены. Статическая функция-член почти как глобальная функция, friend класса, за исключением того, что ему также нужно имя класса в качестве префикса к имени функции.

Нестатические функции-члены немного сложнее. Это все еще обычные функции, которые вызываются напрямую, но им передается скрытый указатель на экземпляр объекта, для которого они были вызваны. Внутри функции вы можете использовать ключевое слово this ссылаться на эти данные экземпляра. Итак, когда вы звоните что-то вроде a.func(b);, сгенерированный код очень похож на код, который вы получите для func(a, b);

Теперь давайте рассмотрим виртуальные функции. Вот где мы попадаем в vtables и vtable указатели. У нас достаточно косвенных указаний на то, что, вероятно, лучше нарисовать несколько диаграмм, чтобы увидеть, как все это изложено. Вот довольно простой случай: один экземпляр одного класса с двумя виртуальными функциями:

Итак, объект содержит свои данные и указатель на виртуальную таблицу. В таблице содержится указатель на каждую виртуальную функцию, определенную этим классом. Однако может быть не сразу понятно, почему нам нужно так много косвенных указаний. Чтобы понять это, давайте рассмотрим следующий (хотя бы немного) более сложный случай: два экземпляра этого класса:

Обратите внимание, что каждый экземпляр класса имеет свои собственные данные, но они оба используют один и тот же vtable и один и тот же код — и если бы у нас было больше экземпляров, они все равно разделяли бы один vtable среди всех экземпляров одного и того же класса.

Теперь давайте рассмотрим деривацию / наследование. В качестве примера, давайте переименуем наш существующий класс в «Base» и добавим производный класс. Поскольку я чувствую себя творчески, я назову это «Производный». Как и выше, базовый класс определяет две виртуальные функции. Производный класс переопределяет один (но не другой) из них:

Конечно, мы можем объединить два, имея несколько экземпляров каждого из базового и / или производного класса:

Теперь давайте углубимся в это немного подробнее. Интересно, что при деривации мы можем передать указатель / ссылку на объект производного класса в функцию, написанную для получения указателя / ссылки на базовый класс, и она все еще работает, но если вы вызываете виртуальную функцию, вы получаете версию для фактического класса, а не базовый класс. Итак, как это работает? Как мы можем обращаться с экземпляром производного класса, как если бы он был экземпляром базового класса, и при этом работать? Для этого у каждого производного объекта есть «подобъект базового класса». Например, давайте рассмотрим код следующим образом:

struct simple_base {
int a;
};

struct simple_derived : public simple_base {
int b;
};

В этом случае, когда вы создаете экземпляр simple_derived, вы получите объект, содержащий два ints: a а также b, a (часть базового класса) находится в начале объекта в памяти, и b (производная часть класса) следует за этим. Таким образом, если вы передаете адрес объекта функции, ожидающей экземпляра базового класса, он использует те части, которые существуют в базовом классе, которые компилятор размещает с теми же смещениями в объекте, что и они. находиться в объекте базового класса, поэтому функция может манипулировать ими, даже не зная, что имеет дело с объектом производного класса. Аналогично, если вы вызываете виртуальную функцию, все, что ей нужно знать, это расположение указателя vtable. Насколько это волнует, что-то вроде Base::func1 в основном просто означает, что он следует за указателем vtable, а затем использует указатель на функцию с некоторым заданным смещением оттуда (например, четвертый указатель на функцию).

По крайней мере, сейчас я собираюсь игнорировать множественное наследование. Это добавляет немного сложности к картине (особенно когда задействовано виртуальное наследование), и вы вообще об этом не упомянули, поэтому я сомневаюсь, что вас это действительно волнует.

Что касается доступа к чему-либо из этого или использования каким-либо иным способом, кроме простого вызова виртуальных функций: вы можете придумать что-то для определенного компилятора — но не ожидайте, что он вообще будет переносимым. Хотя такие вещи, как отладчики, часто должны смотреть на такие вещи, используемый код, как правило, довольно хрупок и зависит от компилятора.