I just realized after years of writing C++, that I can safely delete a NULL pointer. So I figure, I'm not the only one that wasn't aware of this. Now I feel silly for all my
if(p) delete p;
code laying around.
Am I the only one that hadn't realized this? Or is it a less known feature of C++?
A lot of C programmers don't realise that the same is true of malloc and free.
A more interesting question is WHY programmers (both C and C++) don't realise this - it is spelt out clearly in the reference section of K&R and on page 128 of Stroustrup.
Not sure about C++, but in Delphi you can call Free on a nil pointer and it causes no problems.
Despite that, I continue to check for nil/NULL, just as a sanity check.
Yep.. one of the first things we learnt. No need to check for null when deleting. But if someone has already deleted the object and forgot to set the pointer to NULL, then you have a problem.
In the beginning I didn't know. I learnt this after reading C++ FAQ Do I need to check for NULL before delete p?
It says that "The C++ language guarantees that delete p will do nothing if p is equal to NULL"
Ho, yes i know that ...
But I spent a lot of time fighting with people who write their own "operator new / delete" without knowing that sort of thing : As they usually are of the bytes-and-processing-cycles-are-precious family they would rather sell their mother down the river than checking for NULL in every call of their precious "optimized" operator.
So it seems the books are not clear enough about it !
Kind of an odd question really. The cost of the 'problem' is not really that large.
Now one reason to-do it, is it allows you to call debugging commands that check for invalid pointers, or memory usage counting, etc
Another such nifty fact is that 'this' can equal NULL (although the standard stands it's an undefined behavior). For example:
MyClass *myob = NULL;
myob->myfun();
Inside myfun() 'this' pointer will equal NULL.
yes i know... deleting a null pointer does not have any side effect. But i wonder why it is done in project I work
if(NULL != pSomeObject)//any reason for checking for null
{
delete pSomeObject;
pSomeObject = NULL;//any reason for assigning null
}
is-there-any-reason-to-check-for-a-null-pointer-before-deleting
Something similar, the new operator always returns a valid pointer, in other case it throws an exception, so very common code like:
MyClass *p = new MyClass;
if(!p)
return;
doesn't make sense.
Safe operation of delete NULL doesnt payoff too much unless you normalize (set to NULL) already deleted pointers. Although its odd, in most cases i use self grown functions that look like this:
void DoDelete(void **p)
{
if(! p || ! *p)
return;
delete *p;
*p = NULL;
}
This is the only way to automatically avoid deleting a already deleted pointer. Of course this aint no use within a STL-Container or alike.
I estimate that about 1,200,000 people are aware of this, and the other 5,998,800,000 are still unaware.
I only just found out about this yesterday, feel kinda dumb now
In one project I work on the recommendation is to always check for NULL before calling free(). Yes, it's not needed according to the standard, but supposedly there are platforms out there where libc ties itself into a knot if you try to free a NULL pointer, and this particular project is portable to a plethora of platforms.
Though I have no idea if such platforms are actually used today, or if the rule is just some leftover from 20 years ago that nobody has bothered to update. Anybody know better?
Am I the only one that hadn't realized this?
No. Probably, other people don't know it yet.
Or is it a less known feature of C++?
It's a basic piece of knowledge in C++. But, for some reason, a number of people have misconceptions about it.