将成员函数转换为指向成员函数的指针

Question

Clang,GCC,MSVC对成员函数的转换有不同的看法。 谁是对的？

https://gcc.godbolt.org/z/QNsgwd

template<typename T>
struct a
{
    template <typename... Args>
    void va(Args...) {}

    template <typename X>
    void x(X) {}

    void y(int) {}
};

struct b : a<b>
{
    void testva()
    {
        using F = void (a<b>::*)();

        F f = (F)&a<b>::va<int>; // gcc: error, msvc: error, clang: ok
    }

    void testx()
    {
        using F = void (a<b>::*)();

        F f = (F)&a<b>::x<int>;// gcc: error, msvc: ok, clang: ok
    }

    void testy()
    {
        using F = void (a<b>::*)();

        F f = (F)& a<b>::y; // gcc: ok, msvc: ok, clang: ok
    }
};

Answer 1

testx 和 testy 格式正确，所以 gcc 对 testx 的看法是错误的。但标准对testva 有点模糊。

从最简单的开始，在testy 中，表达式&a<b>::y 命名了一个未重载的非模板函数，因此它的类型为void (a<b>::*)(int)，无需进一步分析。从任何指向成员函数的指针到任何其他指向成员函数的指针的转换都是格式良好的reinterpret_cast，除非转换回原始类型，否则会产生未指定的结果，并且 C 风格的转换可以做reinterpret_cast可以。

对于模板函数，我们有[over.over]/1-2:

使用不带参数的重载函数名称在某些上下文中被解析为函数、函数指针或重载集中特定函数的成员函数指针。函数模板名称被认为是在此类上下文中命名一组重载函数。如果F（在可能应用函数指针转换之后）与FT 相同，则选择类型为F 的函数作为上下文中所需目标类型的函数类型FT。目标可以是

• ...

• 显式类型转换（[expr.type.conv]、[expr.static.cast]、[expr.cast]），

• ...

如果名称是函数模板，则进行模板实参推导（[temp.deduct.funcaddr]），如果实参推导成功，则使用生成的模板实参列表生成单个函数模板特化，即添加到考虑的重载函数集。 [ 注意： 如 [temp.arg.explicit] 中所述，如果推导失败并且函数模板名称后跟显式模板参数列表，则 template-id 为然后检查它是否标识了单个函数模板特化。如果是，则 template-id 被认为是该函数模板特化的左值。在该确定中不使用目标类型。 — 尾注 ]

所以这意味着我们首先尝试对a<b>::x<int> 进行模板参数推导，将其与目标类型void (a<b>::*)() 匹配。但是没有任何特化可以给出完全匹配，因为它们都有一个参数，而不是零，所以推论失败了。但根据注释，还有 [temp.arg.explicit]（C++17 中的第 3 段，4 in the latest C++20 draft）：

可以从显式模板参数列表中省略可以从默认模板参数推导出或获得的尾随模板参数。没有以其他方式推导的尾随模板参数包（[temp.variadic]）将被推导为模板参数的空序列。 ...在演绎完成但失败的上下文中，或在未完成演绎的上下文中，如果指定了模板参数列表，并且它与任何默认模板参数一起标识单个函数模板特化，则 template-id 是函数模板特化的左值。

在testx 中，template-id a<b>::x<int> 标识单个函数模板特化。因此它命名了该专业化，并且 C 风格的转换同样有效，结果未指定。

那么在testva 中，a<b>::va<int> 是否确定了一个专业化？当然可以通过[temp.arg.explicit]/9 使用该表达式来命名不同的专业：

模板参数推导可以扩展与模板参数包对应的模板参数序列，即使该序列包含显式指定的模板参数。

除了这个说“模板参数推导”。这里涉及的模板参数推导失败了，因为它需要与目标类型void (a<b>::*)() 不可能匹配。因此，没有什么能真正解释 a<b>::va<int> 是否标识了单个特化，因为没有描述其他获取额外模板参数的方法，或者标识了多个特化，因为它可以在具有匹配目标类型的其他上下文中有效使用。

Answer 2

叮当是对的

[expr.reinterpret.cast]/10

