How to prevent derived class from making a private/protected virtual function public?

Question

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 cla

Answer 1

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.

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.

Edit: 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¹:

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).

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.

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.

¹§4.3, pgs. 115, 116.