Dangling Pointers after Destructor is called

Question

I went through this post and had a doubt. Is it a good practice to null an element of an object in its destructor? The destructor will be called when the object goes out of scope but will its elements need to be set to NULL in the destructor to ensure dangling pointers are not left.

Answer 1

After an object is destroyed, it ceases to exist. There is no point in setting its members to particular values when those values will immediately cease to exist.

The pattern of setting pointers to NULL when deleteing the objects they point to is actively harmful and has caused errors in the past. Unless there's a specific reason the pointer needs to be set to NULL (for example, it is likely to be tested against NULL later) it should not be set to NULL.

Consider:

Foo* foo getFoo();
if (foo!=NULL)
{
    do_stuff();
    delete foo;
}
// lots more code
return (foo == NULL);

Now, imagine if someone adds foo = NULL; after the delete foo; in this code, thinking that you're supposed to do that. Now the code will give the wrong return value.

Next, consider this:

Foo* foo getFoo();
Foo* bar = null;
if (foo != NULL)
{
    bar = foo;
    do_stuff(bar);
    delete bar;
    bar = NULL;
}
// lots more code
delete foo;

We always set pointers to NULL after we delete them, so this delete foo; must be safe, right? Clearly it's not. So setting pointers to NULL after you delete them is neither necessary nor sufficient.

Don't do it.

Answer 2

It's not necessary to set member elements to NULL in the destructor, as delete has been called on the owner object in order for that destructor to be called. It is the responsibility of the code that deletes an object to no longer try to access the contents of that object.

You are also using extra cycles clearing out that memory.

Answer 3

The point of doing this is to provide deterministic behavior in event of a programming error.

• If the deleted pointer is used, then the program will always fail on dereferencing a nullptr. (Not allowing the program to continue.)
• If the deleted pointer set to nullptr and is then deleted again, then the second attempt is a noop (by design).

This is the normal pattern for pointers that are NOT deleted in a destructor. (Smart pointers are your friend, to avoid this situation, entirely.)

The purpose of nulling a deleted member pointer in a destructor is less obvious; when there is a suspicion that other code may have a reference to that member. This should generally be avoided (to rely on this), because it has limited utility once the memory for the destructed class is reclaimed. Although implementation dependent, in many environments the memory can live long enough to cause the program to fail when the deleted memory is re-used, so that the programmer can find the issue and fix it.