Private/protected inheritance

Question

In C++, I can't think of a case in which I would like to inherit private/protected from a base class:

class Base;
class Derived1 : private Base;
class Derived2 : protected Base;

Is it really useful?

Answer 1

Private can be useful in quite a few circumstances. Just one of them are policies:

http://stackoverflow.com/questions/356294/is-partial-class-template-specialization-the-answer-to-this-design-problem#356576.

Another occasion where it is useful is to forbid copying and assigning:

struct noncopyable {
    private:
    noncopyable(noncopyable const&);
    noncopyable & operator=(noncopyable const&);
};

classs my_noncopyable_type : noncopyable {
    // ...
};

Because we don't want that the user has a pointer of type noncopyable* to our object, we derive privately. That counts not only for noncopyable, but many many other such classes too (policies being the most common).

Answer 2

It is useful when you want to have access to some members of the base class, but without exposing them in your class interface. Private inheritance can also be seen as some kind of composition: the C++ faq-lite gives the following example to illustrate this statement

class Engine {
 public:
   Engine(int numCylinders);
   void start();                 // Starts this Engine
};

class Car {
  public:
    Car() : e_(8) { }             // Initializes this Car with 8 cylinders
    void start() { e_.start(); }  // Start this Car by starting its Engine
  private:
    Engine e_;                    // Car has-a Engine
};

To obtain the same semantic, you could also write the car Class as follow:

class Car : private Engine {    // Car has-a Engine
 public:
   Car() : Engine(8) { }         // Initializes this Car with 8 cylinders
   using Engine::start;          // Start this Car by starting its Engine
};

However, this way of doing has several disadvantages:

• your intent is much less clear
• it can lead to abusive multiple inheritance
• it breaks the encapsulation of the Engine class since you can access its protected members
• you're allowed to override Engine virtual methods, which is something you don't want if your aim is a simple composition

Answer 3

Public inheritance models IS-A.
Non-public inheritance models IS-IMPLEMENTED-IN-TERMS-OF.
Containment models HAS-A, which is equivalent to IS-IMPLEMENTED-IN-TERMS-OF.

Sutter on the topic. He explains when you'd choose non-public inheritance over containment for implementation details.

Answer 4

For instance, when you want to reuse the implementation, but not the interface of a class AND override its virtual functions.

Answer 5

I've used both private and protected inheritence at one point or other.

Private inheritence is useful when you want something to have the behaviour of the base class, and then be able to override that functionality, but you don't want the whole world to be aware of it and use it. You can still use the interface of a privately derived class by having a function return that interface. It's also useful when you can have things register themselves to listen for callbacks as they can register themselves using the private interface.

Protected inheritence is especially useful when you have a base class that derives useful functionality from another class but you only want its derived classes to be able to use it.

Answer 6

I once implemented these data structures as classes:

• Linked list
• Generic array (abstract)
• Simple array (inherits from generic array)
• Big array (inherits from generic array)

The big array's interface would make it look like an array, however, it was actually a linked list of fixed-size simple arrays. So I declared it like this:

template <typename T>
class CBigArray : public IArray, private CLnkList {
    // ...

Answer 7

Private inheritance is mostly used for wrong reason. People use it to IS-IMPLEMENTED-IN-TERMS-OF, as indicated in an earlier answer, but in my experience it's always more clean to keep a copy rather than inherit from class. Another earlier answer, the one about CBigArray, provides a perfect example of this anti-pattern.

I realize that there may be cases when has-a does not work due to over-zealous use of "protected", but it's better to fix the broken class than to break a new class.