There's no harm in deleting a null pointer; it often reduces the number of tests at the tail of a function if the unallocated pointers are initialized to zero and then simply deleted.
Since the previous sentence has caused confusion, an example — which isn't exception safe — of what is being described:
void somefunc(void)
{
SomeType *pst = 0;
AnotherType *pat = 0;
…
pst = new SomeType;
…
if (…)
{
pat = new AnotherType[10];
…
}
if (…)
{
…code using pat sometimes…
}
delete[] pat;
delete pst;
}
There are all sorts of nits that can be picked with the sample code, but the concept is (I hope) clear. The pointer variables are initialized to zero so that the delete operations at the end of the function do not need to test whether they're non-null in the source code; the library code performs that check anyway.
delete performs the check anyway, so checking it on your side adds overhead and looks uglier. A very good practice is setting the pointer to NULL after delete (helps avoiding double deletion and other similar memory corruption problems).
I'd also love if delete by default was setting the parameter to NULL like in
#define my_delete(x) {delete x; x = NULL;}
(I know about R and L values, but wouldn't it be nice?)
$5.3.5/2 - "[...]In either
alternative, the value of the operand
of delete may be a null pointer
value.[...'"
Of course, no one would ever do 'delete' of a pointer with NULL value, but it is safe to do. Ideally one should not have code that does deletion of a NULL pointer. But it is sometimes useful when deletion of pointers (e.g. in a container) happens in a loop. Since delete of a NULL pointer value is safe, one can really write the deletion logic without explicit checks for NULL operand to delete.
As an aside, C Standard $7.20.3.2 also says that 'free' on a NULL pointer does no action.
The free function causes the space
pointed to by ptr to be deallocated,
that is, made available for further
allocation. If ptr is a null pointer,
no action occurs.
Yes it is safe.
There's no harm in deleting a null pointer; it often reduces the number of tests at the tail of a function if the unallocated pointers are initialized to zero and then simply deleted.
Since the previous sentence has caused confusion, an example — which isn't exception safe — of what is being described:
There are all sorts of nits that can be picked with the sample code, but the concept is (I hope) clear. The pointer variables are initialized to zero so that the
delete
operations at the end of the function do not need to test whether they're non-null in the source code; the library code performs that check anyway.Deleting a null pointer has no effect. It's not good coding style necessarily because it's not needed, but it's not bad either.
If you are searching for good coding practices consider using smart pointers instead so then you don't need to
delete
at all.delete
performs the check anyway, so checking it on your side adds overhead and looks uglier. A very good practice is setting the pointer to NULL afterdelete
(helps avoiding double deletion and other similar memory corruption problems).I'd also love if
delete
by default was setting the parameter to NULL like in(I know about R and L values, but wouldn't it be nice?)
From the C++0x draft Standard.
Of course, no one would ever do 'delete' of a pointer with NULL value, but it is safe to do. Ideally one should not have code that does deletion of a NULL pointer. But it is sometimes useful when deletion of pointers (e.g. in a container) happens in a loop. Since delete of a NULL pointer value is safe, one can really write the deletion logic without explicit checks for NULL operand to delete.
As an aside, C Standard $7.20.3.2 also says that 'free' on a NULL pointer does no action.
To complement ruslik's answer, in C++14 you can use that construction:
I have experienced that it is not safe (VS2010) to delete[] NULL (i.e. array syntax). I'm not sure whether this is according to the C++ standard.
It is safe to delete NULL (scalar syntax).