新一篇: 网络资源收集(02/12/2007-02/16/2007)  | 旧一篇: 网络资源收集(01/15/2007-01/19/2007)

引言：近日CSDN的"C/C++语言"版的一个问题引起了我的注意:"请问虚函数表放在哪里?"。我也曾经思考过这个问题，零零散散也有一定的收获，这次正好趁这个机会把我对这一部分的理解整理一下。 首先值得声明的是，本文的编译环境是VS2002+WinXP。C++标准并没有对虚函数的实现作出任何的说明，甚至都没有提到虚函数的实现需要用虚表来实现，只不过主流的C++编译器的虚函数机制都是通过虚表来实现的，所以用虚表来实现虚函数就成了"不是标准的标准"。但是这并不代表所有编译器在实现细节上的处理都是完全一致的，它们或多或少都存在一定的个体差异。所以，本文的结论不一定适用于其他的编译情况。

虚函数/虚表的基础知识
一个类存在虚函数，那么编译器就会为这个类生成一个虚表，在虚表里存放的是这个类所有虚函数的地址。当生成类对象的时候，编译器会自动的将类对象的前四个字节设置为虚表的地址，而这四个字节就可以看作是一个指向虚表的指针。虚表里依次存放的是虚函数的地址，每个虚函数的地址占4个字节。

编译模块内部虚表存放的位置
如果一个模块定义了拥有虚表的类，那么这个类的虚表存放在那里呢？要回答这个问题，我们还是需要用汇编代码入手，我首先建立了一个简单的Win32 Console Application，然后定义了一个带虚函数的类，在相应的汇编代码中，我找到了重要的破解虚表存放位置的重要线索：
以上的汇编代码给了我们这样的信息：
1> 虚表存放的位置应该实在模块的常量段中；
2> 这个类有两个虚函数，它们分别是?foobar@CDerived@@UAEXXZ和?callMe@CDerived@@UAEXXZ。

外部模块虚表存放的位置
当一个模块导出了一个带虚表的类，而另外一个模块又使用了这个导出类，这时候情况又是什么样的呢？这里存在两种很自然的处理方式：
1。维护一份虚表。虚表放在定义导出类的那个模块，任何使用这个导出类的其他模块都要通过这个模块来使用导出类。
2。维护多份虚表。这时候每一个使用导出类的模块都会有一份虚表的拷贝。
VS2002是使用那一种情况呢？在假设存在多份虚表的前提下，我们可以使用这样的策略来判断VS2002使用那种方式：
1。在类定义模块中创建一个类对象，并在另外一个模块中使用这个类对象。在类定义模块中创建类对象保证编译器用类定义模块中的虚表来初始化类对象。
2。在模块(非类定义模块)中创建并类对象并使用它。这样就保证编译器会用模块中的虚表来初始化类对象。
3。分别获取两种情况下两个类对象的虚表指针。如果它们的值相等，就说明只存在一份虚表；如果它们的值不等，就说明存在多份虚表。
4。如果两个虚表指针的值相等，则虚表来自于两个模块中的一个模块，判断这个虚表来自于那个模块。

应用上面的策略，我们首先建立一个Win32 DLL工程导出一个带虚表的类，再建立一个Win32 Consle Application使用这个导出类。在Win32 Consle Application的主函数中，我写了以下的代码：
对这段代码做如下的解释：
1。createObject()是DLL导出了一个全局函数。这个全局函数实现的功能就是生成一个类对象并将类对象的地址传出。这样做的目的就是为了在类定义模块中生成一个类对象。
2。获得虚表指针和虚函数的代码可以这样分析：由于虚表指针存放在类对象的前4个字节中，我们首先需要将类对象的首地址转化成int型指针，并通过这个int型指针获得前4个字节的内容，这个内容就是虚表的地址。接着我们将这个虚表的地址再转化成int型指针，并通过这个int型指针获得虚表的前4个字节的内容，这个内容就是虚表的第一项的值，也就是一个虚函数的地址。

通过调试，我们得出这样的结果：
比较vTableAdress和vTableAdress2的值我们发现它们的值是完全一样的，这就说明我们的假设是不正确的，这里是存在一份虚表。那最后的一个问题就是这个虚表是来自于那个模块呢？这个答案我们需要通过比较虚表的地址以及模块所占的内存空间来解答。在调试状态下，打开"模块"窗口，我们就可以找到模块的地址：

