你好，我是雨乐！

在上一篇文章C++：从技术角度聊聊RTTI中聊到了虚函数表，以及内部的部分布局。对于c++对象的内存布局一直处于似懂非懂似清非清的阶段，没有去深入了解过，所以借着这个机会，一并分析下。

多态在我们日常工作中用的算是比较多的一种特性，业界编译器往往是通过虚函数来实现运行时多态，而涉及到虚函数的内存布局往往是最麻烦且容易出错的，本文从一个简单的例子入手，借助gcc和gdb，对内存布局进行分析，相信看完本文，对内存布局会有一个清晰的认识。

多态

众所周知，C++为了实现多态(运行期)，引进了虚函数(语言标准支持的，其它实现方式不在本文讨论范围内)，而虚函数的实现机制则是通过虚函数表。这块的知识点不算多，却非常重要，因此往往是面试必问之一，当然，对于我也不例外。作为候选人，如果没有把运行期多态的实现机制讲清楚，那么此次面试基本凉凉~~

仍然以上一篇文章的代码为例，代码如下：

class Base1 {
public:
  virtual void fun() {}
  virtual void f1() {}
  int a;
};

class Derived : public Base {
public:
  void fun() {}  // override Base::fun()
  int b;
};

void call(Base *b) {
  b->fun();
}

在上述示例call()函数中，当b指向Base对象时候，call()函数实际调用的是Base::fun()；当b指向Derived对象时候，call()函数实际调用的是Derived::fun()。之所以可以这么实现，是因为虚函数后面的实现机制--虚函数表(后面称为Vtable):

• • 对于每个类(存在虚函数，后面文中不再赘述)，存在一个表，表的内容包含虚函数等(不仅仅是虚函数，在后面会有细讲)，类似于如下这种：

• vtable_Base = {&Base::func, ...}
  vtable_Derived = {&Derived::func, ...}

• • 在创建类对象时候，对象最前部会有一个指针(称之为vptr)，指向给类虚函数表的对应位置。PS:(需要注意的是并不是指向Vtable的头，这块一定要注意)

那么，call()函数在运行的时候，因为不知道其参数b所指向具体类型是什么，所以只能通过其它方式进行调用。在前面的内容中，有提到过每个对象会有一个指针指向其类的虚函数表，那么就可以通过该虚函数表进行相应的调用。因此，call()函数中的b->fun()就类似于如下：

((Vtable*)b)[0]()

在现在编译器对多态的实现中，原理与上述差不多，只是更为复杂。比如在在虚函数指针的索引(如上述例子中的index 0)，这个index是根据函数的声明顺序而来，如果在Derived中再新增一个virtual函数fun2()，那么其在虚函数表中的index就是1。

实现

本节中以一个多继承作为示例，代码如下：

class Base1 {
public:
  void f0() {}
  virtual void f1() {}
  int a;
};

class Base2 {
public:
  virtual void f2() {}
  int b;
};

class Derived : public Base1, public Base2 {
public:
  void d() {}
  void f2() {}  // override Base2::f1()
  int c;
};

int main() {
  Base2 *b2 = new Base2;
  Derived *d = new Derived;
}

后面的内容将分别从基类和派生类的角度进行分析。

基类

首先，我们通过g++的命令-fdump-class-hierarchy进行编译，以便在布局上有一个宏观的认识，然后通过gdb进行更加详细的分析。

Base2内存布局如下：

Vtable for Base2
Base2::_ZTV5Base2: 3u entries
0     (int (*)(...))0
8     (int (*)(...))(& _ZTI5Base2)
16    (int (*)(...))Base2::f2

Class Base2
   size=16 align=8
   base size=12 base align=8
Base2 (0x0x7ff572e6b600) 0
    vptr=((& Base2::_ZTV5Base2) + 16u)

在上述代码中，Base2的Vtable名为 _ZTV5Base2 ，经过c++filt处理之后，发现其为vtable for Base2。之所以是这种是因为被编译器进行了mangled。其中，TV代表Table for Virtual，后面的数字5是类名的字符数，Base2则是类名。

