成员函数指针不可直接转为void*，因其实现依赖ABI（如虚函数、继承结构），强转属未定义行为；安全替代方案是std::function配合lambda捕获this，实现可存储、可传递、可调用的绑定。
成员函数指针不是普通函数指针
直接用 reinterpret_cast<void></void> 强转成员函数指针（如 &MyClass::foo）到 void* 是未定义行为，多数编译器会报错或返回错误值。这是因为 C++ 标准规定成员函数指针的底层表示与平台、ABI、类是否有虚函数/多重继承强相关——它可能是一个 4 字节偏移量（简单单继承），也可能是 12 或 16 字节结构（含 this 调整值、vtbl 偏移等）。
常见错误现象：error: cannot convert ‘void (A::*)()’ to ‘void*’；或者转换后调用崩溃，this 指针错位。
- 不要假设成员函数指针可被当作地址直接使用
- 不要在跨编译器/跨 ABI 场景下序列化或保存其原始二进制值
- 即使在同编译器下，
sizeof(void (A::*)())可能 ≠sizeof(void (*)())
用 std::function + lambda 捕获 this 是最安全的“取址”替代方案
如果你真正想要的是“把某个对象的某个成员函数绑定为可调用实体”，那本质需求不是“内存地址”，而是“可存储、可传递、可延迟调用”。此时 std::function 配合捕获 lambda 是标准、可移植、零成本抽象（优化后通常不比裸指针慢）。
struct Widget {
int x = 42;
int get_x() const { return x; }
};
<p>Widget w;
std::function<int()> f = [&w]() { return w.get_x(); };
// 现在 f 可存、可传、可调用：f()
- lambda 捕获
[&w]生成闭包，std::function内部存储该闭包对象 - 没有虚函数调用开销（如果 lambda 是平凡的，且编译器内联成功）
- 避免了成员函数指针的 ABI 不透明性问题
真要挖底层地址？只能靠编译器特定扩展 + 严格限定场景
仅限调试、Hook、逆向或极特殊系统编程，且只在明确目标平台和编译器（如 x86-64 Linux + GCC/Clang）下可行。GCC 提供 __builtin_constant_p 和非标准 reinterpret_cast 解包方式，但必须配合 -fno-rtti -fno-exceptions 并禁用虚函数。
立即学习“C++免费学习笔记（深入）”；
// ⚠️ 极度危险：仅作演示，不可用于生产
struct Plain {
int foo() { return 1; }
};
Plain p;
auto pmf = &Plain::foo;
<p>// GCC/Clang 下，对无虚函数的单继承类，有时可这样取：
void<em> addr = nullptr;
memcpy(&addr, &pmf, sizeof(addr)); // 依赖 sizeof(pmf) == sizeof(void</em>)
// 此时 addr 可能是真实代码地址（需 objdump 验证）
- 必须确保类是 POD-like、无虚表、无虚继承、无多重继承
- 必须关闭 RTTI 和异常（否则成员函数指针结构体含额外字段）
- 不同优化等级（
-O0vs-O2）可能导致布局变化 - MSVC 完全不保证这种 memcpy 行为有效，其成员函数指针始终是 struct
为什么 std::mem_fn 不解决“取地址”问题
std::mem_fn(&MyClass::func) 返回的是一个可调用对象，但它内部仍封装着成员函数指针本身，并未暴露底层地址。它只是对 .* 和 ->* 的泛化包装，底层仍是标准规定的黑盒类型 R (T::*)()。
-
std::mem_fn不能转成void*，也不能用reinterpret_cast拆解 - 它比裸成员函数指针更重（有模板实例化开销），但语义更清晰
- 若你看到某库文档说 “
std::mem_fn可以获取地址”，那是误导——它只是让你少写 lambda
实际工程中，所谓“获取成员函数指针的内存入口地址”，99% 的情况其实是误把“绑定调用”当成了“取地址”。真正需要裸地址的场景极少，而一旦涉及，就必须放弃可移植性，直面 ABI 细节——这时候，objdump -d 查符号、用 GDB 打印 &MyClass::func 的实际值、再比对反汇编，比任何通用代码都可靠。
