Нет таблицы виртуальных функций для абстрактного класса?

Question

Я изучаю таблицы виртуальных функций и их представление путем анализа двоичного файла простой программы, написанной на Visual C ++ (с некоторыми оптимизациями).

Несколько дней назад я задал этот вопрос , когда застрял в содержимом таблицы виртуальных методов с идентичным сворачиванием COMDAT вкл.

Теперь я застрял в другом: когда я анализирую класс, мне нужно найти его таблицу виртуальных методов. Я могу сделать это, найдя либо RTTITypeDescriptor, либо _s_RTTIClassHierarchyDescriptor, найдя перекрестную ссылку на него, что должно привести меня к _RTTICompleteObjectLocator. Когда я нахожу перекрестную ссылку на Полный локатор объекта, она записывается непосредственно перед VMT (в основном -1-я запись VMT).

Этот подход работает на некоторых классах (их имена начинаются с C в моей программе). Затем есть классы, которые в начале именуются I, и я могу связать их с другими классами, начинающимися с C - например, есть класс CClass, и он наследуется от IClass. Эти I -классы, вероятно, служат интерфейсами для C -классов и, следовательно, они, вероятно, содержат только абстрактные методы.

Путем поиска перекрестной ссылки на дескриптор типа или дескриптор иерархии классов любого из I -классов я ничего не могу найти - нет полного локатора объектов, который привел бы меня к VMT класса (это должно быть полные ссылки на pure_virtual вызовите, если я прав насчет всех абстрактных методов в I -классах и если я правильно понимаю, как выглядит VMT абстрактного класса).

Почему у I -классов нет VMT? Оптимизировал ли его компилятор, потому что он был бы полон ссылок на вызов pure_virtual и управлял им по-другому?

Answer 1

Эти абстрактные классы "интерфейсов", вероятно, не нуждаются в написании пользователем кода ни в одном из своих конструкторов и деструкторов (они либо имеют пустое тело и не имеют ctor-init-list, либо просто никогда не определяются пользователем); давайте назовем эти чистые классы интерфейса .

[Чистый интерфейсный класс: концепция, связанная, но не идентичная Java-интерфейсам, которые (были?) Определены как имеющие нулевой код реализации в любой функции-члене. Но будьте осторожны с аналогиями, поскольку семантика наследования Java-интерфейсов отличается от семантики наследования абстрактных классов C ++.]

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