Cppcoreguidelines: NR8: Don't assign pointer to null after delete in destructor.

[sameer-chaudhari]

Request for new guideline.

Reason not to follow this rule:
This simply adds overhead and doesn`t add any value.

This is mostly required while dealing with legacy code or manipulating raw object
.

.
.

[beinhaerter]

I don't think that this should be a rule.
Assigning null after delete helps to find use-after-free bugs faster.
But more important: the guidelines recommend not to use naked new/delete, so why should there be a rule about what to do after a naked delete?

[JonasToth]

Plus there is gsl::owner which elimates the resource bugs when used with a proper static analysis tool. The gsl::owner is then used to implement the proper RAII objects.

[brenoguim]

@beinhaerter sometimes setting it to null will prevent you from finding use-after-free bugs. After all, code using a pointer will generally test the pointer before using. So, sometimes it will test the pointer, see that it is null and fallback to something else.

About the second point, the guidelines will recommend to not use naked new/delete, but there some cases in which one cannot do so. I guess it is valid to add guidelines for those cases.

Now if this rule is agreed upon and relevant enough to put on the guidelines, that I don't know.

[jwakely]

This simply adds overhead

Writes to data members in destructors are dead stores and should be optimised away, so don't add any overhead. (If you're compiling without optimisation then those stores are not going to matter anyway, because you'll have far more overhead).

Assigning null after delete helps to find use-after-free bugs faster.

Not if those dead stores are removed by the compiler.

[sameer-chaudhari]

Why this not rule and myth is required ?

Many people has strong belief setting pointer to NULL is required in destructor.
They feel this is required to prohibit double object deletion or similar memory corruption problem.
Also many of them feel this is part of standard coding practice.

Thus below pattern is common in code.
Foo::~Foo()
{
if(pointer)
{
delete pointer;
pointer = NULL;
}
}

I strongly feel this should be a part of not rule and myth !!!

[jwakely]

Redundantly setting pointers to null doesn't cause bugs or do any harm, it's just dumb. A guideline to forbid it won't reduce bugs.

[xtofl]

Some member pointers are still used either concurrently or by other 'cleanup' member functions. Agreed, that's sloppy design, but it exists:

~MyObject() {
    cleanup_partA();
    cleanup_partB();
}
void cleanup_partA() {
    delete a;
    a = nullptr;
}
void cleanup_partB() { if (a) somestuff(a); }

[hsutter]

Editors call: Setting a pointer to null after delete is often suggested, but doesn't quite have the anticipated benefits because of dead store elimination and not resetting any other extant pointers to the object. We don't think that a rule either for or against is necessary.