When to use C++ private inheritance over composition?

Question

Can you give me a concrete example when is preferable to use private inheritance over composition? Personally, I will use composition over private inheritance, but there mig

Answer 1

Scott Meyers in "Effective C++" item 42 says

"Only inheritance gives access to protected members, and only inheritance allows for virtual functions to be redefined. Because virtual functions and protected members exist, private inheritance is sometimes the only practical way to express an is-implemented-in-terms-of relationship between classes."

Answer 2

Privately inheriting interfaces

A typical application of private inheritance that many people overlook is the following.

class InterfaceForComponent
{
public:
    virtual ~InterfaceForComponent() {}
    virtual doSomething() = 0;
};

class Component
{
public:
    Component( InterfaceForComponent * bigOne ) : bigOne(bigOne) {}

    /* ... more functions ... */

private:
    InterfaceForComponent * bigOne;
};

class BigOne : private InterfaceForComponent
{
public:
    BigOne() : component(this) {}

    /* ... more functions ... */

private:
    // implementation of InterfaceForComponent
    virtual doSomething();

    Component component;
};

Usually BigOne would be a class with a lot of responsibilities. In order to modularize your code you would break your code into components, that help doing the little stuff. These components shouldn't be friends of BigOne, but still they might need some access to your class, that you don't want to give into the public, because it's implementation details. Hence you create an interface for that component to provide this restricted access. This makes your code better maintainable and to reason about, because things have clear boundaries of access.

I used that technique a lot in a several man-year project and it has paid off. Composition is not an alternative here.

Letting the compiler generate a partial copy-constructor and assignment

Sometimes, there are copyable/movable classes that have a lot of different data members. The compiler generated copy or move constructor and assignment would be fine, except for one or two data members that need special treatment. This can be annoying, if data members are added, removed or changed frequently, since hand-written copy and move constructors and assignments need to be updated each time. It produces code-bloat and make the class harder to maintain.

The solution is to encapsulate the data members, whose copy and move operations can be compiler-generated into an extra struct or class from which you privately inherit.

struct MyClassImpl
{
    int i;
    float f;
    double d;
    char c;
    std::string s;
    // lots of data members which can be copied/moved by the 
    // compiler-generated constructors and assignment operators. 
};

class MyClass : private MyClassImpl
{
public:
    MyClass( const MyClass & other ) : MyClassImpl( other )
    {
        initData()
    }

    MyClass( MyClass && other ) : MyClassImpl( std::move(other) )
    {
        initData()
    }

    // and so forth ...

private:
    int * pi;

    void initData()
    {
        pi = &p;
    }
};

You can then use the compiler-generated operations of the MyClassImpl class in the implementation of the respective operations of the class you are interested in. You could do the same with composition, but this would uglify your code in the rest of your class. If you used composition, the rest of the implementation would have to suffer because of this implementation detail of the copy and move operations. Private inheritance avoids this and avoids lots of code repetition.

Answer 3

private inheritance is typically used to represent "implemented-in-terms-of". The main use I have seen is for mixins using private multiple inheritance to build up a child object with the proper functionality from the various mixin parents. This can also be done with composition (which I slightly prefer) but the inheritance method DOES allow you to use using to expose some parent methods publicly, and allows for a slightly more convenient notation when using the mixin methods.