在C++
在C ++中,一个类别在一个类A成员函数中与Ref-Qualifier无需参考函数的成员函数过载。但与此同时,可以从父类中继承一个成员函数,并在子类中过载,如示例:
struct A {
void f() {}
//void f() & {} //overload error everywhere
};
struct B : A {
using A::f;
void f() & {} //ok everywhere
};
int main() {
B b;
b.f(); //ok in GCC only
}
仅在f
的调用期间,Clang抱怨呼叫成员函数“ f”是模棱两可的
。但是GCC在没有任何错误的情况下接受该程序,演示: https://gcc.godbolt.org.godbolt.org/5zzbwcs/5zzbwcs977 < /a>
哪个编译器在这里?
In C++ one cannot overload in one class a member function with ref-qualifier with a member function without ref-qualifier. But at the same time it is possible to inherit one member function from a parent class and overload it in a child class as in the example:
struct A {
void f() {}
//void f() & {} //overload error everywhere
};
struct B : A {
using A::f;
void f() & {} //ok everywhere
};
int main() {
B b;
b.f(); //ok in GCC only
}
Only during the invocation of f
, Clang complains that call to member function 'f' is ambiguous
. But GCC accepts the program without any error, demo: https://gcc.godbolt.org/z/5zzbWcs97
Which compiler is right here?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
GCC是正确的接受这一点,但情况最近发生了变化。当前的措辞是,在类忽略的(基本级)声明中使用dem> 是模棱两可的(从某种意义上说,这比解决过载更严格,部分是因为没有参数列表但是)与班上的其他声明。
void()
和void()&amp;
成员在这个意义上是模棱两可的,因此bf
仅找到b
' sf
,呼叫有效。在上一篇文章(在撰写本文中,这意味着“已发布”)版本的标准版本,这两个功能都可以使用,因为
&amp;
将它们区分开(从某种意义上甚至更严格),这将是不仅使呼叫含糊不清(正如Clang所说),而且要完全不明显,因为检查了基本和衍生的级功能,以过载兼容性。GCC is correct to accept this, but the situation changed recently. The current phrasing is that a using-declaration in a class ignores (base-class) declarations that would be ambiguous (in a sense that is more strict than for overload resolution, partly because there is no argument list yet) with other declarations in the class.
void()
andvoid() &
members are ambiguous in this sense, sob.f
finds onlyB
’sf
and the call is valid.In previous (as of this writing, that means “published”) versions of the standard, both functions would be made available because the
&
distinguished them (in a sense that is even stricter), which would not only render the call ambiguous (as Clang says) but be ill-formed outright because the base- and derived-class functions were checked for overload compatibility which they lack.