关于c ++：为什么在覆盖虚函数时不考虑访问限定符？

c++inheritancemethod-overridingvirtual-functions

Why access qualifier is not considered when virtual function is overridden?

以下代码打印了"我是B！".有点奇怪，因为B::foo()是私有的。关于A* ptr我们可以说它的静态类型是A(foo是公共的)，动态类型是B(foo是私有的)。所以我可以通过指向A的指针调用foo。但这样我就可以进入B的私有功能。是否可以将其视为封装冲突？

由于访问限定符不是类方法签名的一部分，因此可能会导致这种奇怪的情况。当虚函数被重写时，为什么不考虑C++访问限定符？我能禁止这样的案件吗？这个决定背后的设计原则是什么？

活生生的例子。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

#include <iostream>

class A
{
public:
virtual void foo()
{
std::cout <<"I'm A!
";
};
};

class B: public A
{
private:
void foo() override
{
std::cout <<"I'm B!
";
};
};

int main()
{
A* ptr;
B b;

ptr = &b;

ptr->foo();
}

相关讨论

你打电话给A::foo()，这是公开的。你不能直接打电话给b.foo()。最大的问题是为什么B::foo是私有的？
@博佩尔森当然。但我们称之为B::foo。
@是的，这是个问题。我认为编译器可以生成关于这个的警告。
假设您有一个函数void f(A* a) { a->foo(); }是一个单独编译的文件。编译器如何知道您以后是否传递了B、C或A？.接口表示该函数是公共的，所以它是公共的。
您正在调用public A::foo方法。它不是一个封装冲突，原因与没有封装冲突发生的原因相同，仅仅是因为A::foo(不是虚拟的)调用了一些私有方法或修改了一些私有字段。如果将此方法保留为公共方法，但正在执行外部代码不允许执行的操作，则可能会出现封装冲突。
@bo persson我的意思是警告，当它在基类中是公共的时，它指向私有重写函数。我的观点并不太复杂。
@维克多，你为什么要警告？这个案子很好，我看不出有什么问题。如果你在那里有问题，那么这可能是你设计上的一个缺陷。
@user0042我同意基类中的公共函数变为私有是设计错误。我的观点是编译器可以捕获这个错误。
没有要捕获的错误。在class final功能可用之前，我一直有意使用这些东西。
@用户0042您能举个例子，这个方法是如何与final交叉的吗？
@viktor并不是这样，但它可以防止在派生类中进一步重写(使得进一步派生类变得无用)。
@这是一个在StateBase类中有意使用的例子。应该强制继承类坚持静态多态接口。
@user0042谢谢举例！
访问控制适用于声明。命名声明在基类中。访问控制不适用于对象(希望如此)。
访问控制适用于范围中的名称。名称B::foo是私有的，但这并不意味着"功能是私有的"。类似地，您可以返回指向公共函数等中私有变量的指针。
有一种C++编码风格，其中所有的虚拟函数都是私有的，并且通过非虚拟包装器暴露给用户。这是完全合法的。

你有多个问题，所以我会逐一回答。

当虚函数被重写时，为什么不考虑C++访问限定符？

因为在所有重载解析之后，编译器都会考虑访问限定符。这种行为由标准规定。

例如，请参见关于CPPreference：

Member access does not affect visibility: names of private and privately-inherited members are visible and considered by overload resolution, implicit conversions to inaccessible base classes are still considered, etc. Member access check is the last step after any given language construct is interpreted. The intent of this rule is that replacing any private with public never alters the behavior of the program.

下一段描述了您的示例所演示的行为：

Access rules for the names of virtual functions are checked at the call point using the type of the expression used to denote the object for which the member function is called. The access of the final overrider is ignored.

另请参阅此答案中列出的操作顺序。

我能禁止这样的案件吗？

不。

我认为你永远也做不到，因为在这种行为中没有违法的地方。

这个决定背后的设计原则是什么？

只是为了澄清：通过这里的"决策"，我暗示编译器在过载解析之后检查访问限定符的规定。简短的回答是：防止在更改代码时出现意外。

要了解更多详细信息，我们假设您正在开发一些类似于此的CoolClass

1
2
3
4
5
6

class CoolClass {
public:
void doCoolStuff(int coolId); // your class interface
private:
void doCoolStuff(double coolValue); // auxiliary method used by the public one
};

假设编译器可以基于公共/私有说明符进行重载解析。然后以下代码将成功编译：

1
2
3

CoolClass cc;
cc.doCoolStuff(3.14); // invokes CoolClass::doCoolStuff(int)
// yes, this would raise the warning, but it can be ignored or suppressed

然后在某个时刻，您发现您的私有成员函数实际上对类客户机有用，并将其移动到"公共"区域。这会自动改变先前存在的客户机代码的行为，因为现在它调用CoolClass::doCoolStuff(double)。

因此，应用访问限定符的规则是以不允许这种情况的方式编写的，因此您将在一开始就得到"含糊不清的调用"编译器错误。而虚拟函数并不是特殊情况，原因是相同的(见此答案)。

是否可以将其视为封装冲突？

不是真的。通过将指向类的指针转换为指向其基类的指针，您实际上会说："在此，我希望将此对象B用作对象A"-这是完全合法的，因为继承意味着"原样"关系。

因此，问题是，您的示例是否可以被视为违反了基类规定的契约？看来是的，可以。

有关其他解释，请参阅此问题的答案。

附笔。

别误会我，这并不意味着你不应该使用私有虚拟功能。相反，它通常被认为是一个好的实践，看这条线。但他们应该是非常底层阶级的私有。因此，归根结底，您不应该使用私有虚拟函数来破坏公共契约。

除非您有意通过指向接口/基类的指针强制客户机使用您的类。但有更好的方法可以做到这一点，我相信这些讨论超出了这个问题的范围。

访问限定符(如public、private等)是编译时特性，而动态多态性是运行时特性。

当调用virtual函数的private重写时，您认为运行时应该发生什么？一个例外？

Can it be considered as encapsulation violation?

不，因为接口已经通过继承发布，所以没有。

用派生类中的private函数重写基类中的public virtual函数是非常好的(而且可能是有意的)。

相关讨论