如何防止派生类使私有/受保护的虚拟函数公开？ [英] How to prevent derived class from making a private/protected virtual function public?

问题描述

有所有虚函数作为private或protected构造基类接口的好理由（参见 this ）。但是，那么如何防止派生类（可能在外部客户端手中）将私有虚拟函数设为公开？在几乎是您的中，作者讨论这个问题，但没有讨论解决方案。

There are good reasons for constructing the base class interface with all virtual functions as private or protected (see this). But then how does one prevent the derived classes (which may be in the hands of external clients) from making the private virtual function as public? In Virtually Yours, the authors talk about this problem, but no solution is discussed.

编辑：从您的答案和我之前的想法，似乎没有办法防止这种情况。但是，由于在这种情况下，它很容易出错（客户端肯定触及受保护的虚拟函数），编译器会警告这样的使用是有意义的。我试着用g ++测试它。首先，我写道：

Edit: From your answers and as I previously thought, it seems there is no way to prevent this. But since in this situation, it is easy to go wrong (the client surely touches the protected virtual function), it would make sense that the compiler would warn about such usage. I tried to test it with g++. First, I wrote:

class A {
        protected:
        virtual void none() { return; }
};

class B: public A {
        public:
        void none() { return; }
};

g ++ -c -Wall -pedantic file.cpp 编译时没有错误。添加 -Weffc ++ 时发出警告：警告：类A具有虚拟函数和可访问的非虚拟析构函数说得通。添加虚拟析构函数后，没有警告。所以对这个容易出错的情况没有警告。

g++ -c -Wall -pedantic file.cpp compiled with no error. Adding -Weffc++ gave the warning: warning: ‘class A’ has virtual functions and accessible non-virtual destructor, which makes sense. After adding the virtual destructor, there are no warning. So there is no warning for this easy-to-go-wrong case.

推荐答案

正如Bjarne所说，C ++中的访问控制是为了防止Murphy而不是Machiavelli。一般情况下也是如此 - 它的功能是为了防止意外事故，而不是故意做错误的人。

As Bjarne put it, the access control in C++ is meant to protect against Murphy, not Machiavelli. The same is true in general -- it's features are meant to protect against accidents, not people intentionally doing something wrong.

在某种程度上，使用C ++意味着至少对其他有权访问您的源代码的人的信任程度。如果他们想要足够糟糕，他们可以用各种方式拧紧，你不能做任何事情来阻止他们。如果你想对你的代码如何使用的实际限制，C ++是错误的语言为您的目的。

To an extent, using C++ means putting at least some degree of trust in the other people who will have access to your source code. If they want to badly enough, they can screw things up in all sorts of ways, and you can't do much of anything to stop them. If you want to place real restrictions on how your code is used, C++ is the wrong language for your purposes.

编辑：这不是一个真正的参数所有 - 它只是指出作出决定的基础。由于我有一个D& E的副本从回答以前的问题，我会输入更多，如果在这里 ¹ ：

This isn't really an "argument" at all -- it's simply pointing out the basis upon which decisions were made. Since I have my copy of the D&E out from answering a previous question, I'll type a bit more if it in here¹:

更重要的是允许一个有用的功能比防止每个
误用：你可以写错误的程序
在任何语言。重要的是
最小化意外的
滥用功能的机会，并且花费了很多努力
已经花费在试图确保
的默认行为C ++构造
是明显或导致
编译时错误。例如通过
默认所有函数参数类型
被检查 - 甚至跨过单独的
编译边界 - 和
默认所有类成员都是私有的。
然而，系统编程
语言不能防止确定的
程序员破坏系统，所以
设计努力更好地用于
提供写作良好的设施
程序比阻止
不可避免的坏。在较长的
运行中，程序员似乎学习。这个
是旧C的一个变体信任
程序员的口号。各种类型
检查和访问控制规则
存在，以允许类提供者
清楚地说明从
用户期望什么，以防止事故。
这些规则不打算作为
保护以防止故意的
违规（§2.10）。

It is more important to allow a useful feature than to prevent every misuse: You can write bad programs in any language. It is important to minimize the chance of accidental misuse of features, and much effort has been spent trying to ensure that the default behavior of C++ constructs is either sensible or leads to compile-time errors. For example by default all function argument types are checked -- even across separate compilation boundaries -- and by default all class members are private. However, a systems programming language cannot prevent a determined programmer from break the system so design effort is better expended on providing facilities for writing good programs than preventing the inevitable bad ones. In the longer run, programmers seem to learn. This is a variant of the old C "trust the programmer" slogan. The various type checking and access control rules exist to allow a class provider to state clearly what is expected from users, to protect against accidents. Those rules are not intended as protection against deliberate violation (§2.10).

在§2.10中，他说，除了别的以外：

In §2.10, he says, among other things:

保护系统的任务是确保任何这种类型的违反

The task of the protection system is to make sure that any such violation of the type system is explicit and to minimize the need for such violations.

这些目标似乎是在这里实现的 - 宣传一个受保护的基类成员绝对需要在派生类中进行明确的操作，并且在20多年的写作中我不记得有没有必要（甚至想要）做这件事。

Those goals appear to have been met here -- publicizing a protected base class member definitely requires explicit action in the derived class, and in 20+ years of writing C++ I can't remember ever needing (or even wanting) to do it.

sup> 1 §4.3，pgs。

¹§4.3, pgs. 115, 116.

这篇关于如何防止派生类使私有/受保护的虚拟函数公开？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！