Doesn't null check before delete/free optimize out the call to the function?

There are several questions regarding if to put null check before delete or not. Now, I have still seen such practices in many production code and I don't believe that all those programmers were unaware of the fact that delete 0; is safe.

So, I wonder that isn't it wor开发者_开发百科th assuming that null check before delete/free would provide a performance optimization by saving a function call ?

if(0 != p)
  delete p;

---

No. delete is not a function, though there may be an operator delete call behind it depending on the type.

At best you're saving a second comparison to 0. It's all premature optimisation: none of this will be your bottleneck, and you're writing redundant code.

Just write:

delete ptr;

---

I don't believe that all those programmers were unaware of the fact that delete 0; is safe.

Well, they were. That's pretty much it. It's a fact that delete or free on null is perfectly safe. If they weren't unaware of it, then they wouldn't have wasted time checking for it.

So, I wonder that isn't it worth assuming that null check before delete/free would provide a performance optimization by saving a function call ?

You're making an assumption ... ... because what, you don't want to believe that those guys are wrong? Sorry, buddy- they were wrong, and that's that. You've got no evidence or rational reasons to believe that doing a null check has such a benefit.

Or that whoever wrote that code thought so. After all, even if you could eliminate a function call this way, the cost of the function call here is miniscule, if it's not inlined, which it may well be, and it costs more for the programmer time to write the check, which is already written for you. I'd rather be over-zealous about correctness than prematurely optimize like this- are you genuinely doing anyone a favour by suggesting that it may be an optimization?

---

Now, I have still seen such practices in many production code and I don't believe that all those programmers were unaware of the fact that delete 0; is safe.

Long, long ago there was no guarantee that delete (and free) would harmlessly do nothing with a null pointer. Instead they blew up with some compilers / some machines. Hence the origin of the practice.

What keeps this practice alive is a combination of cargo cult programming and small mind mentality ("A foolish consistency is the hobgoblin of small minds.") Cargo cult programmers use cut-and-paste, so when they see some widely-used syntax they copy it. In this case, because some code does that null pointer check, a cargo cult programmer will think that that is the way to do it.

Small mind mentality dictates that there is only one way to do it. Because some decrepit legacy code that no one wants to touch uses this null pointer check, all code must release dynamically-allocated memory this way. I have seen coding standards for multiple projects that mandate this behavior (and those coding standards themselves are created by cargo cult techniques).