维基百科以g++3.4.6为示例，示例中之处Vtable应该只包含指向Base2::f2 的指针，但在我的本地环境(g++5.4.0，布局如上述)中，B2::f2为第三行：首先是offset，其值为0；然后包含一个指向名为_ZTI5Base2的结构的指针（这个在上节RTTI一文中有讲，在本文后面也会涉及）；最后是函数指针B2::f2。

g++ 3.4.6 from GCC produces the following 32-bit memory layout for the object b2:[nb 1]

b2:
  +0: pointer to virtual method table of Base2
  +4: value of b

virtual method table of B2:
  +0: Base2::f2()   

继续看Class Base2部分，我们注意到有一句vptr=((& Base2::_ZTV5Base2) + 16u)，通过这句可以知道，Base2类中其虚函数指针vptr指向其虚函数表的首位+16处。

在下面的内容中，将通过gdb来分析其内存布局。

(gdb) disas
Dump of assembler code for function main:
   0x00000000004006f8 <+0>: push   %rbp
   0x00000000004006f9 <+1>: mov    %rsp,%rbp
   0x00000000004006fc <+4>: push   %rbx
   0x00000000004006fd <+5>: sub    $0x18,%rsp
=> 0x0000000000400701 <+9>: mov    $0x10,%edi
   0x0000000000400706 <+14>: callq  0x400578 <_Znwm@plt>
   0x000000000040070b <+19>: mov    %rax,%rbx
   0x000000000040070e <+22>: mov    %rbx,%rdi
   0x0000000000400711 <+25>: callq  0x40076a <_ZN5Base2C2Ev>
   0x0000000000400716 <+30>: mov    %rbx,-0x18(%rbp)
   0x000000000040071a <+34>: mov    $0x20,%edi
   0x000000000040071f <+39>: callq  0x400578 <_Znwm@plt>
   0x0000000000400724 <+44>: mov    %rax,%rbx
   0x0000000000400727 <+47>: mov    %rbx,%rdi
   0x000000000040072a <+50>: callq  0x40079a <_ZN7DerivedC2Ev>
   0x000000000040072f <+55>: mov    %rbx,-0x20(%rbp)
   0x0000000000400733 <+59>: mov    $0x0,%eax
   0x0000000000400738 <+64>: add    $0x18,%rsp
   0x000000000040073c <+68>: pop    %rbx
   0x000000000040073d <+69>: pop    %rbp
   0x000000000040073e <+70>: retq
End of assembler dump.
(gdb) b *0x0000000000400716
Breakpoint 2 at 0x400716: file abc.cc, line 22.
(gdb) c
Continuing.

Breakpoint 2, 0x0000000000400716 in main () at abc.cc:22
22   Base2 *b2 = new Base2;
(gdb) disas
Dump of assembler code for function main:
   0x00000000004006f8 <+0>: push   %rbp
   0x00000000004006f9 <+1>: mov    %rsp,%rbp
   0x00000000004006fc <+4>: push   %rbx
   0x00000000004006fd <+5>: sub    $0x18,%rsp
   0x0000000000400701 <+9>: mov    $0x10,%edi
   0x0000000000400706 <+14>: callq  0x400578 <_Znwm@plt>
   0x000000000040070b <+19>: mov    %rax,%rbx
   0x000000000040070e <+22>: mov    %rbx,%rdi
   0x0000000000400711 <+25>: callq  0x40076a <_ZN5Base2C2Ev>
