4

In this post:

C++ Pointer: changing the contents without changing the address?

The user Eric Postpischil suggested an answer in which he actively called the destructor of a class. Is it legal? Is it considered good programing?

The reason I ask is that in one of my classes my teacher said it is forbidden and we should never do that, was he wrong?

The question and the answer itself on the post, although interesting is not really relevant to my question.

Community
  • 1
  • 1
Ravid Goldenberg
  • 2,119
  • 4
  • 39
  • 59
  • 6
    It's definitely not forbidden. Placement new is just about the only time you'd want to, though. – chris Jun 05 '13 at 22:18
  • I don't know if it's forbidden as such, but is an advanced technique that might only be appropriate in very specialised situations. Thanks for linking to that question. I didn't know about placement-new. – paddy Jun 05 '13 at 22:22
  • 2
    It's a central part of every allocator. There's even a dedicated part of the standard about pseudo-destructors just to allow easy manual calling of destructors. – Kerrek SB Jun 05 '13 at 22:23
  • I can think of only 1 time I did it (placement new related on an embedded platform) - and it turned out to be the wrong solution to my problem. Your teacher is giving you a generally correct answer to keep from confusing you or tempting you to open a Pandora's box. – Michael Dorgan Jun 05 '13 at 22:30
  • 1
    possible duplicate of [Is calling destructor manually always a sign of a bad design?](http://stackoverflow.com/questions/14187006/is-calling-destructor-manually-always-a-sign-of-a-bad-design) – Jesse Good Jun 05 '13 at 22:32
  • It's absolutely 100% required in order to implement many data structures, like `vector`. – Mooing Duck Jun 05 '13 at 22:32
  • Thank you all for your comments i will be sure to keep that in mind. – Ravid Goldenberg Jun 05 '13 at 23:56

2 Answers2

5

Well, just like the process of creation of a dynamic object can be "disassembled" into two stages: raw memory allocation and actual initialization (e.g. constructor call through placement-new), the process of destroying a dynamic object can also be "disassembled" into two stages: actual de-initialization (destructor call) and raw memory deallocation. (As you can see the the two processes are mirror images of each other.)

This is very useful in situations when you want to use your own raw memory allocation/deallocation mechanism. Granted, in many cases you can achieve the desired effect by overloading operator new/delete, but in some cases it is not flexible enough and you might prefer to carry out the above steps explicitly.

So, here's one example of when the direct destructor call is a useful feature. There are quite a few others. And yes, it is perfectly legal.

When your class teacher said that you should never do that, he/she probably mean that you should avoid it for now, within the scope of your current curriculum. As you progress in your study, you will understand that many "you should never do that" tricks are actually very useful techniques belonging to "do that, if you know what you are doing" category. Of course, you should not abuse this technique, since it is indeed a low-level one.

P.S. This syntax is formally called pseudo-destructor call, since it sort of allows you to "call" non-existing destructors

typedef int INT;

INT i;
i.~INT(); // <- legal code, pseudo-destructor call, no op

The above is legal C++ code, despite the fact that INT is not a class type and therefore has no destructor. (Just don't try doing i.~int() - it is illegal. An aliased typename has to be used for non-class types.)

AnT stands with Russia
  • 312,472
  • 42
  • 525
  • 765
2

C++ destructors are certainly not illegal and are not forbidden or bad (unless you do it wrong of course). So yes, strictly speaking your teacher was wrong (though he may have just been trying to get some other point across).

The most common example of this is classes that use dynamic memory allocation. Simply put, when the destructor is called on a class that has allocated memory for itself on the stack, that memory does not get deallocated. This means that there is memory on the stack that is reserved, but isnt referenced by anyone, meaning you cant get to it. In other words, you have a memory leak. However, if you properly create a destructor and manually deallocate the memory you avoid said memory leak.

David says Reinstate Monica
  • 19,209
  • 22
  • 79
  • 122