Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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.
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.
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.
NULLchecks withdeleteandfree(). I suspect the fact that these checks are harmless make them justifiable in the minds of those who haven't read the documentation.