Explicit call to destructor

Question

I stumbled upon the following code snippet:

#include <iostream>
#include <string>
using namespace std;
class First
{
    string *s;
    public:
    First() { s = new string("Text");}
    ~First() { delete s;}
    void Print(){ cout<<*s;}
};

int main()
{
    First FirstObject;
    FirstObject.Print();
    FirstObject.~First();
}

The text said that this snippet should cause a runtime error. Now, I wasn't really sure about that, so I tried to compile and run it. It worked. The weird thing is, despite the simplicity of the data involved, the program stuttered after printing "Text" and only after one second it completed.

I added a string to be printed to the destructor as I was unsure if it was legal to explicitly call a destructor like that. The program printed twice the string. So my guess was that the destructor is called twice as the normal program termination is unaware of the explicit call and tries to destroy the object again.

A simple search confirmed that explicitly calling a destructor on an automated object is dangerous, as the second call (when the object goes out of scope) has undefined behaviour. So I was lucky with my compiler (VS 2017) or this specific program.

Is the text simply wrong about the runtime error? Or is it really common to have runtime error? Or maybe my compiler implemented some kind of warding mechanism against this kind of things?

Answer 1

Its has been a while since this question, but I think I can contribute a bit more.

First, when an object goes at of scope, its destructor is invoked. Here you are explicitly calling the destructor once, so then it is invoked a second time.

On the second time, it deletes again the internal s pointer, which was already freed. That corrupts the internal memory structs, so it may crash now or it may crash later. You don't know.

It is always good practice to really check and clean data before releasing it. I would have written the destructor like this :

~First() 
{ 
  if (s)
  {
  delete s;
  s = 0;
  }
}

Then you would have been protected from this error.

It is not necessarily bad to manually invoke a destructor. Sometimes it is needed. Let's say you are working on an embedded device, where you don't want to use dynamic allocation constantly. At startup you could allocate a big chunk of memory, and then construct/destroy objects on it.

Let's say you have a raw pointer, pointing to some raw buffer inside that big chunk, that you are going to use as your First object. The size of that buffer has to be at least sizeof(First).

When you want to build the object you use placement new :

new(p) First();

When you want to destroy it, you invoke :

p->~First();

That way you never release the memory, just construct/destruct objects over the preallocated buffer.

Just a reminder, about what new/delete do :

new will allocate memory, and then it will invoke the constructor on it. delete will invoke the destructor and then free the memory.

If you already have the memory, you can just invoke constructor and then destructor, without allocating or freeing.

Being said that, your code would have worked if you had built it again :

int main()
{
    First FirstObject;
    FirstObject.Print();
    FirstObject.~First();
    new(&FirstObject) First(); // constructing the object a second time
}

Answer 2

No this is simply undefined behavior from the draft C++ standard [class.dtor]p16:

Once a destructor is invoked for an object, the object no longer exists; the behavior is undefined if the destructor is invoked for an object whose lifetime has ended ([basic.life]). [ Example: If the destructor for an automatic object is explicitly invoked, and the block is subsequently left in a manner that would ordinarily invoke implicit destruction of the object, the behavior is undefined. — end example  

and we can see from the defintion of undefined behavior:

behavior for which this document imposes no requirements

You can have no expectations as to the results. It may have behaved that way for the author on their specific compiler with specific options on a specific machine but we can't expect it to be a portable nor reliable result. Althought there are cases where the implementation does try to obtain a specific result but that is just another form of acceptable undefined behavior.

Additionally [class.dtor]p15 gives more context on the normative section I quote above:

[ Note: Explicit calls of destructors are rarely needed. One use of such calls is for objects placed at specific addresses using a placement new-expression. Such use of explicit placement and destruction of objects can be necessary to cope with dedicated hardware resources and for writing memory management facilities. For example,

void* operator new(std::size_t, void* p) { return p; }
struct X {
  X(int);
  ~X();
};
void f(X* p);

void g() {                      // rare, specialized use:
  char* buf = new char[sizeof(X)];
  X* p = new(buf) X(222);       // use buf[] and initialize
  f(p);
  p->X::~X();                   // cleanup
}

— end note  ]

Answer 3

A simple search confirmed that explicitly calling a destructor on an automated object is dangerous, as the second call (when the object goes out of scope) has undefined behaviour.

That is true. Undefined Behavor is invoked if you explicitly destroy an object with automatic storage. Learn more about it.

So I was lucky with my compiler (VS 2017) or this specific program.

I'd say you were unlucky. The best (for you, the coder) that can happen with UB is a crash at first run. If it appears to work fine, the crash could happen in January 19, 2038 in production.

Is the text simply wrong about the runtime error? Or is it really common to have runtime error? Or maybe my compiler implemented some kind of warding mechanism against this kind of things?

Yes, the text's kinda wrong. Undefined behavior is undefined. A run-time error is only one of many possibilities (including nasal demons).

A good read about undefined behavor: What is undefined behavor?

Answer 4

Is the text simply wrong about the runtime error?

It is wrong.

Or is it really common to have runtime error? Or maybe my compiler implemented some kind of warding mechanism against this kind of things?

You cannot know, and this is what happens when your code invokes Undefined Behavior; you don't know what will happen when you execute it.

In your case, you were (un)lucky^* and it worked, while for me, it caused an error (double free).

---

_{*Because if you received an error you would start debugging, otherwise, in a large project for example, you might missed it...}