如果T1，“指向T1 类型的X 成员的指针”类型的纯右值可以显式转换为不同类型的“指向T2 类型的Y 成员的指针”类型的纯右值和T2 都是函数类型或都是对象类型。空成员指针值转换为目标类型的空成员指针值。此转换的结果未指定，但以下情况除外：

• 将“指向成员函数的指针”类型的纯右值转换为不同的指向成员函数的指针类型并返回其原始类型会产生指向成员的原始值。
• 将“指向T1 类型X 的数据成员的指针”类型的纯右值转换为“指向T2 类型的Y 数据成员的指针”类型（其中T2 的对齐要求不比T1) 更严格，并且返回其原始类型会产生原始指向成员的值。

&a<b>::va<int> et al. 是 prvalue 类型的“指向a<b> 类型void(int) 的成员的指针”并将其转换（不调用结果函数值未指定的指针）是合法的。

Answer 3

让我们简化为这个例子：

struct a {
    template <typename... Args>
    void va(Args...) {}

    template <typename X>
    void x(X) {}

    void y(int) {}
};

using no_args = void(a::*)();
using int_arg = void(a::*)(int);

让我们尝试以下四件事：

reinterpret_cast<no_args>(&MEMBER_FUNCTION);  // (1)
(no_args) &MEMBER_FUNCTION;  // (2)
(no_args) static_cast<int_arg>(&MEMBER_FUNCTION);  // (3)
int_arg temp = &MEMBER_FUNCTION; (no_args) temp;  // (4)

（将MEMBER_FUNCTION 替换为&a::va<int>、&a::x<int> 和&a::y）。

clang 编译所有这些。
gcc 使用 &a::va<int> 和 &a::x<int> 编译除 (2) 之外的所有内容。
MSVC 使用 &a::va<int> 编译除 (1) 和 (2) 之外的所有内容（但使用 &a::x<int> 很好）。

请注意，(3) 与 (4) 基本相同。

https://gcc.godbolt.org/z/a2qqyo 显示了一个例子。

从中可以看出&MEMBER_FUNCTION在模板的情况下并没有被解析为特定的成员函数指针，但是如果被解析了，则允许将其重新解释为另一个成员函数指针类型。

标准是怎么说的：

[over.over]/1:

使用不带参数的重载函数名称在某些上下文中被解析为函数、函数指针或重载集中特定函数的成员函数指针。 函数模板名称被认为是在此类上下文中命名一组重载函数。 如果 F（在可能应用函数指针转换之后）与 FT 相同，则选择具有 F 类型的函数作为上下文中所需的目标类型的函数类型 FT。 [ 注意：即在匹配指向成员函数的指针类型时，将忽略该函数所属的类。 —— 尾注 ] 目标可以是：
[...]
- 显式类型转换（[expr.type.conv]、[expr.static.cast]、[expr.cast]）

稍后给出的示例是：

int f(double);
int f(int);
void g() {
  (int (*)(int))&f;             // cast expression as selector
}

还有一些关于模板的引用：

[temp.deduct.funcaddr]/1:

模板参数可以从获取重载函数地址时指定的类型推导出来。 函数模板的函数类型和指定类型作为P和A的类型，按[temp.deduct.type]中的描述进行推演。

[temp.arg.explicit]/4

[...] 如果指定了模板参数列表，并且它与任何默认模板参数一起标识单个函数模板特化，则模板 ID 是函数模板特化的左值。

这似乎 MSVC 是对的。

&a::va<int> 不会被解析，除非您将其分配/强制转换为 void(a::*)(int)。您还应该能够将其分配给void(a::*)(int, char) 或void(a::*)(int, double, char)，其中Args 将分别推导出为{ int, char } 和{ int, double, char }。这意味着(no_args) &a::va<int> 应该 失败，因为有很多可能的Args 集合（它们都以int 开头，并且clang 过分热心地解决了它），并且没有一个取零参数，所以(no_args) &a::va<int> 是一个应该失败的static_cast。

至于&a::x<int>，只有一个可能的功能，所以它的工作方式应该和&a::y完全一样（但gcc还没有解决它）。