To my CSDN

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 的位置。这样在我们实际操作中就会很麻烦。因此,选择向内层合并就不就有这种问题产生。

因此,虚表指针选择向内层合并。
posted @ 2020-02-19 23:42  我叫RT  阅读(1023)  评论(0编辑  收藏  举报