纸上谈“型”不如运行识“真”:深入 C++ RTTI 与多态的底层真相!

纸上谈“型”不如运行识“真”:深入 C++ RTTI 与多态的底层真相!

文章目录

在这里插入图片描述

本篇摘要

本文详解 C++ RTTI 的核心组成(typeid、dynamic_cast)、底层原理(vptr、vtable、继承关系图)及使用场景,强调其仅适用于多态类型,并分析其开销与设计原则,指导合理应用。


RTTI(Run-Time Type Information,运行时类型信息) 介绍

C++ 的 RTTI(Run-Time Type Information,运行时类型信息) 是一套在程序运行时查询和操作对象类型信息的机制。它主要用于在继承体系中安全地识别和转换对象的实际类型。


RTTI 的核心组成

C++ 标准库通过以下两个主要组件提供 RTTI 支持:

1. typeid 运算符
  • 用于获取对象或类型的类型信息
  • 返回一个 const std::type_info& 对象。
  • 可比较两个类型是否相同。
#include<iostream>#include<typeinfo>classBase{virtual~Base()=default;};// 必须有虚函数!classDerived:publicBase{};intmain(){ Base* b =newDerived(); std::cout <<typeid(*b).name()<< std::endl;// 输出实际类型(如 "7Derived") std::cout <<(typeid(*b)==typeid(Derived))<< std std::endl;// truedelete b;}
注意:只有多态类型(含虚函数的类)才能通过基类指针/引用正确识别派生类类型。否则 typeid 返回的是静态类型(即指针声明的类型也就是对应的Base)。

2. dynamic_cast 运算符
  • 用于安全地在继承层次结构中转换指针或引用(主要是向下转型,常用作子转父,然后父再转回子)。
  • 依赖 RTTI 信息进行运行时检查。
Base* b =newDerived(); Derived* d =dynamic_cast<Derived*>(b);if(d){ std::cout <<"Cast succeeded!"<< std::endl;}else{ std::cout <<"Cast failed!"<< std::endl;}
  • 指针版本:失败返回 nullptr
  • 引用版本:失败抛出 std::bad_cast 异常
同样要求:被转换的类型必须是多态类型(有虚函数),否则编译报错。

RTTI 如何工作?(底层原理)

下面我们简单说,就从编写完对应代码时候,对应编译器处理转化方面讲起:

① 编译器为多态类型做了什么?

当一个类被定义为多态类型时,编译器会在编译期自动插入额外的数据结构和指针,主要包括:

1. 虚函数表(vtable)

  • 每个多态类在程序中对应一个全局唯一的 vtable。
  • vtable 是一个函数指针数组,存储该类所有虚函数的地址(对应的虚表存储在只读数据段也就是静态储存区)。

重点来啦:现代主流编译器(如 GCC、Clang、MSVC)还会在 vtable 的开头或特定位置,存入一个指向 std::type_info 对象的指针;也就是说:vtable 不仅用于虚函数调用,也承载了类型信息。

2. 对象内存布局增加 vptr

每个多态类的对象在内存中的最开始处会隐式包含一个指针,称为 vptr(virtual table pointer);vptr 指向该对象所属类的 vtable。
例如:

Base obj;// 内存布局:// [vptr] → 指向 Base 的 vtable// [其他成员变量...]

注意:这个 vptr 是编译器自动添加的,程序员不可见,但真实存在。

3·类型继承关系图(type hierarchy graph)

  • 编译器在程序启动时已构建了一个 类型继承关系图(type hierarchy graph),记录了所有类之间的继承关系,也就是为什么我们使用dynamic_cast等的时候(多态时候),它可以判断是是否能转换,进而做出对应应答!

② 当我们调用对应接口,RTTI底层是如何实现呢?

因此当我们运行时候就会存在这样一个结构:

在这里插入图片描述
  • 上面也就是我们RTTI执行的时候需要走的途径(剩下还有就是编译器生成的对应类型继承关系图了)。
场景 1:typeid(obj)
Base* p =newDerived(); std::cout <<typeid(*p).name();

执行过程如下:

  • 程序通过 p 访问对象;
  • 从对象内存开头读取 vptr;
  • 通过 vptr → vtable;
  • 从 vtable 中取出 type_info 指针;
  • 返回对应的 std::type_info&。

