Why does C++ forbid private inheritance of a final class?

Question

C++11 introduced the final keyword to C++.

It can be used on a virtual method or on a class.

Declaring a class final forbids any kind of inheritance: public, protected and private.

struct A final {
};

class B: private A {
};

 error: base 'A' ^ is marked 'final'

While it can be reasonable to forbid public inheritance (e.g. if my class doesn't have a virtual destructor, or for other reasons), why should I forbid private inheritance?

Might it be that if final forbade only public inheritance, that std::string and its other friends in std would have been final -- as they should -- for not having a virtual destructor?

EDIT:

Howard Hinnant already answered Why the standard containers are not final but still, there is a reason for declaring a class final but allowing private inheritance.

Not having a virtual destructor does not prohibit or limit inheritance anyhow. It only makes ownership over object through a pointer to base class faulty. So that is not a reason for making `std::string` and most of other library classes `final`. — user7860670, Dec 25 '18 at 08:14
How would that hypothetical feature work? Assume you can derive (if only privately) from a final class. Would virtual functions be treated as final? — curiousguy, Dec 25 '18 at 14:22

score 13 · Accepted Answer · edited Dec 25 '18 at 12:24

13

Inheritance is inheritance. Accessibility is orthogonal to it. It only protects from statically treating the derived class as the base, outside the scope of the derived class. It makes no difference at runtime, and if private inheritance was allowed, you could write this:

struct C {
    virtual void foo() {}
};

struct A final : C {
    virtual void foo() {}
};

void baz(A& ref) { ref.foo(); }

class B: private A {
   virtual void foo() {}
   void bar() {
       baz(*this);
   }
};

Private inheritance doesn't stop you from using run-time polymorphism. If final is meant to fully prevent further overriding, then private inheritance must be included in the prohibition.

edited Dec 25 '18 at 12:24

Boann

48,794
16
117
146

answered Dec 25 '18 at 08:12

StoryTeller - Unslander Monica

165,132
21
377
458

Beautiful example, which reminds me the peculiar rule: if B is privately inherited from A, object of type B is still considered "an A" inside B itself! IMHO it would be better if the spec would not allow B in this case (of private inheritance) to override private virtuals of A, even without final! But this would be an extra rule for a very rare case I guess... and maybe not a good one at all. A better rule might be: be careful with private inheritance. – Amir Kirsh Dec 25 '18 at 08:42
1

@AmirKirsh - A subsection of the master rule. Be careful with C++ in general :) – StoryTeller - Unslander Monica Dec 25 '18 at 08:43
2

privately inherited from the master rule? :-) – Amir Kirsh Dec 25 '18 at 08:49
It could have been possible to have `final` only cap the *polymorphic* hierarchy. In that case, accessibility wouldn't have come into it either though. – Deduplicator Dec 25 '18 at 12:36
@Deduplicator - Could have. But the paper proposing it wanted to give class authors the tool to say "you can't inherit from this, period". That's not without merit either, and that's the direction the committee went with. – StoryTeller - Unslander Monica Dec 25 '18 at 12:41

score 3 · Answer 2 · answered Dec 25 '18 at 12:46

In addition to what Story Teller said, consider the reason for introducing final: It's supposed to help optimizations.

When a class is final, and you have a pointer to it, the compiler can prove which member function you are calling, even if it's virtual. If the class is not final, the pointer could actually be a pointer to some derived class, which could conceivably override the virtual method, forcing a full dynamic vtable lookup.

Whether the inheritance is private or not, it is always possible to create a base-class pointer. In the case of private inheritance, the creation of this base-class pointer would be restricted to the deriving class, the derived class, and any base of the derived class, which is still more code than the optimizer has available to make its decisions. As such, only forbidding all inheritance allows the virtual call optimizations to be made.

Why does C++ forbid private inheritance of a final class?

2 Answers2