C++ | 虚函数表内存布局
虚表指针
虚函数有个特点。存在虚函数的类会在类的数据成员中生成一个虚函数指针 vfptr，而vfptr 指向了一张表（简称，虚表）。正是由于虚函数的这个特性，C++的多态才有了发生的可能。
其中虚函数表由三部分组成，分别是 RTTI（运行时类型信息）、偏移及虚函数的入口地址。而虚表与类及类生成的对象有存在着以下两种关系：
- 类与虚表的关系：一个类只有一个虚表
- 对象与类的关系：所有对象共享一个虚表
如下图所示：对象通过一个 vfptr （虚表指针)共享虚表.
虚表指针在类中的布局
1、虚表指针 vfptr 在上，类成员变量 ma 在下（图左）
2、类成员变量 ma 在上，虚表指针 vfptr 在下（图右）
在类中，vfptr 的优先级最高，所以虚函数在类中的布局应该是上图左边的结构，其中vftpr指针指向虚表，在虚表的起始位置存放这虚表所属类的类型信息RTTI（运行时类型信息 Run-Time Type Identification）。可以通过 typeid(pb).name() 查看。
虚函数表在类中的布局
现有基类 Base、派生类 Deriver 为测试代码：
#include<iostream>
class Base //定义基类
{
public:
Base(int a) :ma(a) {}
virtual void Show() // 声明为虚函数
{
std::cout << "Base: ma = " << ma << std::endl;
}
protected:
int ma;
};
class Deriver : public Base //派生类
{
public:
Deriver(int b) :mb(b), Base(b) {}
void Show() // 没有声明为虚函数
{
std::cout << "Deriver: mb = " << mb << std::endl;
}
protected:
int mb;
};
1. 查看Base类的内存布局
在VS 2019开发者命令提示中输入:
cl 虚函数.cpp /d1reportSingleClassLayoutBase
其中，虚函数.cpp 为源文件的文件名， 最后的Base为要查看的类
/* Base类 内存布局 */
class Base size(8):
+---
0 | {vfptr}
4 | ma
+---
Base::$vftable@:
| &Base_meta //运行时类型信息 Run-Time Type Identification
| 0 //虚函数指针相对于整体作用域的偏移
0 | &Base::Show //虚函数入口地址，虚函数入口地址有一个或多个
2. 查看Deriver内存布局
输入：cl 虚函数.cpp /d1reportSingleClassLayoutDeriver
我们查寻到 Deriver的内存布局中类对象占据12个字节的空间。
/* Deriver类 内存布局 */
class Deriver size(12):
+---
0 | +--- (base class Base)
0 | | {vfptr}
4 | | ma
| +---
8 | mb
+---
Deriver::$vftable@:
| &Deriver_meta
| 0
0 | &Deriver::Show
发现：我们在源代码中并没有把 Deriver::Show() 声明为虚函数，但在Deriver的类内存布局中也存在 {vfptr} 指针。
这里不得不说虚函数的另一个特点了，“基类中同名同参的函数是虚函数，派生类中同名同参的函数也会变成虚函数”。意思是，在派生类中同名同参的函数即使没有 virtual 关键字声明也默认是虚函数，也会产生一张虚表。
那么派生类中的虚表结构又是什么样的呢？
根据上面提到的 vfptr 的优先级最大，并且 Deriver 是继承自 Base 类。因此，我门推测 Deriver 的内存布局应该是如下格式16字节布局才对，但显然不是这样。那么在派生类 Deriver 的内存布局中究竟进行了怎样的操作，才形成了12字节的内存布局呢？
注：以下结构为错误示范
/* 我们推测的Deriver类的内存布局 */
class Deriver size(16):
+---
0 | {vfptr} // Deriver::
4 | +--- (base class Base)
4 | | {vfptr} // Base::
8 | | ma
| +---
12 | mb
+---
解释这个原因之前我们先得了解派生类的虚表是怎样生成的？
在编译基类时，基类生成了一张虚表，在编译派生类时，又生成一张虚表。
我们在基类中添加一个Print() 函数，派生类中没有该函数。在上述假设成立的前提下，对应内存布局如下：
如果是这样，那么试想，在调用Print的时候，就需要查询两张虚表，从而找到 Base::Show() 对应的入口地址。这样做的确可行，但是整个调用的效率会变得非常差。
那么怎么来解决这个效率问题呢？
虚表合并
其实，在派生类的虚表生成好之后还有一个步骤，就是虚表的合并，具体演示如下：
将派生类中同名的虚函数覆盖到基类的虚表中，虚表合成之后，其中一个虚表指针已经没用了，不如也一并合并了。虚表指针合并的方式为向内层合并。因此，通过这一步虚表合并最终得到了Deriver 了的12字节内存布局。
那么有人就问了：为什么虚表指针合并的方式是向内合并，就不能向外合并吗?
要知道在继承中基类的指针是可以指向派生类对象，更加具体的说法是，基类的指针指向派生类对象中基类的起始部分。如果虚表指针向外层合并，那么对应的结构如下图所示，其中 Base* pb = new Deriver(10);
注：以下结构为错误示范
而正如我们问到的那样，如果虚表指针向外层合并的话，我们会发现无法通过虚表指针找到我们的虚表，因为在 Base:: 作用域中已经不存在虚表指针了。并且，当我们想要释放 new 出的堆区资源时，也不再是用 delete pb 而是 delete (Base*)((char*)pb - 4)，因为在申请空间时内存分配的程序往往在被分配出的内存块“头部”放上一些校验信息。释放时必须从此空间的头部开始释放，否则会报 “Expression: is_block_type_valid(header->block_use)”错误。而我们申请的内存空间头部是在 0x100 的位置，而不是 0x104 的位置。这样在我们实际操作中就会很麻烦。因此，选择向内层合并就不就有这种问题产生。