=> 0x0000000000400716 <+30>: mov    %rbx,-0x18(%rbp)
   0x000000000040071a <+34>: mov    $0x20,%edi
   0x000000000040071f <+39>: callq  0x400578 <_Znwm@plt>
   0x0000000000400724 <+44>: mov    %rax,%rbx
   0x0000000000400727 <+47>: mov    %rbx,%rdi
   0x000000000040072a <+50>: callq  0x40079a <_ZN7DerivedC2Ev>
   0x000000000040072f <+55>: mov    %rbx,-0x20(%rbp)
   0x0000000000400733 <+59>: mov    $0x0,%eax
   0x0000000000400738 <+64>: add    $0x18,%rsp
   0x000000000040073c <+68>: pop    %rbx
   0x000000000040073d <+69>: pop    %rbp
   0x000000000040073e <+70>: retq
End of assembler dump.

在上述汇编中<+14>处，调用了operator new进行内存分配，然后将地址放于寄存器rax中，在<+25>处调用Base2构造函数，继续分析：

(gdb) p/x $rax
$2 = 0x612c20
(gdb) x/2xg 0x612c20
0x612c20: 0x0000000000400918 0x0000000000000000
(gdb) p &(((Base2*)0)->b)
$3 = (int *) 0x8

首先通过p/x $rax获取b2的地址0x612c20，然后通过x/4xg 0x612c20打印内存地址，地址信息包含存储的属性；接着通过p &(((Base2*)0)->b)来获取变量b的布局，其值为0x8，因此可以说明变量b在类Base2的第八字节处，即vptr之后，那么class base2的结构布局如下：

在上述x/2xg 0x612c20的输出中，有个地址0x0000000000400918,其指向Base2类的虚函数表，这个可以通过如下方式进行验证：

(gdb) p *((Base2*)0x612c20)
$6 = {_vptr.Base2 = 0x400918, b = 0}

但是需要注意的是，其并不是指向虚函数表的首位，而是指向Vtable + 0x10处，下面是类Base2虚函数表的内容：

(gdb) x/4xg 0x0000000000400918-0x10
0x400908 <_ZTV5Base2>: 0x0000000000000000 0x0000000000400980
0x400918 <_ZTV5Base2+16>: 0x000000000040074c 0x0000000000000000
(gdb) x/2i 0x000000000040074c
0x40074c <_ZN5Base22f2Ev>: push   %rbp
0x40074d <_ZN5Base22f2Ev+1>: mov    %rsp,%rbp

其中，0代表offset，第三项0x400918值与_vptr.Base2一致，其中的内容通过x/2i 0x000000000040074c分析可以看出为Base2::f2()函数地址。那么第二项又代表什么呢？

还记得上篇文章中的RTTI信息么？对！第二项就是指向RTTI信息的地址，可以通过如下命令：

(gdb) x/2xg 0x0000000000400980
0x400980 <_ZTI5Base2>: 0x0000000000600da0 0x0000000000400990
(gdb) x/s 0x0000000000400990
0x400990 <_ZTS5Base2>:  "5Base2"

其中，_ZTI5Base2代表typeinfo for Base2，其指向的地址有两个内容，分别是0x0000000000600da0和0x0000000000400990，其中0x400990存储的是类名，可以通过x/s来证明。

然后接着分析0x0000000000600da0存储的内容，如下：

(gdb) x/2xg 0x0000000000600da0
0x600da0 <_ZTVN10__cxxabiv117__class_type_infoE@@CXXABI_1.3+16>: 0x0000003e9628b210 0x0000003e9628b230

_ZTVN10__cxxabiv117__class_type_infoE解析之后为vtable for __cxxabiv1::__class_type_info。

综上，类Base2的内存布局如下图所示：

多重继承

跟上节一样，仍然通过 -fdump-class-hierarchy 参数获取Derived类的详细信息，如下：

Vtable for Derived
Derived::_ZTV7Derived: 7u entries
0     (int (*)(...))0
8     (int (*)(...))(& _ZTI7Derived)
16    (int (*)(...))Base1::f1
24    (int (*)(...))Derived::f2
32    (int (*)(...))-16
40    (int (*)(...))(& _ZTI7Derived)
48    (int (*)(...))Derived::_ZThn16_N7Derived2f2Ev

