Inheritance in C++: public, private, protected and performance

What lies behind inheritance modifiers in C++?

Imagine you are an architect. You have a blueprint for a "building" (base class), and you want to build three different "houses" (derived classes) from it. One house will be an exact copy with a public entrance (public), the second with a closed inner courtyard (private), and the third with access only for family and friends (protected). In C++, this is exactly how inheritance modifiers work. But does this choice affect program speed? Spoiler: both yes and no. Let's figure out how not to shoot yourself in the foot and optimize your code at the same time.

This question is one of the most popular on Stack Overflow (tens of thousands of views), and for good reason. Beginners often confuse the access level of class members with the type of inheritance. And experienced developers know: the right choice of inheritance can save hours of debugging and even speed up the program a bit. Today on pythonlib.ru, we will close this topic once and for all.

The Inheritance Triangle: public, private, protected

First, the basics. Imagine we have a base class Animal:

class Animal {\npublic:\n    void eat() { /* ... */ }\nprotected:\n    int age;\nprivate:\n    std::string secretDNA;\n};

Now let's see how the three types of inheritance change access to these members in the derived class Dog.

1. Public inheritance — "as is"

The most common and intuitive type. All access levels remain unchanged:

\n
• public → public (accessible to everyone)
\n
• protected → protected (accessible to descendants)
\n
• private → inaccessible (remains in the base class)
\n

Use this when you want to express the relationship "Dog IS-A Animal". This is classic OOP.

2. Protected inheritance — "for insiders only"

All public members of the base class become protected in the derived class:

\n
• public → protected
\n
• protected → protected
\n
• private → inaccessible
\n

Use this when you want to hide implementation details from the outside world but allow access to "grandchildren". For example, the Boost library actively uses protected inheritance for internal mechanisms.

3. Private inheritance — "mine and mine alone"

The strictest mode. All public and protected members become private:

\n
• public → private
\n
• protected → private
\n
• private → inaccessible
\n

This is the relationship "Dog is implemented IN TERMS OF Animal". It is often used instead of composition for optimization (more on this below).

Performance: where the dog is buried

And now — to the main intriguing question: does the type of inheritance affect performance? In short: directly — no, but indirectly — very much so.

Myth: private inheritance is faster than public

Some think that private inheritance "removes extra checks". This is not true. Access modifiers (public, protected, private) are a purely compile-time concept. The compiler checks them at build time and generates the same machine code. There is no difference at runtime.

Reality: optimization through empty base optimization (EBO)

This is where private inheritance actually speeds up a program! If the base class contains no data (an empty class), then with public or protected inheritance, the compiler may (but is not required to) add an extra byte for alignment. But with private inheritance, the Empty Base Optimiz