在网上经常看到有人说,dynamic_cast的效率问题.当然因为它是运行 时的cast,开销必然少不了.
对于down cast,可以用static_cast代替,只不过不太安全.
对于钻石结构类关系,要cast到兄弟类,那么只能用dynamic_cast了.
记得我在做前一个项目中,发现召唤了500个一样的怪物的时候客户端巨卡,于是把可以优化的地方都搞了一遍,包括把dynamic_cast改为 static_cast.最后问题解决了,这也让我对dynamic_cast有了实践性的感知,而不是停留在道听途说的那种认识.
今天跟同事讨论dynamic_cast,同时我也觉得Gamebryo的NiIsKindOf和NiDynamicCast的效率跟C++的效率 差不多,都是运行时的类型判断和转换,但是同事跟我说,C++的dynamic_cast会比较虚函数表,也就是一层一层匹配v-table,开销巨大, 而Gamebryo的RTTI没有这么大的开销.我带着疑问做了测试发现如下结果:
在相同的软件和硬件环境下,相同的循环次数下,并且都是Release版本:
1.typeid() 类型判断与NiIsKindOf的比较
typeid用了9秒多,NiIsKindOf用了2秒多.
2.dynamic_cast与NiDyanmicCast:
dymaic_cast用了26.7秒,NiDyamicCast用了3.3秒, 8倍!
看到以上结果,我顿时大吃一惊,明白了为什么很多引擎用自己实现的RTTI而不用C++的.比如Nebula引擎也有类似的RTTI,当时我看到了还很不 理解.
实践是检验真理的唯一标准,呵呵,以前不管别人怎么说,我是带有不确定的疑问,"真的是这样吗",今天测了才知道确实不一样.
突然想起来,这个测试可能不准,因为编译模式里面把C++内置的RTTI关掉了,会不会影响效率呢.有待验证..
另我对于Gamebryo或者其他类似的RTTI的看法,
第一,不雅观,为了方便把宏丢到类声明里面,宏本身我就觉得不雅,如果放在逻辑执行块里面我还勉强能接受,放在类声明里面,至少我肯定不会这么做的,呵 呵.
第二,更重要的,Effective C++上说,尽量避免dyamic_cast,不光是运行时的开销,而且对于设计,也不太好.用到dynamic_cast的设计,不能算是好的设计.应 该在对象抽象上做好统一的接口.因为IsKindOf或者dynamic_cast都是依赖于具体类型的,面向过程的,相当于一个if else,而不是面向对象的.
如何在运行时确定对象类型（RTTI）
RTTI 是“Runtime Type Information”的缩写，意思是：运行时类型信息。它提供了运行时确定对象类型的方法。本文将简略介绍 RTTI 的一些背景知识、描述 RTTI 的概念，并通过具体例子和代码介绍什么时候使用以及如何使用 RTTI；本文还将详细描述两个重要的 RTTI 运算符的使用方法，它们是 typeid 和 dynamic_cast。
其实，RTTI 在C++中并不是什么新的东西，它早在十多年以前就已经出现了。但是大多数开发人员，包括许多高层次的C++程序员对它并不怎么熟悉，更不用说使用 RTTI 来设计和编写应用程序了。
一些面向对象专家在传播自己的设计理念时，大多都主张在设计和开发中明智地使用虚拟成员函数，而不用 RTTI 机制。但是，在很多情况下，虚拟函数无法克服本身的局限。每每涉及到处理异类容器和根基类层次（如 MFC）时，不可避免要对对象类型进行动态判断，也就是动态类型的侦测。如何确定对象的动态类型呢？答案是使用内建的 RTTI 中的运算符：typeid 和 dynamic_cast。
首先让我们来设计一个类层次，假设我们创建了某个处理文件的抽象基类。它声明下列纯虚拟函数：open()、close()、read()和 write()：
class File
{
public:
virtual int open(const string & filename)=0;
virtual int close(const string & filename)=0;
//
virtual ~File()=0; // 记住添加纯虚拟析构函数（dtor）
};
现在从 File 类派生的类要实现基类的纯虚拟函数，同时还要提供一些其他的操作。假设派生类为 DiskFile，除了实现基类的纯虚拟函数外，还要实现自己的flush()和defragment()操作：
class DiskFile: public File
{
public:
int open(const string & filename);
// 实现其他的纯虚拟函数
......
// 自己的专有操作
virtual int flush();
virtual int defragment();
};
接着，又从 DiskFile 类派生两个类，假设为 TextFile 和 MediaFile。前者针对文本文件，后者针对音频和视频文件：
class TextFile: public DiskFile
{
// ......
int sort_by_words();
};
class MediaFile: public DiskFile
{
//......
};
我们之所以要创建这样的类层次，是因为这样做以后可以创建多态对象，如：
File *pfile; // *pfile的静态类型是 File if(some_condition) pfile = new TextFile; // 动态类型是 TextFile else pfile = new DiskFile; // 动态类型是 DiskFile
假设你正在开发一个基于图形用户界面（GUI）的文件管理器，每个文件都可以以图标方式显示。当鼠标移到图标上并单击右键时，文件管理器打开一个菜单，每 个文件除了共同的菜单项，不同的文件类型还有不同的菜单项。如：共同的菜单项有“打开”“拷贝”、和“粘贴”，此外，还有一些针对特殊文件的专门操作。比 如，文本文件会有“编辑”操作，而多媒体文件则会有“播放”菜单。为了使用 RTTI 来动态定制菜单，文件管理器必须侦测每个文件的动态类型。利用 运算符 typeid 可以获取与某个对象关联的运行时类型信息。typeid 有一个参数，传递对象或类型名。因此，为了确定
x 的动态类型是不是Y，可以用表达式：typeid(x) == typeid(Y)实现：
#include <typeinfo> // typeid 需要的头文件
void menu::build(const File * pfile)
{
if (typeid(*pfile)==typeid(TextFile))
{
add_option("edit");
}
else if (typeid(*pfile)==typeid(MediaFile))
{
add_option("play");
}
}
使用 typeid 要注意一个问题，那就是某些编译器（如 Visual C++）默认状态是禁用 RTTI 的，目的是消除性能上的开销。如果你的程序确实使用了 RTTI，一定要记住在编译前启用 RTTI。使用 typeid 可能产生一些将来的维护问题。假设你决定扩展上述的类层次，从MediaFile 派生另一个叫 LocalizeMedia 的类，用这个类表示带有不同语言说明文字的媒体文件。但 LocalizeMedia 本质上还是个 MediaFile 类型的文件。因此，当用户在该类文件图标上单击右键时，文件管理器必须提供一个“播放”菜单。可惜
build()成员函数会调用失败，原因是你没有检查这种特定的文件类型。为了解决这个问题，你必须象下面这样对 build() 打补丁：
void menu::build(const File * pfile)
{
//......
else if (typeid(*pfile)==typeid(LocalizedMedia))
{
add_option("play");
}
}
唉，这种做法真是显得太业余了，以后每次添加新的类，毫无疑问都必须打类似的补丁。显然，这不是一个理想的解决方案。这个时候我们就要用到 dynamic_cast，这个运算符用于多态编程中保证在运行时发生正确的转换（即编译器无法验证是否发生正确的转换）。用它来确定某个对象是 MediaFile 对象还是它的派生类对象。dynamic_cast 常用于从多态编程基类指针向派生类指针的向下类型转换。它有两个参数：一个是类型名；另一个是多态对象的指针或引用。其功能是在运行时将对象强制转换为目 标类型并返回布尔型结果。也就是说，如果该函数成功地并且是动态的将
*pfile 强制转换为 MediaFile，那么 pfile的动态类型是 MediaFile 或者是它的派生类。否则，pfile 则为其它的类型：
void menu::build(const File * pfile)
{
if (dynamic_cast <MediaFile *> (pfile))
{
// pfile 是 MediaFile 或者是MediaFile的派生类 LocalizedMedia
add_option("play");
}
else if (dynamic_cast <TextFile*> (pfile))
{
// pfile 是 TextFile 是TextFile的派生类
add_option("edit");
}
}
细细想一下，虽然使用 dynamic_cast 确实很好地解决了我们的问题，但也需要我们付出代价，那就是与 typeid 相比，dynamic_cast 不是一个常量时间的操作。为了确定是否能完成强制类型转换，dynamic_cast`必须在运行时进行一些转换细节操作。因此在使用 dynamic_cast 操作时，应该权衡对性能的影响。