多继承，RTTI和虚函数

  - _ -b 最近喜欢在CSDN上写长文抢分...  不能抢一，就发他个千文贴，楼主揭帖的时候一看哟这么长，100分怎么也得给个80罢？

 

    早在一个月前，讨论某个多继承相关的bug的时候，我就想写这个主题了。但是那时候对高层概念知之甚少，怕有所偏颇。 前几天恰好看到一个百分贴《RTTI一定要求有虚函数吗？》，一不小心，回复了近2K文字，俨然一篇整文...  既然已经写了，那就干脆用上把。

 

---

  

    问题 1  多继承、向上映射有冲突？ C++ 的设计错了吗？

    最初的时候，C++只有单继承。很多人要求多继承，然而多继承就必然涉及到某种程度的类型识别问题！（阿？会吗？） 看下面一个多继承的例子。看出有什么错误吗？

class A{ int i; };
class B{ int i; };
class C: public A, public B{};
 
void delB( B* pb ){
    delete pb;
}
 
int main(){
    B* pc = new C;
    delB( pc );
}

      B是C的公开基类， 亦即：C的对象是B的对象，所以C++甚至鼓励这样做： B* pc = new C; 

 

      但是，上面的程序实际上是错误的。 在VC7.1 Debug 模式下会出现一个保护性测试报错 _BLOCK_TYPE_IS_VALID( pHead->nBlockUse )。为什么呢？

      问题来自于多继承。A和B大小为4，假如C的地址为 2000，则C::B的地址为 2004 ! 所以 pb = 2004，和C的实际分配地址产生了所谓“内存错位”现象！下面的操作将试图删除2004(而不是2000）的内容 :

void delB( B* pb ){
  delete pb;
}

 

    花开两支，各表一支。这一支暂且按下不表，先看看另一支：

 

---

 

     问题 2  typeid一定要虚函数么？

    前几天，C++区有人提下面的问题（稍有删节）：

 

    基类如果没有虚函数。输出结果(rtti)就不对。不知道为什么。环境：win2000、vs2003、控制台工程。/GR

class BaseClass{
    // 如果把这行注释掉。下面的输出结果就不正确了。(应该是DerivedClass1，却变成了BaseClass)为什么。(gcc也是这种情况)
    virtual void vfunc(){}; 
};
class DerivedClass1 : public BaseClass{};
class DerivedClass2 : public BaseClass{};
 
int _tmain(int argc, _TCHAR* argv[]){
    DerivedClass1 obj1;
 
    BaseClass*p = &obj1;
    std::cout << typeid(*p).name() << std::endl;
}

 

    其实，这根本不是错误。ISO C++98 规定，涉及继承的 RTTI 都要求对象是“多态类型”：

5.2.7 Dynamic cast
条款6 在其他情况下， v 必须是多态类型(10.3)的指针或者左值。

5.2.8 Type identification
条款2 当type_info作用于多态类型(10.3)左值的时候，结果是描述最后继承对象的 type_info 对象（即，动态对象）。

    那么多态类型是什么呢？

10.3 Virtual functions
条款1 ... 一个包含或者继承虚函数的class 被称为多态 class

    看来虚函数和RTTI的确存在深刻的联系。但是，C++ 为什么要这样规定？

 

 

---

 

    我们要知道C++不是透明的语言。 若要真正理解C++，就必须知道他的“背后”完成了什么。 C/C++很吝啬而高效的。他们的执行是如此面向底层，以至于可以与汇编媲美。

 

    一个普通的结构，C++绝对不会往里面放入多余的东西。 RTTI是OOP的强力支持，但是同样有额外开销。 游戏程序员甚至声称：“不要用RTTI和虚函数，他们会显著且莫名其妙的影响性能”—— RTTI容易造成Cache丢失。 但他们仍然大量使用C++，因为 C++ 让你能自由选择要支持还是要开销 —— java 、C# 等语言则强制捆绑了所有特性。

 

    下面解释RTTI的原理，我们用一个一般的32位C++编译器：

    假定 BaseClass 不是多态类型，他没有虚函数，如下：

class BaseClass {
    int i, j;
};

    显然它只有8个字节（两个int）空间。 他必须和C的struct开销等价，否则很多人就会抛弃C++了。

 

    下面有一个基类指针：

BaseClass* p = new DerivedClass;

    系统如何知道 p 指向什么东西？没办法知道呀。p 只拥有前8个字节的访问权，这8个字节已经有用了。也许 DerivedClass 可以在第9个字节放上什么信息， 但是 p 绝对不该访问这个字节 —— 既然 BaseClass 没有纯虚函数（即可以实例化）， 万一 p 真的指向 BaseClass 类型，岂不是越界访问了？

 

    聪明的读者啊，你能想出一个不增加 class 大小，又能支持RTTI的算法吗？ （难道你打算让C++提供一个虚拟机，对所有内存进行索引？ 这显然会得到更BT的开销 ）

 

    那么系统如何支持RTTI的呢？答案是借用虚函数表。

     

 

---

 

     对于C++有一个常识是：假如一个类用于继承，那么它的析构函数一定要是虚函数（除非你有非常特殊的理由） —— 否则对基类指针执行delete，派生类的析构函数就被忽略了。即使派生类无需作额外析构工作， 后面我们还有一个更大的理由。 看这个BaseClass， 由于增加了一个虚析构函数，他就变成了多态类。

class BaseClass {
    int i, j;
public:
    virtual ~BaseClass();
};

    为了实现多态，C++ 已经有了虚函数表的概念。 当某个类包含虚函数的时候，系统就要晚绑定动态调用它。 所以，这样的类就要承担额外的时间和空间开销：他的大小会增加4字节，这个 VPTR 指针指向类对应的虚函数表。每个基类和子类都有单独的虚函数表，构造函数调用时会设置当前的 VPTR。 于是多态就很容易实现了。

     所以，上面的 BaseClass 的大小变成了12字节。VC的虚函数表在第一个DWORD上，某些Linux下的编译器虚函数表在最后一个DWORD上。

    假如有一个BaseClass* p，那么系统可以传递他的地址作为 this，从虚函数表中找到对应函数执行调用。

 

    当标准化委员会决定增加RTTI特性的时候，他们把目光放在了虚函数表上。一旦打开 RTTI 选项，虚函数表里面就增加了多个子表的引用。

BaseClass* p = new DerivedClass;

    当你要求RTTI操作时，编译器产生代码察看 p的 VPTR，索引到其中需要的子表，完成操作。这也是为什么VC 关闭 RTTI 时不能正确 cast 的原因 —— 那种情况下虚函数表中只包含虚函数。

 

 

---

   当涉及到多继承的时候，不只是delete，虚函数调用同样出现了危机：基类和派生类拥有不同的this，却可以调用同样的虚函数 —— 如何传递正确的 this ?

    考虑一个基类虚函数f ，他被多继承的派生类 Derived 覆盖。

struct B{
    virtual void f();
};

struct Derived: public A, public B{
    virtual void f();    // 覆盖B::f
}

Derived* pd = new Derived;         // 假定返回2000
B*  pb   = pd;                                   // 指向 Derived::B,  结果可能是2004

    现在的问题是， 地址为2000的 pd 和 2004的 pb 都可以调用 f， 但无论怎么调用 f 必须获得 this 指针 2000 —— 这需要一个向下的修正。 怎么修正呢？

    VC 的处理很聪明：  B::f 是B的虚函数，所以就应该传递B* 。 于是，无论你通过基类还是派生类调用f，传递的都是 pd->B 的地址 2004， 而 Derived::f 则知道自己收到的是 Derived::B的地址，从而减去4得到正确地址2000。

 

    回到最初的问题。派生类指针不知道自己的真正this， 但是他的虚函数知道。 所以大部分编译器采取这样的策略：通过虚析构函数（而不是delete运算符）完成空间释放操作。

 

    当VC执行 delete bp 时， 如果bp的析构函数为虚函数，他并非在原地删除bp，而是 push 一个“删除标志”，然后调用 bp 的当前析构函数 —— 即最晚派生类的析构函数。

    最晚派生类肯定拥有自己的析构函数 —— 如果你不定义，那么编译器会产生一个默认的版本。 在析构函数尾部，他检查删除标志，根据情况 operator delete this。 根据上面所说的，我们知道这个 this 已经是正确的了。