因此,即使 p 是 Base 类型,typeid(p) 也能知道它实际指向的是 Derived 对象!

注意: 如果 Base 没有虚函数(非多态),则对象没有 vptr,编译器无法在运行时知道实际类型,此时 typeid(*p) 只能返回 Base(静态类型),且某些编译器甚至会直接报错或行为未定义。

场景 2:dynamic_cast<Derived*> ( p )

执行过程更复杂一些:

  • 同样通过 p 获取对象的 vptr → vtable → type_info(即实际类型 T);
  • 首先我们要先知道:编译器在程序启动时已构建了一个 类型继承关系图(type hierarchy graph),记录了所有类之间的继承关系;

这也就是RTTI核心(运行时检查目标类型 Derived 是否是 T 的基类或派生类?):

此时就是拿着对应type_info类型按照对应的继承关系图去对比,如果在里面存着这个继承关系也就是在里面就进行转化,不在进行异常处理。

  • 如果是 → 安全转换,计算偏移量(考虑多重继承),返回正确指针;
  • 如果不是 → 返回 nullptr(指针版本)或抛异常(引用版本)。
比如: 若 p 实际指向 OtherClass,而 OtherClass 与 Derived 无继承关系,则 dynamic_cast 失败。

std::type_info 类简介

  • 由编译器实现,不可复制(C++11 起可移动);
  • 主要成员:
    • name():返回类型的实现定义名称(通常是 mangled name,可用 c++filt 解码);
    • operator== / operator!=:比较两个类型是否相同;
    • before():用于 std::type_index 的排序(C++11)。

如:

std::cout <<typeid(int).name()<< std::endl; std::cout <<typeid(std::string).name()<< std::endl;
在这里插入图片描述
  • 这就是它们底层的类型表现形式!

解码操作:

在这里插入图片描述

  • 可以成功看到对应类型。

RTTI 的开销与争议

优点:
  • 实现安全的向下转型;
  • 支持运行时类型查询(调试、序列化、插件系统等场景有用)。
缺点:
  • 空间开销:每个含虚函数的类增加一个 type_info 对象;
  • 时间开销dynamic_cast遍历继承树,比 static_cast 慢;
  • 设计争议:频繁使用 RTTI 往往意味着面向对象设计不佳(应优先用虚函数实现多态,而非类型判断)。
许多高性能项目(如游戏引擎、嵌入式系统)会 禁用 RTTI(编译选项 -fno-rtti)以节省资源。

何时使用 RTTI?

场景是否推荐
安全向下转型(无法用虚函数替代)✅ 谨慎使用
调试/日志打印类型名✅ 可接受
序列化/反序列化框架✅ 合理
日常业务逻辑中频繁类型判断❌ 应重构为多态设计

禁用 RTTI操作

在 GCC/Clang 中:

g++ -fno-rtti main.cpp 

此时:

  • typeiddynamic_cast无法使用,编译报错;
  • 适合对性能/体积敏感的场景。

为什么非多态类型不支持 RTTI?

  • 非多态类 没有虚函数
  • 编译器 不会为其生成 vtable;
  • 对象内存中 没有 vptr;

因此,运行时无法获取其实际类型信息。

总结

特性说明
作用运行时获取类型信息、安全类型转换
前提类必须是多态类型(有虚函数)
核心工具typeiddynamic_caststd::type_info
性能有运行时开销,非零成本
最佳实践优先用虚函数,RTTI 仅作兜底方案
所以说 善用多态,少用类型判断,才是面向对象的精髓。

本篇小结

RTTI 是 C++ 实现运行时类型识别的关键机制,依赖虚函数表与 type_info,在多态类型中支持安全转型和类型查询,但存在性能开销,应优先通过虚函数实现多态,谨慎使用 RTTI。

Read more

