Question

Assume you have an object of class Fool.

class Fool
{
    int a,b,c;
    double* array ;
    //...
    ~Fool()
    {
        // destroys the array..
        delete[] array ;
    }
};


Fool *fool = new Fool() ;

Now, I know you shouldn’t, but some fool calls the destructor on fool anyway. fool->~Fool();.

Does that mean fool‘s memory is freed, (ie a,b,c are invalid) or does that mean only whatever deallocations in ~Fool() function occur (ie the array is deleted only?)

So I guess my question is, is a destructor just another function that gets called when delete is called on an object, or does it do more?

Answer 1

If you write

fool->~Fool();

You end the object’s lifetime, which invokes the destructor and reclaims the inner array array. The memory holding the object is not freed, however, which means that if you want to bring the object back to life using placement new:

new (fool) Fool;

you can do so.

According to the spec, reading or writing the values of the fields of fool after you explicitly invoke the destructor results in undefined behavior because the object’s lifetime has ended, but the memory holding the object should still be allocated and you will need to free it by invoking operator delete:

fool->~Fool();
operator delete(fool);

The reason to use operator delete instead of just writing

delete fool;

is that the latter has undefined behavior, because fool‘s lifetime has already ended. Using the raw deallocation routine operator delete ensures that the memory is reclaimed without trying to do anything to end the object’s lifetime.

Of course, if the memory for the object didn’t come from new (perhaps it’s stack-allocated, or perhaps you’re using a custom allocator), then you shouldn’t use operator delete to free it. If you did, you’d end up with undefined behavior (again!). This seems to be a recurring theme in this question. 🙂

Hope this helps!