Are virtual destructors inherited?

Question

If I have a base class with a virtual destructor. Has a derived class to declare a virtual destructor too?

class base {
public:
    virtual ~base () {}
};

class derived : base {
public:
    virtual ~derived () {} // 1)
    ~derived () {}  // 2)
};

Concrete questions:

1. Is 1) and 2) the same? Is 2) automatically virtual because of its base or does it "stop" the virtualness?
2. Can the derived destructor be omitted if it has nothing to do?
3. What's the best practice for declaring the derived destructor? Declare it virtual, non-virtual or omit it if possible?

Autoclave

Answer 1

1. Yes, they are the same. The derived class not declaring something virtual does not stop it from being virtual. There is, in fact, no way to stop any method (destructor included) from being virtual in a derived class if it was virtual in a base class. In >=C++11 you can use final to prevent it from being overridden in derived classes, but that doesn't prevent it from being virtual.
2. Yes, a destructor in a derived class can be omitted if it has nothing to do. And it doesn't matter whether or not its virtual.
3. I would omit it if possible. And I always use either the virtual keyword or override for virtual functions in derived classes for reasons of clarity. People shouldn't have to go all the way up the inheritance hierarchy to figure out that a function is virtual. Additionally, if your class is copyable or movable without having to declare your own copy or move constructors, declaring a destructor of any kind (even if you define it as default) will force you to declare the copy and move constructors and assignment operators if you want them as the compiler will no longer put them in for you.

As a small point for item 3. It has been pointed out in comments that if a destructor is undeclared the compiler generates a default one (that is still virtual). And that default one is an inline function.

Inline functions potentially expose more of your program to changes in other parts of your program and make binary compatibility for shared libraries tricky. Also, the increased coupling can result in a lot of recompilation in the face of certain kinds of changes. For example, if you decide you really do want an implementation for your virtual destructor then every piece of code that called it will need to be recompiled. Whereas if you had declared it in the class body and then defined it empty in a .cpp file you would be fine changing it without recompiling.

My personal choice would still be to omit it when possible. In my opinion it clutters up the code, and the compiler can sometimes do slightly more efficient things with a default implementation over an empty one. But there are constraints you may be under that make that a poor choice.

Eduction

Your last sentence should probably read "shouldn't" instead of "should." – Ahern

@Chris Lutz, I'm ahead of you on that. It's been edited into submission now. :-) – Eduction

I disagree with the 'omit' part. It does not cost much to declare it in the header and define it (empty body) in the source. If you do so, you can always come back and add some steps (logging ?) without forcing your clients to recompile. – Beckibeckie

@Matthieu M, that's an argument for not declaring any function inline. Though I will grant that it's likely a little more common to want to log constructor and destructor calls than anything else. – Eduction

Actually, I don't declare much function inline, not even the classic 'accessors', but then working in a big company, we may have binary compatibility constraints that are a higher than most. – Beckibeckie

If a function in subclass hide function in base class with the same name but different parameters, will this subclass function still be virtual?@MatthieuM. – Baldwin

I just learned from this talk that declaring the virtual destructor will actually cause your class to become unmoveable! So anytime you declare a virtual destructor you must also provide the entire rule of 5 if you want those properties. Even more reason to omit when possible. – Tired

@YuanWen - Though this response is several years delayed... no, it will not be virtual. The type signature must match... though I'm not sure about contravariance rules here (i.e. if the function in the derived class takes an argument that's a base of the class the base class function takes as an argument (yes, that's kind of confusing)), but I suspect they don't matter and that it still isn't virtual. I think contravarience is a design consideration and isn't supported or enforced by the compiler in any way. – Eduction

"Additionally, if your class is copyable or movable without having to declare your own copy or move constructors, declaring a destructor of any kind (even if you define it as default) will force you to declare the copy and move constructors and assignment operators if you want them as the compiler will no longer put them in for you." That is wrong! en.cppreference.com/w/cpp/language/copy_constructor – Pathless

@Pathless - I'll double check that this is true and fix my answer. – Eduction

@Omifarious do you still feel that same way about #3 above? In modern C++ you will have an override keyword on any virtuals so you will not need to scan up the inheritance tree. – Sympetalous

@JoeSteele - No, I don't. You're right, override works. – Eduction

Answer 2

A virtual member function will make implicitely any overloading of this function virtual.

So the virtual in 1) is "optional", the base class destructor being virtual makes all child destructors virtual too.

Sublet

Answer 3

1. The destructor is automatically virtual, as with all methods. You can't stop a method from being virtual in C++ (if it has already been declared virtual, that is, i.e. there's no equivalent of 'final' in Java)
2. Yes it can be omitted.
3. I would declare a virtual destructor if I intend for this class to be subclassed, no matter if it's subclassing another class or not, I also prefer to keep declaring methods virtual, even though it's not needed. This will keep subclasses working, should you ever decide to remove the inheritance. But I suppose this is just a matter of style.

Booby

Destructors are not automatically virtual, and neither are any other member functions. – Dislike

@Neil; of course not, I was referring to the destructor in the example (i.e. where the base class has a virtual one), not destructors in general. And this is true for all methods, not just destructors. – Booby

Since C++11, we have final. – Countrybred

Answer 4

1/ Yes 2/ Yes, it will be generated by the compiler 3/ The choice between declaring it virtual or not should follow your convention for overriden virtual members -- IMHO, there are good arguments both way, just choose one and follow it.

I'd omit it if possible, but there is one thing which may incite you to declare it: if you use the compiler generated one, it is implicitly inline. There are time when you want to avoid inline members (dynamic libraries for instance).

Tame

Answer 5

Virtual functions are overridden implicitly. When the method of a child class matches the method signature of the virtual function from a base class, it is overridden. This is easy to confuse and possibly break during refactoring, so there are override and final keywords since C++11 to mark this behavior explicitly. There is a corresponding warnings that forbid the silent behavior, for example -Wsuggest-override in GCC.

There is a related question for override and final keywords on SO: Is the 'override' keyword just a check for a overridden virtual method?.

And the documentation in the cpp reference https://en.cppreference.com/w/cpp/language/override

Whether to use override keyword with the destructors is still a bit of debate. For example see discussion in this related SO question: default override of virtual destructor The issue is, that the semantics of the virtual destructor is different to normal functions. Destructors are chained, so all base classes destructors are called after child one. However, in case of a regular method base implementations of the overridden method are not called by default. They can be called manually when needed.

Sterlingsterlitamak