C++通过虚拟机制支持动态绑定。但据我所知，虚拟机制是编译器的实现细节，标准只规定了特定情况下应该发生的行为。大多数编译器都通过虚拟表和虚拟指针来实现虚拟机制。这不涉及虚拟指针和表的实现细节。我的问题是：
sizeof将是该编译器上指针（在this中的vptr）的大小。因此，鉴于虚拟指针和TBL机制本身是编译器的实现，我上述说法是否总是正确的？并非对象中的vtable指针始终是最有效的。我的另一种语言的编译器曾经出于类似原因使用对象内指针，但现在不再这样做：它使用单独的数据结构将对象地址映射到所需的元数据，在我的系统中，这实际上是用于垃圾收集器的形状信息。
对于单个简单对象，该实现会多花费一些存储空间，但对于具有许多基类的复杂对象来说更加高效，而且对于数组来说也要高效得多，因为所有对象在数组中只需要一个映射表条目。特别是在我的实现中，可以在对象内部的任何点给定指针时找到元数据。
实际的查找非常快速，存储要求非常低，因为我使用了全球最佳的数据结构：Judy 数组。
我还不知道有哪个 C++ 编译器使用除 vtable 指针之外的其他方式，但这并不是唯一的方式。实际上，由于具有基类的类的初始化语义使任何实现变得混乱，因为完整类型必须随着对象的构建而来回移动。由于这些语义，复杂的 mixin 对象会导致生成大量的 vtable，大型对象和缓慢的对象初始化。这可能不仅是 vtable 技术的后果，还因为需要完全遵循子对象的运行时类型始终正确的要求。实际上，在构建期间没有必要这样做，因为构造函数不是方法，不能明智地使用虚拟分派：但在析构期间这一点并不那么清楚，因为析构函数是真正的方法。
this并相应转发来解决。 - j_random_hacker我认为现代编译器除了vptr/vtable之外没有其他的方法。实际上，很难想出其他不仅仅是简单低效的方法。
然而，在这种方法中仍然有相当大的设计折衷空间。也许特别是关于虚继承的处理方式。因此，将其实现定义是有意义的。
如果您对此类内容感兴趣，我强烈建议阅读《C++对象模型内幕》。
sizeof class 取决于编译器。如果您想要可移植的代码，请不要做任何假设。
new在固定且不重叠的地址范围内分配不同类型的对象。然后，可以使用右移操作快速推断对象的类型，并使用结果索引vtable表，从而每个对象可以节省1个vtable指针。乍一看，这个方案可能会遇到堆栈分配对象的问题，但是可以进行清理处理：
(地址范围，类型) 对，并在销毁时删除该记录。this 指针，扫描数组以查找相应地址处对象的类型（vptr），并调用指向的虚表中的相应方法。（即第42个 thunk 将调用虚表中的第42个方法——如果任何类中使用的最多的虚函数是 n，则至少需要 n 个 thunk。）这种方案显然会产生非常大的开销（至少需要O(log n)的查找时间）用于基于堆栈的对象进行虚方法调用。在不存在基于堆栈对象的数组或组合（包含在另一个对象中）时，可以使用更简单和更快速的方法，在对象之前将vptr放置在堆栈上（请注意，它不被视为对象的一部分，并且不会按照sizeof所测量的大小进行贡献）。在这种情况下，thunks只需从this减去sizeof (vptr)即可找到正确的vptr并像以前一样转发。
据我所知，Eiffel使用了一种不同的方法，所有对方法的覆盖最终都会合并在同一个地址中，并编译一个序言来检查对象类型（因此每个对象必须有一个类型ID，但它不是指向VMT的指针）。当然，这对于C++来说需要在链接时创建最终函数。
然而，我不知道任何使用这种方法的C++编译器。
C++/CLI偏离了这两种假设。如果您定义一个ref class，它根本不会被编译成机器代码；相反，编译器将其编译为.NET托管代码。在中间语言中，类是一种内置的特性，并且虚方法集合是在元数据中定义的，而不是在方法表中。
实现对象布局和调度的具体策略取决于VM。在Mono中，只包含一个虚方法的对象在MonoObject结构中需要两个指针来存储；第二个用于对象的同步。由于这是实现定义的，而且也没什么用处，所以C++/CLI不支持ref classes的sizeof操作。
我从未听说过或见过任何使用其他实现的编译器。虚函数表之所以如此流行，是因为它不仅是最高效的实现方式，而且是最容易设计和最明显的实现方式。
在几乎任何你想使用的编译器上，这几乎肯定是正确的。然而，并非总是如此——即使情况几乎总是如此，你也不能依赖它。你喜欢的编译器也可能改变它的对齐方式，增加它的大小，玩个乐子，但不告诉你。据我记忆，它还可以插入任何调试信息和任何它喜欢的内容。
首先，提到了Borland对C++的专有扩展——动态分派虚拟表（DDVT），你可以在一个名为DDISPATC.ZIP的文件中阅读相关内容。Borland Pascal同时具备虚拟方法和动态方法，而Delphi还引入了一种“消息”语法，类似于动态方法，但用于处理消息。目前我不确定Borland C++是否具有同样的功能。Pascal和Delphi都没有多重继承，因此Borland C++ DDVT可能与Pascal或Delphi不同。
其次，在1990年代及早期，有人试验不同的对象模型，Borland并不是最先进的。我个人认为关闭IBM SOMobjects对我们所有人造成了损害。在关闭SOM之前，有过使用Direct-to-SOM C ++编译器进行实验。因此，SOM代替了C ++调用方法的方式。它在许多方面类似于C ++ vtable，但也有几个例外。首先，为了防止脆弱的基类问题，程序不使用vtable内部的偏移量，因为它们不知道这个偏移量。如果基类引入新方法，则它可能会改变。而是调用在运行时创建的具有此知识的thunk，该thunk具有其汇编代码中的这些知识。还有一个区别。在C ++中，当使用多重继承时，对象可以包含多个VMT IIRC。与C ++相比，每个SOM对象仅有一个VMT，因此分派代码应与“call dword ptr [VMT + offset]”不同。这里有一份与SOM相关的文档，SOM中发布到发布的二进制兼容性。您可以在其中找到我所知道的另外一些项目，例如Delta/C++和Sun OBI的比较。它们解决了SOM解决的问题子集，并通过这样做也略微调整了调用代码。
我最近发现Visual Age C++ v3.5 for Windows编译器片段足以让事情运行并实际接触它。大多数用户不太可能获取OS/2 VM来使用DTS C++，但拥有Windows编译器完全是另一回事。 VAC v3.5是第一个也是最后一个支持Direct-to-SOM C++功能的版本。VAC v3.6.5和v4.0不适合。
Local anInfo->x = 5
Local anInfo->_get_x() = 5
Local anInfo->y = A
Local anInfo->_get_y() = B
{An instance of class info at address 0092E318
}
vptr，将整个函数表存储在每个对象中。在某些非常特定的情况下，这可能很有价值，因为在虚拟函数调用期间，这种方法可以节省额外的内存间接引用。在驱动程序开发中，这可能是至关重要的：这种间接引用可能导致对分页内存的访问。 - valdo