Поскольку рассматривается только функциональность, специфичная для виртуальной функции, в традиционном подходе к производному классу реализации vtable потребуется отдельная версия vtable тогда и только тогда, когда , этот производный класс переопределяет хотя бы один виртуальный функция. В вашем примере Derived
переопределяет виртуальную функцию print
. Поскольку Derived
имеет свою собственную версию print
, соответствующая запись в Derived
vtable отличается от записи в Base
vtable. Это обычно требует отдельного vtable для Derived
.
Если бы Derived
вообще ничего не переопределял, формально это был бы отдельный полиморфный класс, но для правильной работы его виртуальных функций мы могли бы просто повторно использовать Base
vtable для Derived
. , Таким образом, технически не было бы необходимости в отдельной vtable для Derived
.
Однако в практических реализациях структура данных, которую мы обычно называем «vtable», часто также содержит некоторую дополнительную информацию, специфичную для класса. Эта дополнительная информация настолько специфична для класса, что большую часть времени становится невозможным делить таблицы между различными классами в иерархии, даже если они используют один и тот же набор виртуальных функций. Например, в некоторых реализациях указатель vtable, хранящийся в каждом полиморфном объекте, указывает на структуру данных, которая также хранит так называемую «информацию RTTI» о классе. По этой причине в большинстве (если не во всех) практических реализациях каждый полиморфный класс получает свой собственный vtable, даже если указатели виртуальных функций, хранящиеся в этих таблицах, совпадают.