Why doesn't delete set the pointer to NULL?

I always wondered why automatic setting of the pointer to NULL after delete is not part of the standard. If this gets taken care of then many of the crashes due to an invalid pointer would not occur. But having said that I can think of couple of reasons why the standard would have restricted this:

> 1. Performance: > > An additional instruction could slow down the delete performance. >
> 2. Could it be because of const pointers. > > Then again standard could have done something for this special case I guess.

Does anyone know exact reasons for not allowing this?

Stroustrup himself answers. An excerpt:

> C++ explicitly allows an > implementation of delete to zero out > an lvalue operand, and I had hoped > that implementations would do that, > but that idea doesn't seem to have > become popular with implementers.

But the main issue he raises is that delete's argument need not be an lvalue.

First, setting to null would require a memory stored variable. It's true, that you usually have a pointer in a variable but sometimes you might want to delete an object at a just calculated address. That would be impossible with "nullifying" delete.

Then comes performance. You might have written code in such a way that the pointer will go out of scope immediately after delete is done. Filling it with null is just a waste of time. And C++ is a language with "don't need it? then you don't have to pay for it" ideology.

If you need safety there's a wide range of smart pointers at you service or you can write your own - better and smarter.

You can have multiple pointers pointing to that memory. It would create a false sense of security if the pointer you specified for the delete got set to null, but all the other pointers did not. A pointer is nothing more than an address, a number. It might as well be an int with a dereference operation. My point is you would have to also scan every single pointer to find those that are referencing the same memory you just deleted, and null them out as well. It would be computationally intense to scan all the pointers for that address and null them out, because the language is not designed for that. (Although some other languages structure their references to accomplish a similar goal in a different way.)

A pointer can be saved in more than one variable, setting one of these to NULL would still leave invalid pointers in the other variables. So you don't really gain much, you are more likely creating a false sense of security.

Besides of that, you can create your own function that does what you want:

template<typename T>
void deleten(T *&ptr) {
  delete ptr;
  ptr = NULL;
}

Because there isn't really any need to, and because it would require delete taking pointer-to-pointer rather than just pointer.

delete is used mostly in destructors, in which case setting a member to NULL is pointless. A few lines later, at the closing }, the member no longer exists. In assignment operators, a delete is typically followed by an assignment anyway.

Also, it would render the following code illegal:

T* const foo = new T;
delete foo;

Here's another reason; suppose delete does set its argument to NULL:

int *foo = new int;
int *bar = foo;
delete foo;

Should bar get set to NULL? Can you generalize this?

If you have an array of pointers, and your second action is to delete the empty array, then there is no point setting each value to null when the memory is about to be freed. If you want it to be null.. write null to it :)

C++ allows you to define your own operator new and delete so that for instance they would use your own pool allocator. If you do this then it is possible to use new and delete with things that are not strictly addresses but say indexes in your pool array. In this context the value of NULL (0) might have a legal meaning (referring to the first item in the pool).
So having delete set NULL automatically to its argument doesn't always have the meaning of - set the value to an invalid value. The invalid value may not always be NULL.

Philosophy of C++ is "pay for it only if you use it". I think it may answer your question.

Also sometimes you could have your own heap which will recover deleted memory.. or sometimes pointer not owned by any variable. Or pointer stored in few variables - it possible zero just one of them.
As you can see it have many issues and possible problems.

Setting the pointer to NULL automatically would not solve most of the issues with bad pointer usage. The only crash it would avoid is if you try to delete it twice. What if you call a member function on such a pointer? It would still crash (assuming that it accesses member variables). C++ does not restrict you from calling any function on NULL pointers, nor should it do that from performance point of view.

I see people giving weird answers to this question.

ptr = NULL; How can such a simple statement cause performance delay?

Another answer is saying that we can have multiple pointers pointing to the same memory location. Surely we can. In this case delete operation on one pointer would make only that pointer NULL (if delete was making pointer NULL) and the other pointer would be non-NULL and pointing to memory location which is free.

The solution for this should have been that user should delete all pointers pointing to same location. Internally it should check if memory is already freed than don't free. Only make the pointer NULL.

Stroustrup could have designed delete to work in this manner. He thought programmers would take care of this. So he ignored.