其中的DllInDepth.dll模块就是定义导出类的模块，而TestApp.exe就是使用这个类的模块。通过比较不难发现，虚表的地址落在DllInDepth.dll的地址范围内，这就说明了虚表来在于类定义的模块。

到了现在，关于虚表存放的问题基本上都得到了圆满的解决，但是我又有了一个新的问题：为什么会是这样的情况呢？我想，大概应该是这样的原因吧：类对象虚表指针的初始化应该发生在构造函数被调用的时候，更具体的说应该实在进入到构造函数"{"之前，这个时机就是通常所说的构造函数"初始化列表"被执行的时候。由于构造函数是在类定义模块中执行的，当然虚表也应该是类定义模块的虚表，对于其他的模块而言就是导入函数的调用，这样就没有必要维护多份虚表了。

后记

虽然本文的主要内容是讨论虚表的位置，实际上本文涉及到DLL导出类的内容。在论坛上也经常看到一些网友对DLL导出类的内容感到迷惑。相对于简单的函数和数据，类的构成将显得比较复杂，类声明中可以包含任意类型的数据，成员函数，虚函数，静态函数，我们就不禁迷惑这些东西是以什么样的方式导出并让其他的模块使用的？对于这个问题，我不禁想到了一个很有名的缩写"KISS(Keep It Simple, Stupid)"。这是一个很有用的思维方式，我们就不妨尝试使用这种思维方法从简单的出发点开始思考。对于DLL来说，作为一个模块，用户感兴趣的无非是代码和数据：

•     对于代码来说，DLL是以函数符号的形式导出的。

•     对于数据来说，DLL是以数据符号的形式导出的。

在对C++类的结构(或者说模型)进行深入分析的基础上，我们知道，对于C++类，它既有代码，也有数据：

•    代码是以类的成员函数,类的虚函数和类的静态函数的形式存在的；

•    数据包含类的静态成员变量和类的虚表。

由此可见，从本质上来说，DLL导出类的情况就是导出函数和数据，并没有什么神秘的。如果我们再加上类的特殊性的分析，问题的答案就清晰了：

1. 对于成员函数，虚函数，静态函数和静态数据，他们都处于类的作用域内，所以他们导出的函数符号中应该包含类的信息。
2. 对于成员函数和虚函数，他们的第一个参数应该是指向类对象的指针，并且他们以"__thiscall"的调用习惯(calling convention)调用。
3. 对于类的静态函数和静态数据，DLL按照全局函数和全局数据的处理方式一样处理他们。
4. 虚表是以常量的形式导出的。
   

^_^，DLL导出类的情况尽是如此的简单，没有想到吧，不过"情况就是这样的"。

参考文献
1.提到C++对象模型，就不得不提这本书：《深度探索C++对象模型》。对这本书的评价我就不罗嗦了，反正是只要涉及到C++对象模型的问题，很多人告诉你去看这本书就好了。相对于很多人这本书几乎痴迷的崇拜，我保留我自己一点小小的看法。C++对象模型的细节太依赖于C++编译器，各个不同厂商的编译器之间，甚至是同一厂商不同版本编译器之间，都可能存在这样或者那样的差别。对于不同的编译器，我们还是要"就事论事"，通过自己的实践来获得某个编译器下的"第一手资料",而不能100%迷信书中的说法。
2.无意中发现一篇网友的BLOG文章,内容正好也是关于DLL中导出C++类,我发现写的比我的详细,对这个问题特别感兴趣的朋友可以看看这篇文章:
    Balon白话MSDN：从普通DLL中导出C++类（2） – 细看导出C++类的底层机制

历史记录
01/28/2007   v1.0
原文的第一版
05/10/2007  v1.1
添加：在后记中添加了对DLL导出类的内容的分析

发表于 @ 2007年01月28日 14:09:00|评论(loading...)|编辑

新一篇: 网络资源收集(02/12/2007-02/16/2007)  | 旧一篇: 网络资源收集(01/15/2007-01/19/2007)