C++如何用typeid获取类名详解

typeid(T).name()不可靠，因返回编译器特定mangled名，标准不保证可读、稳定或跨平台；推荐用__PRETTY_FUNCTION__配合宏提取类名，零开销且三编译器兼容。

在 C++ 中，typeid 确实能获取类型信息，但直接用它拿“类的名称字符串”有严重陷阱——typeid(T).name() 返回的是编译器内部的 mangled 名，不是可读的类名，且标准不保证可移植。

为什么 typeid(T).name() 不可靠

不同编译器对同一类名生成的 name() 结果完全不同：g++ 返回类似 N5MyLib7MyClassE 的 mangling 字符串，MSVC 可能返回 class MyLib::MyClass，而 clang 行为又略有差异。更关键的是，C++ 标准只要求 name() 返回“实现定义的字符串”，不承诺可读、不承诺稳定、甚至不承诺唯一。

• 即使加 abi::__cxa_demangle（g++）或 UnDecorateSymbolName（MSVC），也只解决部分平台问题，无法跨平台
• typeid 对模板实例化类型、带 cv 限定符的类型返回名可能含空格或括号，解析困难
• 运行时开销虽小，但在 hot path 中频繁调用仍需留意

用宏 + __PRETTY_FUNCTION__ 提取类名（推荐）

这是目前最实用、跨编译器（g++/clang/MSVC 均支持）、零运行时开销的方案。原理是利用函数签名字符串中隐含的类名，再通过预处理器宏截取。

#define CLASS_NAME_STR(x) []{ \
    constexpr const char* s = __PRETTY_FUNCTION__; \
    constexpr size_t len = sizeof(__PRETTY_FUNCTION__) - 1; \
    constexpr size_t start = /* 找到 'x' 在 s 中的位置逻辑 */; \
    /* 实际项目中建议用更健壮的 constexpr 解析，或退而求其次用 __func__ + 类名硬编码 */ \
    return "MyClass"; \
}()

更现实的做法是定义一个简洁宏：

#define GET_CLASS_NAME() \
    ([]{ \
        static constexpr const char* s = __PRETTY_FUNCTION__; \
        constexpr size_t offset = []{ \
            constexpr size_t n = sizeof(__PRETTY_FUNCTION__) / sizeof(char); \
            size_t i = n; \
            while (i-- > 0 && s[i] != ':') {} \
            return i > 0 ? i + 1 : 0; \
        }(); \
        constexpr size_t len = []{ \
            constexpr size_t n = sizeof(__PRETTY_FUNCTION__) / sizeof(char); \
            size_t i = offset; \
            while (i < n && s[i] != ']' && s[i] != '(' && s[i] != ' ') ++i; \
            return i - offset; \
        }(); \
        char buf[len + 1]{}; \
        for (size_t i = 0; i < len; ++i) buf[i] = s[offset + i]; \
        return buf; \
    }())

注意：上面是示意逻辑，真实项目中更常用简化版（牺牲一点通用性换可维护性）：

#define CLASS_NAME_STR(cls) #cls

适用于已知具体类名的场景，如日志、断言、反射注册等。

运行时需要动态类名？考虑手动注册 + std::map

如果真要运行时根据对象指针/引用拿到可读类名（比如序列化、调试器集成），typeid 仍是起点，但必须配合 demangling 和缓存：

• Linux/g++：用 abi::__cxa_demangle 处理 typeid(obj).name()，结果缓存到 static std::unordered_map 避免重复解析
• Windows/MSVC：用 UnDecorateSymbolName，注意传入缓冲区大小和标志位 UNDNAME_NAME_ONLY
• 务必检查返回值是否成功，失败时 fallback 到 typeid(obj).name() 原始字符串
• 避免在多线程高频路径中首次调用 demangle（可能触发锁），提前初始化缓存

真正需要类型反射？别只盯着 typeid

C++20 的 std::source_location 和宏可以辅助构建轻量反射；更严肃的需求应考虑：

• 第三方库如 magic_enum（枚举）或 RTTR（运行时类型反射），它们通过宏注入元信息
• 自己用 CRTP 模式在基类中强制派生类提供 static constexpr const char* name()
• 构建时代码生成（如基于 Clang AST 的工具）产出头文件，绕过运行时解析

硬啃 typeid 的 name() 是在和编译器实现细节较劲，多数时候属于过早优化或设计错位。