c – 使用nullptr作为参数的函数重载决策

请考虑以下代码.虽然fun的两个重载接受指针,但将nullptr传递给fun不会导致任何编译错误.然而,非常相似的函数bun无法编译.当我使用typeid(i).name()打印参数的类型时(修改代码只是为了打印)我得到相同的类型,只是int *.在有趣的案例中解决歧义的规则是什么,但是却没有成功?提前致谢!

#include <iostream>

struct Foo {
    int sth;
};

template< class U>
void fun(decltype(U::sth)* i){
    std::cout << "1" << std::endl;
}

template< class U>
void fun(U* i){
    std::cout << "2" << std::endl;
}

void bun(decltype(Foo::sth)* i){
    std::cout << "3" << std::endl;
}

void bun(Foo* i){
    std::cout << "4" << std::endl;
}

int main ( )
{
    fun<Foo>(nullptr);
    // bun(nullptr); --> call of overloaded 'bun(std::nullptr_t)' is ambiguous        
    return 0;          
}
-----------------------
output : 1

最佳答案 嗯,事实上,
GCC accepts your code, but Clang does not.因此,一开始,这个电话是否模糊不清楚.

你问什么规则解决了有趣案例中的含糊之处;海湾合作委员会显然认为有这样的规则.我认为GCC正在应用的规则是规则[over.match.best] /1.7,它更喜欢一个更专业的功能模板而不是一个不太专业的功能模板.

[temp.func.order]中描述了确定哪个函数模板比​​另一个更专业的过程,并在this SO answer中进行了详细解释.但是,当您尝试将此过程应用于两个有趣的过载时,您会注意到这个问题,我们遇到的问题是,在第一个重载中需要替换U的唯一合成类型需要有一个名为sth的成员,并且没有指定该成员的性质,尽管可能很清楚在第二个有趣的重载中演绎的人必须成功,无论什么类型是什么,编译器可能无法证明它.

这是CWG 1157.由于这个问题仍然没有提出解决方案,我不知道WG21是否打算让这个重载决议成功.

点赞