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.
Why do programmers still use SAFE_DELETE?
c++;memory
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.