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

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

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.

Answer 2

You can't. "virtualness" of a function and access type are two different unrelated concepts.