I ran into my first compiler that changes the lvalue passed to ::delete, but doesn't zero out the lvalue. That is the following is true:
Foo * p = new Foo();
Foo * q = p;
assert(p != 0);
assert(p == q);
::delete p;
assert(p != q);
assert(p != 0);
Note that p is not zero after the delete operation, and it has changed from it's old value. A coworker told me that this is not unusual in his experience having worked with some mainframe C++ compilers that would change p to 0xFFFFFFFF, as well as other compilers that would change p to 0.
Where in the C++ Standard does it say that a compiler is allowed to do this?
Searching through StackOverflow, I found this question: Why doesn’t delete set the pointer to NULL? which had an answer that referred to Bjarne Stroustrup's response that includes the statement:
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.
I've read and re-read section 5.3.5 and 12.5 of the final committee draft C++0x standard, but I'm not seeing the "explicit" part. Am I just looking in the wrong sections of the standard? Or is there a chain of logic that is in the sections but I'm just not connecting together properly.
I don't have my copy of the Annotated C++ Reference Manual anymore. Was it in the ARM that a compiler could do this?
[Edit: Correcting the section reference from 3.5.3 to 5.3.5. I'm also adding an interesting paradox as a counterpoint to Henk's assertion that p is undefined after delete.]
There is an interesting paradox if p is initialized to null.
Foo * p = 0;
Foo * q = p;
assert(p == 0);
assert(p == q);
::delete p;
assert(p == q);
assert(p == 0);
In this case though, the behavior is well documented. When delete gets a null pointer, it is suppose to do nothing, so p remains unchanged.