学步园

By making the inheritance private, you're basically saying that even the fact that B inherits from A (at all) is private -- not accessible/visible to the outside world.

Without getting into a long-winded discussion of what would happen if it was allowed, the simple fact is that it's not allowed. If you want to use a pointer to base to refer to an object of derived type, then you're pretty much stuck with using public inheritance.

Edit: Since somebody went to the trouble of sending an email to ask for more information about what could happen if this was allowed, I guess I'll elaborate a little on it.

The basic problem is that private inheritance is not necessarily intended to follow the Liskov
substitution principle. Public inheritance asserts that a derived object can be substituted for an object of the base class, and proper semantics will still
result. Private inheritance does not assert that though. The usual description of the relationship implied by private inheritance is "is implemented
in terms of".

Public inheritance means a derived class maintains all the capabilities of the base class and potentially adds more besides. Private inheritance often means more or less the opposite: that the derived class uses a general base class to implement something with
a more restricted interface.

Just for example, let's assume for the moment that the containers in the C++ standard library were implemented using inheritance rather than templates. In the current system, std::deque andstd::vector are
containers, and std::stack is
a container adapter that provides a more restricted interface. Since it is based on templates, you can use std::stack as
an adapter for eitherstd::deque or std::vector.

If we wanted to provide essentially the same with inheritance, we would probably use private inheritance, so std::stack would
be something like:

class stack : private vector {
    // ...
};

In this case, we definitely do not want the user to be able to manipulate our stack as
if it were avector.
Doing so could (and likely would) violate the expectations of a stack (e.g., the user could insert/remove items in the middle, rather than a purely stack-like fashion as intended). We're basically using vector as
a convenient way to implement our stack, but if (for example) we changed the implementation for stack stand
alone (with no dependence on a base class) or re-implement it in terms of std::deque,
we do not want that to affect any client code -- to the client code, this is supposed to be just a stack, not some specialized variety of vector
(or deque).