Class Derived
   size=32 align=8
   base size=32 base align=8
Derived (0x0x7f2708268af0) 0
    vptr=((& Derived::_ZTV7Derived) + 16u)
  Base1 (0x0x7f2708127840) 0
      primary-for Derived (0x0x7f2708268af0)
  Base2 (0x0x7f27081278a0) 16
      vptr=((& Derived::_ZTV7Derived) + 48u)

接着继续使用gdb进行分析：

(gdb) disas
Dump of assembler code for function main:
   0x00000000004006f8 <+0>: push   %rbp
   0x00000000004006f9 <+1>: mov    %rsp,%rbp
   0x00000000004006fc <+4>: push   %rbx
   0x00000000004006fd <+5>: sub    $0x18,%rsp
   0x0000000000400701 <+9>: mov    $0x10,%edi
   0x0000000000400706 <+14>: callq  0x400578 <_Znwm@plt>
   0x000000000040070b <+19>: mov    %rax,%rbx
   0x000000000040070e <+22>: mov    %rbx,%rdi
   0x0000000000400711 <+25>: callq  0x40076a <_ZN5Base2C2Ev>
   0x0000000000400716 <+30>: mov    %rbx,-0x18(%rbp)
   0x000000000040071a <+34>: mov    $0x20,%edi
   0x000000000040071f <+39>: callq  0x400578 <_Znwm@plt>
   0x0000000000400724 <+44>: mov    %rax,%rbx
   0x0000000000400727 <+47>: mov    %rbx,%rdi
   0x000000000040072a <+50>: callq  0x40079a <_ZN7DerivedC2Ev>
=> 0x000000000040072f <+55>: mov    %rbx,-0x20(%rbp)
   0x0000000000400733 <+59>: mov    $0x0,%eax
   0x0000000000400738 <+64>: add    $0x18,%rsp
   0x000000000040073c <+68>: pop    %rbx
   0x000000000040073d <+69>: pop    %rbp
   0x000000000040073e <+70>: retq
End of assembler dump.
(gdb) p/x $rax
$8 = 0x612c40
(gdb) p sizeof(Derived)
$9 = 32
(gdb)  x/6xg 0x612c40
0x612c40: 0x00000000004008e0 0x0000000000000000
0x612c50: 0x0000000000400900 0x0000000000000000
0x612c60: 0x0000000000000000 0x00000000000203a1
(gdb) p &(((Derived*)0)->a)
$15 = (int *) 0x8
(gdb) p &(((Derived*)0)->b)
$16 = (int *) 0x18
(gdb) p &(((Derived*)0)->c)
$17 = (int *) 0x1c
p *((Derived*)0x612c40)
$13 = {<Base1> = {_vptr.Base1 = 0x4008e0, a = 0}, <Base2> = {_vptr.Base2 = 0x400900, b = 0}, c = 0}

从上述代码可以看出，Derived的结构布局如下：

接着，我们分析类Derived的虚函数表：

(gdb) x/7xg 0x00000000004008e0 - 0x10
0x4008d0 <_ZTV7Derived>: 0x0000000000000000 0x0000000000400938
0x4008e0 <_ZTV7Derived+16>: 0x0000000000400740 0x0000000000400758
0x4008f0 <_ZTV7Derived+32>: 0xfffffffffffffff0 0x0000000000400938
0x400900 <_ZTV7Derived+48>: 0x0000000000400763

其对应如下：

Vtable for Derived
Derived::_ZTV7Derived: 7u entries
0     (int (*)(...))0
8     (int (*)(...))(& _ZTI7Derived)
16    (int (*)(...))Base1::f1
24    (int (*)(...))Derived::f2
32    (int (*)(...))-16
40    (int (*)(...))(& _ZTI7Derived)
48    (int (*)(...))Derived::_ZThn16_N7Derived2f2Ev

为了验证如上，继续使用gdb进行操作：

