什么时候可以安全地从C ++中的基类继承

Question

So the basic rule that I find everywhere is that to inherit from a base class, the base class must have a virtual destructor so that the following works:

Base *base = new Inherited();
delete base;

However I am certain I have seen at least one other possibility that allows safe inheritance. However I can't find it anywhere and I feel like I am going mad trying to find it. I thought the other option might have been that the base class had a trivial destructor, but according to Non-virtual trivial destructor + Inheritance , this isn't the case. Even though there wouldn't be a memory leak for this case, it appears this is still undefined behaviour.

Does anyone else know what the other case is or can you definitively tell me that I dreamt it?

Answer 1

I guess an example can be the one that involves shared_ptr s, for it is good to show both the sides of the issue.

Suppose you have a class B with a trivial non virtual destructor and a derived class D with its own complex one.

Let's define the following function somewhere:

shared_ptr<B> factory () {
    // some complex rules at the very end of which you decide to instantiate class D
    return make_shared<D>();
}

In that case you are dealing with all the interesting features due to the polymorphism, but the pointer you are working with has inherited the deleter from the one constructed with type D .

Even though, thanks to the type erasure, the type is buried somewhere and everything works fine, the actual invoked destructor is the one of D , so everything should work fine also from that point of view, even though the destructor of B was not virtual .

Instead, if you define the above factory as:

B* factory () {
    return new D{};
}

The called destructor (well, supposing that someone will delete it) will be the one of B , that is not what you want.

That said, defining as virtual the destructor of a class that is meant to be inherited from is a good practice, otherwise put a final in the class definition and stop there the hierarchy.

There also a lot of other examples, this is not the only case where it works, but it can help to explain why it works.

Answer 2

Perhaps when the inheritance is private. In such a case, the user can't convert Derived* to Base* so there is no chance of trying to delete the derived class through the base class pointer. Of course, you still have to watch that you don't do this anywhere within your implementation of Derived .

Answer 3

My take on this is pragmatic rather than anything to do with what is or isn't allowed by the standards.

So, pragmatically , if a class doesn't have a virtual destructor - even an empty one - then my default assumption is that it hasn't been designed to be used as a base class . This may have more implications than just destruction and in more cases than not, just opens a can of worms for you to fall in later.

If you want or need to use functionality from a class without a virtual destructor, it would be safer to use composition rather than inheritance. In fact, that's the preferred route anyway.

Answer 4

The other case I've seen mentioned is making the base-class destructor protected . That way, you prevent deletion through a base class.

This is actually item 50 in the book C++ Coding Standards by Herb Sutter et al: "Make base class destructors public and virtual or protected and non-virtual", so it is quite likely that you have heard of it before.

Answer 5

You can always inherit from a class. There are rules to obey though, eg without a virtual destructor you can't invoke the destructor polymorphically. In order to avoid this, you could eg use private derivation for baseclasses that were not intended as baseclasses, like eg the containers from the STL.

Answer 6

As others have mentioned, as long as you delete the class through it's own destructor - in other words you do

Inherited *ip = new Inherited();
Base *p = ip; 
... 
delete ip;

you'll be fine. There are several different ways to do that, but you have to be quite careful to ensure that is the case.

However, having an empty destructor in the baseclass [and your inherited type is immediately inheriting] only works as long as it is TRULY empty, and not just that you have an { } for the body of the destructor. [See Edit2 below!]

For example, if you have a vector or std::string , or whatever other class that needs destruction, in your baseclass, then you will leak the content of that class. In other words, you need to make 100% sure that the destructor of the baseclass is empty. I don't know of a programmatic way to determine that (beyond analysing the generated code, that is).

Edit:

Also beware of "changes in the future" - for example, adding a string or vector inside Base or changing the base class from Base to SomethingInheritedFromBase that has a destructor "with content" will ruin the "empty destructor" concept.

Edit2:

It should be noted that for the "destructor is empty", you have to have true empty destuctors in all derived clases too. There are classes that have no members that need destruction (interface classes typically have no data members, for example, so would not need destruction in themselves), so you could construct such a case, but again, we have to be VERY careful to avoid the destructor of a derived class adding a destructor into the class.