不能安全获取类成员函数指针的内存入口地址，因其本质是编译器私有结构体，含偏移、vtbl索引等多字段，reinterpret_cast为void*或uintptr_t属未定义行为，跨平台/编译器/优化等级极易崩溃。
不能安全获取类成员函数指针的“内存入口地址”——它根本就不是单一地址，而是编译器私有结构体。所谓“取地址”得到的 &T::func 是一个类型为 void (T::*)() 的对象，其二进制布局可能含偏移、vtbl 索引、甚至多个字段，直接 reinterpret_cast 成 void* 或 uintptr_t 在标准 C++ 中是未定义行为，且跨平台/编译器/优化等级极易崩溃。
为什么 &T::func 不能当普通函数地址用
成员函数调用必须携带 this 调整逻辑，而普通函数指针不包含该语义。C++ 标准明确禁止将 T::* 类型转为整数或 void*（[expr.cast]），所有主流编译器（GCC/Clang/MSVC）都会在编译期报错，例如：
C2440: cannot convert from 'void (__thiscall A::* )(void)' to 'void *'
即使你绕过编译错误（如用 union 或 memcpy），运行时行为仍不可靠：
- 虚函数：得到的是 vtable 槽位偏移，不是代码地址
- 多重继承或虚继承：成员指针可能占 12–16 字节，前 8 字节未必是可执行地址
- -O2 下内联或 devirtualize 后，原函数可能根本不存在于代码段中
哪些场景下“看似成功”但实际危险
某些简单单继承、非虚、无 RTTI 的 case 下，union_cast 可能输出一个看起来像地址的数值（比如 0x4012a0），但这只是巧合：
- 它依赖 Itanium ABI 下 GCC 的具体布局（前 8 字节常为 this 偏移或函数地址）
- 启用
-fPIC或链接时优化（LTO）后，该值可能失效 - 换成 MSVC x64，默认 8 字节布局，但含义不同；若类有虚基类，立即涨到 16 字节
- 一旦你把这个值传给
dlsym、GetProcAddress或写入 JIT 内存，大概率 segfault
真正可行的替代路径
如果你目标是回调、hook、调试符号匹配或跨语言绑定，请放弃“提取地址”，改用语义等价但安全的方案：
- 需要把成员函数当回调传给 C API？包装成 static 函数 +
void*user_data：static void wrapper(void* obj) { static_cast(obj)->func(); } - 想在运行时查某个函数的真实代码地址？对**静态或自由函数**用
dladdr（Linux）或SymFromAddr（Windows），而非对&T::func操作 - 调试时定位虚函数实现？用调试信息（DWARF/PDB）查 vtable slot 对应的 symbol，而不是从成员指针硬解
- 热重载或动态 patch？用 thunk（如 inline asm jmp 到新地址），thunk 地址可取，但成员指针本身不可 patch
最常被忽略的一点：哪怕你用 union 或 asm offset “拿到”了某个数值，它也不是稳定可执行的入口——它只在特定 ABI、特定编译选项、特定继承结构下，恰好指向某条指令。换一台机器、升一个编译器版本、加一个虚函数，这个数值就失去意义。真正的可移植性，来自封装调用协议，而不是搬运裸字节。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
