0

I'm new to C++, and one of the concepts I'm working on understanding is destructors. Out of curiosity, can an unnecessary (e.g., when a class has no dynamically allocated memory, resources, or anything requiring a user-defined destructor) and empty destructor cause any unforeseen problems?

Edit: I know that part of this has been answered in Will an 'empty' constructor or destructor do the same thing as the generated one? but I wanted to broaden it to ask more about generalized negative consequences such as crashes or making an application slower. There is some overlap, but it is a slightly different question.

Community
  • 1
  • 1
ce_nort
  • 168
  • 1
  • 16
  • 2
    @mkaes It's a broader question than the one you refer to – SomeWittyUsername Mar 18 '16 at 15:05
  • @SomeWittyUsername: The question itself can be interpreted as 'broader' but still the answer in the linked question answers this question too. So I still believe that this question should be closed. – mkaes Mar 18 '16 at 15:15
  • @mkaes I was looking for more/slightly different information than was included in that question (which I had read). Hopefully my edit clarifies a bit. – ce_nort Mar 18 '16 at 15:36
  • Well, an empty destructor can cause a memory leak, which would be bad. But I think you should make the question more precise, most answerers didn't read it this way. I guess you try to rule out "when a class has no dynamically allocated memory", but you should rule out "when a class has no resources". It might still leak files or sockets for instance if it owns "raw" C handles to those things and doesnt have a dtor. – Chris Beck Mar 18 '16 at 16:08
  • @ChrisBeck Thanks for pointing that out, let me know if my most recent edit is still unclear. – ce_nort Mar 18 '16 at 16:15

5 Answers5

4

The question depends on several parameters. Emptiness isn't the only thing that has effect on the result. E.g., if you don't define virtual destructor (empty or not), you'll get problematic behavior when inheriting from the class. On the other hand, if you define an empty destructor in private or protected section, it will prevent creating instances of the class on stack.

SomeWittyUsername
  • 18,025
  • 3
  • 42
  • 85
  • Problematic behavior doesn't come from **inheriting**, but from deleting though a pointer to the base type. – Pete Becker Mar 18 '16 at 16:46
  • @PeteBecker True. I meant that deleting through a pointer to base is a very common and basic operation when working with polymorphic objects. – SomeWittyUsername Mar 18 '16 at 17:55
  • @PeteBecker, yes, you are not likely to benefit from polymorphic objects unless you delete them through base at some point. – SergeyA Mar 18 '16 at 17:58
  • @SomeWittyUsername - indeed; but base classes are not used exclusively for polymorphic types. For example, several base classes in the standard library do not have virtual destructors and do not need them. – Pete Becker Mar 18 '16 at 18:56
  • @PeteBecker, yes, the answer doesn't mention polymorphic objects! I did not see it. I agree with you, SWU should speficially mention those. – SergeyA Mar 18 '16 at 19:16
  • I agree with you both :) – SomeWittyUsername Mar 18 '16 at 19:18
4

There is also an interesting aspect (which do not seem to be talked about in the linked duplicate) of a triviality of destructor. Compiler-generated (or defaulted) destructors are considered trivial destructors, and having a trivial destructor is a pre-requisite of your class being a POD-type. The user-defined destructor, even if empty, prevents your class from being a POD-type.

And having a POD-type is sometimes very important. For example, POD-types can be memcpyed or entity-serialized.

SergeyA
  • 61,605
  • 5
  • 78
  • 137
1

No, all members of the instance are still destroyed after your destructor ran. The only thing a destructor must not do is throwing an exception, otherwise it may do anything a "proper" method can do, i.e. also doing nothing at all is fine. Not closing handles when you should have is another question.

Kijewski
  • 25,517
  • 12
  • 101
  • 143
0

No. In fact, if you don't declare and write a destructor for a class or struct, the compiler will do it for you - and it will be empty.

Martin Bonner supports Monica
  • 28,528
  • 3
  • 51
  • 88
  • Hmm. I think a bald "Wrong" is a bit harsh. If someone is getting to grips with what a "destructor" is, they aren't going to be worrying about POD types for some time. (And I really can't think of a good reason to use memcpy over assignment/std::copy) – Martin Bonner supports Monica Mar 18 '16 at 15:29
  • But there is a difference, so saying there is no difference is not correct. As for the benefits of `memcpy` (`std::copy` is not applicable here at all) as opposed to writing assignment operator is simply performance and code typing. And default assingment operator will call `memcpy` for PODs, instead of by member copying - again, for performance reasons. – SergeyA Mar 18 '16 at 15:43
0

"Empty destructor" is a bit of a misnomer. Whether or not your destructor has a body, the compiler will still generate code to call the destructor of every non-static member variable and base class in reverse order of declaration. You only need a body if you wish to do something before those other destructors get called.

Nevin
  • 4,595
  • 18
  • 24