If I had a dime for every time I've seen this macro in use, today I would be coding just for fun:

#define SAFE_DELETE(p) if ((p) != NULL) { delete (p); (p) = NULL; }

Why do programmers insist in keep using this macro when delete checks for null? Is is because it sets the pointer to null at the end? Then why not at least rewrite it and remove the redundant check:

#define SAFE_DELETE(p) { delete (p); (p) = NULL; }

Still, it doesn't seem like a good practice.

  • 2
    For some reason there is a considerable amount of superstition surrounding NULL checks with delete and free(). I suspect the fact that these checks are harmless make them justifiable in the minds of those who haven't read the documentation. Commented Jul 3, 2014 at 0:09
  • 3
    "avoid asking subjective questions where … your question is just a rant in disguise: “______ sucks, am I right?”" (help center)
    – gnat
    Commented Jul 3, 2014 at 3:56
  • 1
    One possible justfication is if it's a micro-optimisation. If delete results in a function call, then SAFE_DELETE avoids that call if the pointer is null.
    – Simon B
    Commented Jul 3, 2014 at 12:19
  • 1
    One word: Cargo cult programming. Commented Jul 3, 2014 at 18:26
  • 3
    This question appears to be off-topic because it is (a) a rant and (b) asking for psychological insight rather than solving a genuine problem
    – david.pfx
    Commented Jul 4, 2014 at 9:44

1 Answer 1


Let me put it this way. Does it seem like something C++ would do? C++ is replete with gotchas and undefined behavior, but in this one instance, it helpfully validates a parameter for you? Every other "safer" language you know throws an exception if you try to do anything with a null pointer, but the unsafest language you use just handles it cleanly? It's not self-consistent. People take the safe approach because in nearly every other case, C++ forces the programmer to take the safe approach. In other words, in C++ code, "Bring Your Own Validation" is idiomatic and habitual. It doesn't look right when it's missing.

  • +1 I have been guilty of this, for exactly those reasons.
    – J Trana
    Commented Jul 3, 2014 at 1:11
  • 2
    I'm not sure if a agree with the case that delete accepting null quietly is inconsistent. Termination/shutdown in C++ is supposed to be fail-safe, inasmuch as possible. Destructors can't throw exceptions, so it kind of makes sense that delete is tolerating of a null pointer.
    – glampert
    Commented Jul 3, 2014 at 2:04
  • 2
    @glampert: There in nothing in C++ that stops you from throwing an exception in a destructor. It is just considered bad form, because it can cause abrupt termination of the program. Commented Jul 3, 2014 at 6:37
  • 1
    Exactly, @Bart. A great example of C++ programmers habitually providing their own safety. Commented Jul 3, 2014 at 12:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.