Is not providing an explicit destructor bad practice?

Question

If I do not provide an explicit destructor for a C++ class because I'm confident that the default destructor provided by the compiler is all my class needs, is that fine? Or is this considered bad practice?

Answer 1

The main advantage of providing the explicit destructor is that you can easily put a breakpoint into it for debugging. Some people like that and prefer to give every class an explicit destructor because of that.

However, if the class is trivial enough that it is obvious that the default constructor suffices, it is perfectly fine to omit it. Also note that adding a destructor does have its disadvantages: Apart from the additional noise in the code, adding a destructor might prevent your class from being a POD. So you should still avoid mindlessly spreading trivial destructors throughout your code.

The only situation in which I would consider it harmful to omit an empty non-virtual destructor is when it is not obvious why destruction is trivial (e.g. if the rule-of-three/rule-of-five would suggest that you'd need one). In this case I would still provide an explicit empty destructor with a comment in the body why it is safe to not do anything. But that is more a personal preference than a fixed rule.

Answer 2

Explicit destructors are needed only in two cases:

• When you need runtime polymorphism. In this case, the base class destructor needs to be virtual — this requirement forces you to explicitly define the destructor (even if it is empty!). The derived classes, however, may or may not have explicit destructor depending on whether they manage resources or not (which is the second bullet point).

• When your class is a resource managing class — that is, it implements RAII idiom. In this case, you may also need to implement copy-semantics and move-semantics.

In all other cases, explicitly defined destructor is not needed. :-)