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.

closed as off-topic by david.pfx, Kilian Foth, mattnz, Dan Pichelman, GlenH7 Jul 15 '14 at 2:42

  • This question does not appear to be about software engineering within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 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. – Greg Hewgill Jul 3 '14 at 0:09
  • 3
    "avoid asking subjective questions where … your question is just a rant in disguise: “______ sucks, am I right?”" (help center) – gnat Jul 3 '14 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 Jul 3 '14 at 12:19
  • 1
    One word: Cargo cult programming. – Thomas Eding Jul 3 '14 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 Jul 4 '14 at 9:44

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 Jul 3 '14 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 Jul 3 '14 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. – Bart van Ingen Schenau Jul 3 '14 at 6:37
  • 1
    Exactly, @Bart. A great example of C++ programmers habitually providing their own safety. – Karl Bielefeldt Jul 3 '14 at 12:52

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