成员指针是“偏移量 + 类型信息”的组合，非内存地址，须配合对象用。 或 -> 调用；声明调用复杂，不支持虚函数动态绑定，类型严格区分 const/noexcept 等，容器存储需类型安全方案。
成员指针不是普通指针，不能直接解引用
它本质是“偏移量 + 类型信息”的组合，不是内存地址。你不能像 int* p = &x; *p = 42; 那样对成员指针用 * 或 ->——编译器会直接报错 error: cannot apply indirection to member pointer。
必须配合具体对象（或指针）使用运算符 .*（对象）或 ->*（对象指针）才能调用：
struct S {int x = 10; void f() {}}; int S::* pm = &S::x; void (S::* pf)() = &S::f; <p>S s; s.<em>pm = 42; // ✅ 正确：用 .</em> 绑定对象 (s.*pf)(); // ✅ 正确：调用成员函数 </p><p>S<em> ps = &s; ps-></em>pm = 99; // ✅ 正确：用 -><em> 绑定指针 (ps-></em>pf)(); // ✅ 常见错误是写成 *pm 或 pm->f()，这在语法上完全不合法。
成员函数指针的声明和调用比普通函数指针复杂得多
它必须显式带上类名、const 限定、noexcept、参数列表，甚至 volatile ——漏一个就类型不匹配。比如 void (S::*)() 和 void (S::*)() const 是两种完全不同的类型。
立即学习 “C++ 免费学习笔记（深入）”；
实操建议：
- 用
auto推导简化声明：auto pf = &S::f; - 传参给模板或函数时，优先用模板参数推导，避免手写冗长签名
- 注意虚函数：成员函数指针调用的是静态绑定的版本，不走虚表；要动态分发得用虚函数本身，不是靠指针
- 性能上，成员函数指针调用开销略高于普通函数指针（尤其涉及多重继承时需调整 this），但现代编译器通常能内联优化掉
数组 / 容器里存成员指针要小心类型擦除和生命周期
你不能把 int S::* 和 double S::* 放进同一个 std::vector，因为它们是不同底层类型。强行用 void* 或 std::any 存会丢失类型信息，取出来时无法安全还原。
常见场景是“配置驱动的字段访问”，比如解析 JSON 后按字段名映射到结构体成员。这时更稳妥的做法是：
- 用
std::variant<int s:: double std::string></int>（C++17+） - 或封装为访问器对象：
struct FieldAccessor {virtual void set(S&, const std::string&) = 0; }; - 避免跨 DLL 边界传递成员指针：不同模块的 ABI 可能对成员指针布局有差异，尤其是 MSVC 和 GCC 不兼容
成员指针在模板元编程中容易误用 std::is_member_pointer
这个类型特征只检测“是否为成员指针类型”，但不会告诉你它指向什么——int S::* 和 void (S::*)() 都返回 true，但后续操作完全不同。
典型坑点：
- 用
std::invoke时，如果传入的是成员数据指针，必须提供对象；如果是成员函数指针，还要确保参数个数 / 类型匹配 - 泛型代码里别假设
T是成员函数指针就直接(obj->*t)(args……)，先用std::is_member_function_pointer_v<t></t>分支判断 - Clang 和 GCC 对空基类优化下的成员指针偏移计算可能有细微差异，调试时别全信打印出的数值
真正麻烦的从来不是怎么写出来，而是怎么让不同类型、不同继承层次、不同 const/volatile 修饰的成员指针，在同一套泛型逻辑里不出错——这时候往往得退一步，用标签分派或概念约束来收口。
