CODEWITHSUNDEEP
c++destructor
Cricketer
Cricketer

Reputation: 2431

Is not providing an explicit destructor bad practice?

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?

Upvotes: 9

Views: 3942

Answers (5)

Arne Mertz
Arne Mertz

Reputation: 24626

Yes, that's perfectly fine. You have mainly three reasons to provide a destructor yourself:

  1. You are defining a base class of a class hierarchy, whose objects will be destroyed polymorphically. You then need to define the destructor public and virtual (and defaulted, see later).
  2. You are defininig a base class in a hierarchy that will not have its objects destroyed polymorphically. Since in good OO-practice you won't instanciate objects of that base class, you make the destructor nonvirtual, protected (and defaulted).
  3. You are defining a class that owns a resource. You'll have to obey The Rule of Five and define the destructor to release the resource.

Case 1 and 2 are mutually exclusive, and in case 3 the SRP demands that the class' purpose is solely management of the owned resource, so it should not be a base class, making all three cases mutually exclusive. That's the reason why the base class destructors and almost any "normal class" destructor should be defaulted (see this article about The Rule of Zero).

Of course there are many corner cases that don't exactly fit into that scheme and where destructors are needed in some cases. But generally, if you are sure the defaulted destructor does what is needed, you don't need to define it yourself.

Upvotes: 1

ComicSansMS
ComicSansMS

Reputation: 54737

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.

Upvotes: 8

justin
justin

Reputation: 104708

Where applicable, you should generally provide an out of line definition if:

  • The destructor is virtual and your class provides no out of line virtual definitions (remember that bases with virtual destructors make your destructor virtual). Many implementations emit vtables and RTTI info in the translation which contains the definition of the first out of line virtual member function. This can result in a lot of cloned information, if the type is visible to many translations.

  • or if the destruction of the members is 'heavyweight'

These two can shave a big chunk off your binary size and build times.

You may also define it out of line in order to correctly delete a PIMPL member (based on which headers are visible where and the mechanics of your smart pointers).

Upvotes: 0

Sarfaraz Nawaz
Sarfaraz Nawaz

Reputation: 361732

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. :-)

Upvotes: 7

fsw
fsw

Reputation: 3695

It depends on what your constructor is doing. C++ does not provide garbage collection so if your constructor is creating new objects it would be good to delete them in destructor. Memory used for class members is freed anyway so if you are not using "new" in constructor and not allocating memory in any other way, destructor is not mandatory.

Upvotes: 0

Related Questions