RTTI 的基本原理与成本
RTTI 是什么
运行时类型信息（RTTI） 是 C++ 提供的一组机制，用于在运行时查询对象的实际类型。常见的入口包括 dynamic_cast 和 typeid，它们依赖对象的多态结构来产生和使用类型信息。通过 RTTI，我们可以在不知道具体派生类型的情况下进行安全的下转或类型比较，从而实现更灵活的多态行为。
在实现层面，RTTI 需要编译器在对象的布局中附加描述符，通常与虚函数表（vtable）和每个对象的动态类型标记相关联。这个描述符用于在运行时区分不同的派生类型，并帮助执行 动态下转和类型识别 的操作。随着对象的多态性增强，RTTI 的存在成为一种必要的运行时元信息来源。
开销的来源
真正的开销来自于执行 动态下转、typeid 的运行时检查，以及在多态对象上进行的指针调整。在调用 dynamic_cast 时，编译器需要查找目标类型的 RTTI 描述符，并进行一致性验证，这会带来额外的分支和内存访问成本。
typeid 的成本 取决于对象是否为多态类型，以及你获取的是否是运行时类型。对于多态对象，typeid 访问通常涉及对虚表的查询和类型信息的解析，因此也会带来一定的运行时开销。总体来说，RTTI 的成本并不是每次操作都显著，而是在高频使用的热路径中才显现出来。
编译器与库对 RTTI 的实现差异
不同的编译器对 RTTI 的实现与优化策略存在差异，GCC、Clang、MSVC 在默认行为、内存布局和优化阶段对 RTTI 的处理各不相同。对于开启 RTTI 的程序，这些差异往往影响到下转、类型识别以及编译器生成的代码规模。对于一些极端的场景，编译器还提供对 RTTI 的开关选项，影响整个程序对运行时类型信息的支持。
在实际使用中，禁用 RTTI 的后果 会直接影响 dynamic_cast、typeid 等特性以及标准库的一些实现。若采用 -fno-rtti（GCC/Clang）或 /GR-（MSVC），需要确保持有的设计允许这样做而不影响基本的类型识别需求。整体来说，开启与关闭 RTTI 的选择会对代码规模、可维护性和跨模块行为产生综合影响。
dynamic_cast 的性能分析
动态下转的成本结构
在 指针 dynamic_cast 的路径中，只有在成功下转时才会产生实际的指针调整，否则通常需要完整的类型检查流程，这会带来额外的开销。引用类型的 dynamic_cast 若失败会抛出异常，成本往往更高，因为除了检查外还要处理异常路径。
硬件层面，分支预测与缓存命中率 会在多态对象较多的场景中显著影响 dynamic_cast 的性能。若下转路径较长且分支不可预测，CPU 的分支预测失误会带来额外的指令拉取与执行周期。
与 static_cast 和 typeid 的对比
static_cast 在没有运行时类型概率支撑的前提下可以提供更高的性能，因为它避免了运行时的类型检查。但前提是你明确知道对象的实际类型且确保类型安全。这与 dynamic_cast 的运行时检查形成对照，后者在保障类型安全的同时带来额外成本。
typeid 主要用于确定运行时对象的确切类型，而非进行安全的下转。对于完全类型比较的场景，typeid 可以提供明确的判定，但在多态场景中的混合使用，dynamic_cast 的灵活性通常更高。而在需要严格区分运行时动态类型的逻辑中，dynamic_cast 的路径会比 typeid 更直观和可维护。
微基准与实际场景测量建议
在设计对比时，优先在真实场景或接近实际负载的微基准中评估。微基准应覆盖热路径，如频繁的下转或类型识别操作，以及可能的失败路径。测量时应使用稳定的測速工具与高分辨率时钟，避免误差影响判断。
在评估时，关注 缓存友好性与分支预测 的影响，以及不同编译选项对结果的影响。对于跨平台应用，务必在目标编译器与目标 CPU 上进行测量，以获得可复现的结果。
#include <iostream>
class Base { public: virtual ~Base() {} };
class DerivedA : public Base {};
class DerivedB : public Base {};void try_cast(Base* p) {if (auto d = dynamic_cast(p)) {std::cout << "DerivedA" << std::endl;} else if (auto d2 = dynamic_cast(p)) {std::cout << "DerivedB" << std::endl;} else {std::cout << "Unknown" << std::endl;}
}
#include <typeinfo>
#include <iostream>
class Base { public: virtual ~Base() {} };
class DerivedA : public Base {};void check_type(Base* p) {if (typeid(*p) == typeid(DerivedA)) {std::cout << "It's DerivedA" << std::endl;} else {std::cout << "Unknown type" << std::endl;}
}
取舍与设计实践
场景分析：何时需要 RTTI 的动态下转
在需要对同一基类下的多种派生对象进行区分并执行不同逻辑时，动态下转提供了方便而安全的路径。尤其当对象集合中包含不同实现且无法通过统一的虚函数接口完全表达时，动态下转成为一种可控的运行时策略。
然而，当业务逻辑可以通过统一的接口、明确的虚方法派发来实现时，过度依赖 RTTI 基于类型的分支 会增加维护成本与性能波动。因此，权衡点通常在于热路径的比例以及对运行时类型信息的真实需求。
设计模式替代
虚函数接口、访问者模式、以及双分派等设计手段可以在很多场景下替代直接的类型识别逻辑。通过将行为挪到多态对象的实现中，或通过访问者对不同类型执行专门逻辑，可以在保持可扩展性的同时降低对 RTTI 的依赖。
在结构清晰且类型关系稳定的系统中，减少外部类型判断、提升接口的统一性，往往能够带来更好的可维护性和更稳定的性能表现。跨团队协作的代码库中，清晰的接口和模式化的处理路径也有助于减少对 RTTI 的潜在需求。
编译选项与平台差异
如果在某些平台或构建配置中可以完全移除 RTTI，禁用 RTTI 的选项（如 -fno-rtti、/GR-）可能带来代码尺寸和某些路径的性能改善。然而，这也会使 dynamic_cast、typeid 的可用性下降，甚至影响标准库的某些实现。
跨平台开发时，需要考虑 ABI 兼容性与运行时行为 的差异，以及不同编译器对禁用 RTTI 的处理是否一致。综合评估后再决定是否在目标平台启用或禁用 RTTI，以确保功能性、性能与可维护性之间的平衡。