Flutter for OpenHarmony:Flutter 三方库 dart_openai — 激发鸿蒙应用的 AIGC (AI 大模型/ChatGPT、Deepseek等) 无限创意(适配鸿蒙

Flutter for OpenHarmony:Flutter 三方库 dart_openai — 激发鸿蒙应用的 AIGC (AI 大模型/ChatGPT、Deepseek等) 无限创意(适配鸿蒙

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net。 Flutter for OpenHarmony:Flutter 三方库 dart_openai — 激发鸿蒙应用的 AIGC (AI 大模型/ChatGPT、Deepseek等) 无限创意(适配鸿蒙 HarmonyOS Next ohos) 前言 随着生成式 AI(AIGC)浪潮席卷全球,将大语言模型(LLM)的智慧集成到移动应用中已成为大势所趋。无论是智能对话、代码生成,还是图像创作,AI 正在重塑我们的交互方式。 在 Flutter for OpenHarmony 开发中,我们如何让鸿蒙应用直接对话全球顶尖的 AI 模型?dart_openai 库通过对 OpenAI API 的完美封装,

By Ne0inhk

4步创作革命!WAN2.2极速视频AI重新定义AIGC视频生产流程

4步创作革命!WAN2.2极速视频AI重新定义AIGC视频生产流程 【免费下载链接】WAN2.2-14B-Rapid-AllInOne 项目地址: https://ai.gitcode.com/hf_mirrors/Phr00t/WAN2.2-14B-Rapid-AllInOne 价值定位:打破专业壁垒的视频创作新范式 在AIGC视频生成领域,创作者长期面临"三高困境":技术门槛高、硬件要求高、时间成本高。传统工作流往往需要串联文本理解、图像生成、视频插值等多个模型,仅模型加载就需消耗数分钟,且80%以上的失败案例源于模型组合不当。WAN2.2-14B-Rapid-AllInOne(简称WAN2.2极速视频AI)以"一体化模型架构"直击行业痛点,将原本需要10+步骤的创作流程压缩至4个核心环节,在8GB显存设备上实现每分钟视频内容的高效生成。 这款由Phr00t团队开发的开源模型,通过"MEGA Merge"

By Ne0inhk

Dify v1.12.0深度适配DeepSeek-V3:支持LoRA微调注入、流式响应对齐、上下文长度动态扩展,附GitHub私有仓库验证清单

第一章:Dify v1.12.0与DeepSeek-V3集成概述 Dify v1.12.0 是一个面向 AI 应用开发的低代码平台,支持快速构建、调试和部署基于大语言模型的应用。该版本显著增强了对第三方大模型的兼容性,尤其在与国产高性能模型 DeepSeek-V3 的集成上实现了深度优化。通过标准化接口对接与上下文管理机制升级,开发者可无缝将 DeepSeek-V3 接入 Dify 的应用工作流中,实现高效推理与对话能力。 核心特性 * 支持通过 API Key 直接连接 DeepSeek-V3 模型服务 * 内置 Prompt 编排引擎,适配 DeepSeek-V3 的输入格式要求 * 提供实时日志追踪与 token 消耗统计功能 * 兼容 streaming 输出模式,提升用户交互体验 配置步骤 1. 登录 Dify 管理后台,

By Ne0inhk
【AI大模型前沿】通义万相Wan2.2:阿里270亿参数巨兽开源,消费级显卡就能跑,免费平替Sora上线

【AI大模型前沿】通义万相Wan2.2:阿里270亿参数巨兽开源,消费级显卡就能跑,免费平替Sora上线

系列篇章💥 No.文章1【AI大模型前沿】深度剖析瑞智病理大模型 RuiPath:如何革新癌症病理诊断技术2【AI大模型前沿】清华大学 CLAMP-3:多模态技术引领音乐检索新潮流3【AI大模型前沿】浙大携手阿里推出HealthGPT:医学视觉语言大模型助力智能医疗新突破4【AI大模型前沿】阿里 QwQ-32B:320 亿参数推理大模型,性能比肩 DeepSeek-R1,免费开源5【AI大模型前沿】TRELLIS:微软、清华、中科大联合推出的高质量3D生成模型6【AI大模型前沿】Migician:清华、北大、华科联手打造的多图像定位大模型,一键解决安防监控与自动驾驶难题7【AI大模型前沿】DeepSeek-V3-0324:AI 模型的全面升级与技术突破8【AI大模型前沿】BioMedGPT-R1:清华联合水木分子打造的多模态生物医药大模型,开启智能研发新纪元9【AI大模型前沿】DiffRhythm:西北工业大学打造的10秒铸就完整歌曲的AI歌曲生成模型10【AI大模型前沿】R1-Omni:阿里开源全模态情感识别与强化学习的创新结合11【AI大模型前沿】Qwen2.5-Omni:

By Ne0inhk