关于友元函数的一个问题
我最近遇到了一个关于从 xml 生成类的第三方库的问题。其要点如下:
class B;
class A
{
void doSomething();
friend class B;
};
class B
{
void doSomething();
void doSomethingMore()
{
doSomething();
}
};
编译器将对函数 doSomething()
的调用标记为不明确,并将其标记为编译器错误。很容易理解为什么会出现错误。B 类
是A 类
的友元,B 类
的每个成员都可以访问所有A 类
的成员。重命名这两个函数解决了我的问题,但它让我想到,在这种情况下,编译器不应该优先考虑类自己的成员函数,而不是它是朋友的另一个类中的函数吗?
注意:明天我会更新编译器版本详细信息。需要在工作场所检查确切的版本详细信息。我想我应该把它们放在第一位..:(
[问题更新和解决方案]
我再次检查了一个小示例程序,但问题不在于友元函数引起的歧义。第三方库在内部生成具有相同签名且位于同一类内的函数,这会导致歧义。谢谢各位的回复,至少纠正了我的错误观念:)
I faced a problem recently with a 3rd party library which generates classes from a xml. Here is a gist of it:
class B;
class A
{
void doSomething();
friend class B;
};
class B
{
void doSomething();
void doSomethingMore()
{
doSomething();
}
};
The compiler flags call to the function doSomething()
as ambiguous and flags it as an compiler error. It is easy to understand why it gives the error.Class B
being friend of class A
, every member of class B
has access to all the members of class A
. Renaming of the either of functions resolved my problem but it got me thinking that shouldn't in this case the compiler should give a priority to the class's own member function over the function in another class of which it is a friend?
Note: I will update the compiler version details tomorrow..Need to check the exact version details at the workplace. I guess i should have got them in first place..:(
[Problem Update & Resolution]
I checked out again with a small sample program and my bad the problem is not with the ambiguity due to friend functions. The 3rd party library internally generates a function with the same signature and inside the same class which causes the ambiguity. Thanks for the replies, at least my misconception got corrected :)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
没有任何歧义。 A 中调用的函数需要 A 实例。 B 中调用的函数需要 B 实例。
doSomethingMore 在 B 实例上调用,因此被调用的函数是 B 中的函数。
您似乎误解了友谊。这意味着,在这种情况下,给定 A 的实例,B 的成员函数可以调用 A::doSomething() 函数或在 A 中执行具有私有访问权限的任何其他操作。
There is no ambiguity. The function called in A requires an A instance. The function called in B requires a B instance.
doSomethingMore is called on a B instance and therefore the function that gets called is the one in B.
You seem to have misunderstood friendship. All it means is that, in this case, given an instance of A, member functions of B can call the A::doSomething() function or do anything else in A that has private access.
你的例子绝对没有歧义。正如您所描述的那样,使一个班级成为另一个班级的朋友对名称查找没有影响。 “很容易理解……”的解释从语言的角度来看并没有多大意义。
虽然损坏的编译器可能会按照您所描述的方式运行,但很可能您错过了某些内容,并且产生歧义的原因是不同的。
There's absolutely no ambiguity in your example. Making one class friend of another has no such effect on the name lookup as you describe. The "It is easy to understand..." explanation does not really make much sense from the language point of view.
While it is possible that a broken compiler might behave the way you describe, most likely you missed something and the reason for the ambiguity is different.