C++的RTTI和dynamic_cast效率问题

本文探讨了RTTI(运行时类型信息)及其在C++中的应用,特别是typeid和dynamic_cast两个运算符的使用。通过实例展示了如何在多态编程中使用这些工具来判断对象类型及进行安全的类型转换。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在网上经常看到有人说,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 操作时,应该权衡对性能的影响。
<think>我们被要求回答关于C++四种类型转换操作符的区别用法:static_cast, dynamic_cast, const_cast, reinterpret_cast。 根据提供的引用,我们可以总结如下: 1. static_cast: - 用于基本类型转换(如int转double)具有明确继承关系的类指针或引用的转换(向上转换是安全的,向下转换不安全)。 - 不进行运行时类型检查,因此向下转换(基类指针转派生类指针)可能不安全。 - 也可以用于非多态类型的转换。 2. dynamic_cast: - 主要用于多态类型(即含有虚函数的类)的安全转换,特别是在继承体系中向下转换(基类指针/引用转派生类指针/引用)或交叉转换。 - 运行时检查转换的有效性。如果转换失败,对于指针返回nullptr,对于引用抛出std::bad_cast异常。 - 要求基类至少有一个虚函数(以提供运行时类型信息)。 3. const_cast: - 用于移除或添加变量的const(或volatile)属性。 - 常用于函数重载或与非const API交互时,但需注意修改原为const的对象是未定义行为。 4. reinterpret_cast: - 提供低级别的重新解释,如将指针转换为整数,或将一种类型的指针转换为另一种不相关类型的指针。 - 非常危险,因为不进行任何类型检查,应尽量避免使用,仅在底层编程(如系统调用、驱动开发)中必要时使用。 我们将按照这些要点组织回答,并给出简单示例。 同时,根据要求,我们需要生成相关问题。 注意:回答中引用的段落末尾要自然地添加引用标识,例如:[^1] 我们引用的内容来自提供的引用[1]到[5],但注意我们只能使用这些引用,不能引入外部知识。 由于用户要求使用中文回答,且数学表达式用$...$,独立公式用$$...$$,但本问题中可能涉及较少数学公式,我们按需使用。 步骤: 1. 分别介绍四种转换,说明区别使用场景。 2. 给出简单代码示例(注意:由于是文本,我们只写关键代码片段)。 3. 生成相关问题。 注意:我们引用的内容在回答中需要标注引用标识,例如:dynamic_cast在运行时进行类型检查[^4]。</think>### C++类型转换操作符详解 C++提供了四种显式类型转换操作符,用于在不同场景下进行安全或强制的类型转换: #### 1. `static_cast`(静态转换) - **用途**:基本类型转换、明确的继承关系转换(如向上转型) - **特点**: - 编译时检查,无运行时开销 - 向下转型(基类→派生类)不安全,可能导致未定义行为 - 不能移除`const`限定符 - **示例**: ```cpp double d = 3.14; int i = static_cast<int>(d); // 基本类型转换 Base* base = new Derived(); Derived* derived = static_cast<Derived*>(base); // 向下转型(风险!) ``` #### 2. `dynamic_cast`(动态转换) - **用途**:安全的多态类型转换(需虚函数支持) - **特点**: - 运行时类型检查(RTTI),失败返回`nullptr`(指针)或抛出异常(引用) - 主要用于继承体系中的向下转型交叉转换 - 比`static_cast`安全但性能开销较大[^4] - **示例**: ```cpp class Base { virtual void foo() {} }; // 必须含虚函数 class Derived : public Base {}; Base* base = new Derived(); Derived* derived = dynamic_cast<Derived*>(base); // 安全向下转型 if(derived) { /* 转换成功 */ } // 运行时检查 ``` #### 3. `const_cast`(常量转换) - **用途**:移除或添加`const`/`volatile`限定符 - **特点**: - 不修改底层数据,仅改变编译器解释 - 修改原为`const`的对象是未定义行为[^2] - 常用于兼容非`const` API - **示例**: ```cpp const int x = 10; int* y = const_cast<int*>(&x); // 移除const限定 *y = 20; // 危险!原对象x仍是const ``` #### 4. `reinterpret_cast`(重新解释转换) - **用途**:底层二进制数据重新解释 - **特点**: - 最危险的转换,不进行任何类型检查 - 常用于系统编程(如指针↔整数转换) - 高度平台依赖,应作为最后手段[^2][^5] - **示例**: ```cpp int x = 10; long ptr_val = reinterpret_cast<long>(&x); // 指针→整数 int* ptr = reinterpret_cast<int*>(ptr_val); // 整数→指针 ``` ### 关键区别总结 | 操作符 | 检查时机 | 安全性 | 典型场景 | |----------------|-----------|-------------|----------------------------| | `static_cast` | 编译时 | 中等(无RTTI)| 基础类型转换、明确继承关系转换 | | `dynamic_cast` | 运行时 | 高 | 多态类型安全向下转型 | | `const_cast` | 编译时 | 低(语义风险)| 临时移除`const`限定 | | `reinterpret_cast` | 无检查 | 极低 | 底层二进制数据重新解释 | > 最佳实践:优先使用`dynamic_cast`保证多态安全;避免`reinterpret_cast`;谨慎使用`const_cast`修改原`const`对象[^2][^4]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值