(gdb) x/2xg 0x0000000000400938
0x400938 <_ZTI7Derived>: 0x0000000000600df8 0x0000000000400970
(gdb) x/4xi 0x0000000000400740
   0x400740 <_ZN5Base12f1Ev>: push   %rbp
   0x400741 <_ZN5Base12f1Ev+1>: mov    %rsp,%rbp
   0x400744 <_ZN5Base12f1Ev+4>: mov    %rdi,-0x8(%rbp)
   0x400748 <_ZN5Base12f1Ev+8>: nop
(gdb) x/2xi 0x0000000000400740
   0x400740 <_ZN5Base12f1Ev>: push   %rbp
   0x400741 <_ZN5Base12f1Ev+1>: mov    %rsp,%rbp
(gdb) x/2xi 0x0000000000400758
   0x400758 <_ZN7Derived2f2Ev>: push   %rbp
   0x400759 <_ZN7Derived2f2Ev+1>: mov    %rsp,%rbp
(gdb) x/4xi 0x0000000000400763
   0x400763 <_ZThn16_N7Derived2f2Ev>: sub    $0x10,%rdi
   0x400767 <_ZThn16_N7Derived2f2Ev+4>: jmp    0x400758 <_ZN7Derived2f2Ev>
   0x400769: nop
   0x40076a <_ZN5Base2C2Ev>: push   %rbp 

在上面的内存布局中，_ZThn16_N7Derived2f2Ev在上篇文章中没有进行分析，那么这个标记代表什么意思么，其作用又是什么呢？

通过c++filt将其demanged之后，non-virtual thunk to Derived::f2()。那么这个thunk的目的或者意义在哪呢？

我们看下如下代码：

Derived *d = new Derived;
Base1 *b1 = (Base1*)d;
Base2 *b2 = (Base2*)d;

std::cout << d << " " << b1 << " " << b2 << std::endl;

((Base2*)d)->f2();

输出如下：

0x1cc0c20 0x1cc0c20 0x1cc0c30

可以看出，同样是一个地址，使用Base1转换的地址和使用Base2转换的地址不同，这是因为在转换的时候，对指针进行了偏移，即加上了sizeof(Base1)。

好了，言归正传。

分析下如下情况：

Base1* b1 = new Derived();
b1->f1();

其正常工作，不需要移动任何指针，这是因为b1指向Derived对象的首地址。

那么如下是下面这种情况呢？

Base2* b2 = new Derived();
// 相当于 Derived *d = new Derived;
// Base2* b2 = d + sizeof(Base1);
b2->f2();

对于创建对象操作，在上述代码中有大致解释，那么对于b2->f2()操作，编译器又是如何实现的呢？

其必须将b2所指向的指针调整为具体的Derived对象的其实指针，这样才能正确的调用f2。此操作可以在运行时完成，即在运行时候通过调整指针指向进行操作，但这样效率明显不高。所以为了解决效率问题，编译器引入了thunk，即在编译阶段进行生成。那么针对上面的b2->f2()操作，编译器会进行如下：

void thunk_to_Derived_f2(Base2* this) {
    this -= sizeof(Base1);
    Derived::f2(this);
}

我们仍然通过gdb来验证这一点，如下：

(gdb) x/2i 0x0000000000400763
   0x400763 <_ZThn16_N7Derived2f2Ev>: sub    $0x10,%rdi
   0x400767 <_ZThn16_N7Derived2f2Ev+4>: jmp    0x400758 <_ZN7Derived2f2Ev>

其中，寄存器rdi中存储的是this指针，对this指针进行-16操作，然后进行调用 Derived::f2(this) 。

继续分析虚函数表的内容，其第二项为TypeInfo信息：

(gdb) x/2xg 0x0000000000400938
0x400938 <_ZTI7Derived>: 0x0000000000600df8 0x0000000000400970
(gdb) x/2xg 0x0000000000600df8
0x600df8 <_ZTVN10__cxxabiv121__vmi_class_type_infoE@@CXXABI_1.3+16>: 0x0000003e9628df70 0x0000003e9628df90
(gdb) x/s 0x0000000000400970
0x400970 <_ZTS7Derived>:  "7Derived"

