《你真的了解C++吗》No.026：运行时类型识别（RTTI）的开销——内存实相与寻址算法
导言：当多态失去方向
在正常的虚函数调用中，我们不需要知道对象的精确类型，只需要调用ptr->speak()。但现实开发中，有时你会陷入一种窘境：你手里拿着一个Base*，却必须确认它到底是不是一个Hero*，以便调用其特有的ultimateSkill()。
这种“向下转型（Downcasting）”的需求引出了 C++ 的 RTTI 机制。它是多态的补丁，也是一套极其精密的运行时身份验证系统。
一、 物理存储：type_info到底长什么样？
在 C++ 中，std::type_info是 RTTI 的核心。为了节省空间，编译器不会在每个对象里存储类型信息，而是将其挂在**虚表（vtbl）**上。
1. 内存位置：虚表的“负偏移”
在对象内存布局中，vptr指向虚表。虚表的第一个函数地址（Index 0）之前，通常存储着一个指向该类type_info结构的指针。
2.type_info的内部结构
以 Itanium ABI（GCC/Clang）为例，type_info内部远比name()复杂，它实际上是一组派生结构：
_vptr：type_info本身也是一个类，拥有虚指针。_name：指向Name Mangling（名称修饰）后的类名字符串（如"7Derived"）。- 继承辅助信息：这是最核心的秘密。根据类的复杂度，它会使用不同的辅助结构：
__class_type_info：无基类的简单类。__si_class_type_info：单一继承类，持有指向基类type_info的指针。__vmi_class_type_info：多重/虚继承类，持有一个数组，记录所有基类的type_info地址、访问权限以及它们在对象内的内存偏移量（Offset）。
二、dynamic_cast的寻址算法：它在忙什么？
当你执行Derived* p = dynamic_cast<Derived*>(base_ptr);时，底层运行时库（如__dynamic_cast）会启动一套复杂的搜索算法：
- 定位源起点：通过
base_ptr找到对象的vptr，进而访问虚表，取回当前对象的type_info。 - 获取目标终点：编译器在编译期就已经确定了目标类型
Derived的type_info地址。 - 继承树图搜索（Graph Search）：
- 程序开始遍历
type_info里的继承信息。 - 如果是多重继承，它会递归地检查每一个基类节点。
- 匹配与偏移：一旦找到匹配的
type_info地址，它会根据该节点记录的offset对指针进行加减运算。
- 安全返回：如果整个继承树都找不着，或者由于访问权限（如私有继承）导致转型非法，它会返回
NULL。
三、 性能警告：为什么不要滥用？
相比于编译期确定的static_cast，dynamic_cast的代价非常昂贵：
- Cache Miss 风险：从对象到虚表，再到
type_info，最后在继承树中跳转。每一次“跳跃”都可能导致 CPU 高速缓存失效。 - 跨库（Shared Library）性能塌陷：当涉及动态链接库时，不同库可能为同一个类生成了不同的
type_info副本。此时寻址算法被迫退化，从“地址比较”变为**“字符串比较（strcmp）”**，性能会下降几个数量级。 - 二进制膨胀：为了支持这些信息，编译器必须生成大量的元数据。在嵌入式领域，通常通过
-fno-rtti彻底关闭它。
四、 架构建议：RTTI 是设计失败的信号吗？
C++ 社区常说：“如果你必须频繁使用dynamic_cast，说明你的抽象出问题了。”
- 优化方案：尽量使用虚函数。不要问对象“你是不是英雄”，而是直接调用
ptr->playSpecialEffect()。 - 手动标签：在极其追求性能的场景（如游戏引擎），开发者常在基类定义
enum Type，通过简单的整数比较代替dynamic_cast。
总结：必要的昂贵
- RTTI是 C++ 为了在强类型系统中保留动态灵活性而付出的代价。
dynamic_cast不是简单的逻辑判断，而是一次深度的内存寻址与路径搜索。- 了解了其背后的
type_info结构，你就理解了为什么它只能作用于多态对象。
下一篇预告：聊完了运行时的类型博弈，我们要回到代码编写时的权力控制。为什么protected在 C++ 中被认为是一个“危险”的折中？
➡️《你真的了解C++吗》No.027：访问权限：不仅仅是访问控制——受保护成员的语义陷阱。
（支持资料、图片参考_相关定制）_文章底部可以扫码)
（支持资料、图片参考_相关定制）_文章底部可以扫码)
