TITLE: Thoughts on delete and zeroing pointers


RESPONSE: Jamshid Afshar (jamshid@emx.utexas.edu)

I think explicitly setting the pointer to 0 after a delete (when
necessary) would be the best approach and would cause the least
confusion and surprise for other C++ programmers.


RESPONSE: bs@alice.att.com (Bjarne Stroustrup)

Actually, `delete' is explicitly allowed to invalidate its operand
provided that operand is an lvalue. I think it would be a good idea
for implementations to do that so that

	X* p = something;
	// ...
	delete p;

would leave p==0.


RESPONSE: warsaw@nlm.nih.gov (Barry A. Warsaw @ Century Computing, Inc.)

But if allowed != required, isn't
 
	delete p;
	p=0;

necessary for portability?


RESPONSE: bs@alice.att.com (Bjarne Stroustrup)

Not really. After `delete p' the value of p is undefined and should not be
used in any way. An implementation that sets p==0 simply provides a service
that makes it a bit easier to detect illegal uses of p. It is what many call
a `quality of implementation issue.'


RESPONSE: steve@taumet.com (Steve Clamage)

Only if you depend on p having a zero value after the delete.

I believe the point was to make possible a positive error indication
when dereferencing a dangling pointer.  Currently, the results of
doing so are undefined, since it is in general expensive to detect,
and not everyone wants to pay the cost every time.

Even with mandatory nulling, you would still have the problem of
other copies of the pointer which might be hanging around:
	
	T *p = new T;
	T *q = p;
	delete p;	// q dangles, no matter what happens to p

Bjarne's suggestion addresses a quality of implementation issue,
rather than the general problem.


RESPONSE: price@linus.serum.kodak.com (Kevin Price)
          x37128 @ Clinical Products Division, Eastman Kodak Company

I agree that this would be a good idea, especially for native C programmers who are
used to counting on NULL pointers after deallocation.  I for one got bitten on
a few occasions by assuming that a pointer would be == 0 after a delete.  However,
if this decision is left to implementers, I expect there will be an awful lot of
unportable code from folks who depend on such an assumption.  Should it become
a language rule?  Why or why not?


RESPONSE: bs@alice.att.com (Bjarne Stroustrup)

It is unwise to rely on p==0 after `delete p;' or `free(p)' because it is not
guaranteed (in C or C++). The reason it couldn't be a language rule is that
the argument to delete or free needn't be an lvalue so that delete and free
has nothing they could zero out. For example:

	delete some_fct(p);
	free( &p[i] );

Thus the language could at best guarantee that some deleted pointers were
zero'd out and that is a very weak guarantee.


RESPONSE: bs@alice.att.com (Bjarne Stroustrup)

Please note that unless you add the restriction (not in C or C++)
that the argument to delete (free in the case of C) must be an lvalue
the compiler cannot guarantee that deleted pointers are zero'd out.

That is not a restriction that I think that I or anyone else can
impose in general, but it is one that a programmer can impose on
his or her own program and enforce through the use of a suitable
operation that deletes objects

	void destroy(T*& p) 
	{
		delete p;
		p = 0;
	}

Using a non-const reference argument ensures a warning from the compiler
if you try to destroy a non-lvalue. For more than one type, use a template