所以，综合以上内容，class Derived的内存布局如下图所示：

 

通过上图，可以看出class Derived对象有两个vptr，那么有没有可能将这俩vptr合并成一个呢？

答案是不行。这是因为与单继承不同，在多继承中，class Base1和class Base2相互独立，它们的虚函数没有顺序关系，即f1和f2有着相同对虚表起始位置的偏移量，所以不可以按照偏移量的顺序排布；并且class Base1和class Base2中的成员变量也是无关的，因此基类间也不具有包含关系；这使得class Base1和class Base2在class Derived中必须要处于两个不相交的区域中，同时需要有两个虚指针分别对它们虚函数表索引。

偏移(offset)

在前面的内容中，我们多次提到了top offset，在上节Derived的虚函数表中，有两个top offset，其值分别为0和-16，那么这个offset起什么作用呢？

在此，先给出结论：将对象从当前这个类型转换为该对象的实际类型的地址偏移量。

仍然以前面的class Derived为例，其虚函数表布局如下：

Vtable for Derived
Derived::_ZTV7Derived: 7u entries
0     (int (*)(...))0
8     (int (*)(...))(& _ZTI7Derived)
16    (int (*)(...))Base1::f1
24    (int (*)(...))Derived::f2
32    (int (*)(...))-16
40    (int (*)(...))(& _ZTI7Derived)
48    (int (*)(...))Derived::_ZThn16_N7Derived2f2Ev

为了能方便理解本节内容，我们不妨将Derived虚函数表认为是 class Base1和class Base2两个类的虚函数表拼接而成 。因为是多重继承，所以编译器将先继承的那个认为是 主基类(primary base) ，因此Derived类的主基类就是class Base1。

在多继承中，当最左边的类中没有虚函数时候，编译器会将第一个有虚函数的基类移到对象的开头，这样对象的开头总是有vptr。

首先看虚函数表的前半部分，如下：

0     (int (*)(...))0
8     (int (*)(...))(& _ZTI7Derived)
16    (int (*)(...))Base1::f1
24    (int (*)(...))Derived::f2

正是因为编译器将class Base1作为Derived的主基类，并将自己的函数加入其中。从上述可以看出offset为0，也就是说Base1类的指针不需要偏移就可以直接访问Derived::f2()。

接着看虚函数表的下半部分：

32    (int (*)(...))-16
40    (int (*)(...))(& _ZTI7Derived)
48    (int (*)(...))Derived::_ZThn16_N7Derived2f2Ev

偏移值为-16，因为是多重继承，所以class Base1和class Base2类型的指针或者引用都可以指向class Derived对象，那么又是如何调用正确的成员函数呢？

Base2* b2 = new Derived;
b2->f2(); //最终调用Derived::f2();

由于不同的基类起点可能处于不同的位置，因此当需要将它们转化为实际类型时，this指针的偏移量也不相同，且由于多态的特性，b2的实际类型在编译时期是无法确定的；那必然需要一个东西帮助我们在运行时期确定b2的实际类型，这个东西就是offset_to_top。通过让this指针加上offset_to_top的偏移量，就可以让this指针指向实际类型的起始地址。

结语

写这块的时候，感觉需要写的还是很多的，也有很多内容没写，比如虚拟继承、菱形继承的布局都在本文中没有体现，后面有机会再接着分析。今天的文章就到这，我们下期见！

如果对本文有疑问可以加笔者微信直接交流，笔者也建了C/C++相关的技术群，有兴趣的可以联系笔者加群。

你好，我是雨乐，从业十二年有余，历经过传统行业网络研发、互联网推荐引擎研发，目前在广告行业从业8年。目前任职某互联网公司高级技术专家一职，负责广告引擎的架构和研发。专注于架构、技术、线上bug分析等干货，欢迎关注。