ARM page 63 seems to be saying that implementations are permitted that
change pointer values as a result of a delete.  For example, doing a
delete on a pointer might cause a pointer to be set to zero, so that
a deleted object may not be sucessfully accessed via the deleted pointer
after delete.

Is this true?

If so, shouldn't overloaded operator deletes also support a first parameter
of reference-to-void-pointer, so that programmers can implement their own
operator deletes that change pointers to null [or some other value]
as a side-effect of deleting via that pointer?

jimad@microsoft.UUCP (Jim ADCOCK) writes:
>        shouldn't overloaded operator deletes also support a first parameter
> of reference-to-void-pointer, so that programmers can implement their own
> operator deletes that change pointers to null [or some other value]
> as a side-effect of deleting via that pointer?

That's an interesting thought.  It's not quite that simple, though, since a
typed pointer is not compatible with a void*& and, in general, can't be.  On
some architectures, the representation of an address as a void* is different
from the representation of that same address expressed as a pointer to some
other data type.  In order to implement your suggestion, it would require
that all pointers be required to have the void* representation and would
introduce an implicit cast of the operand of "delete" to void*& before
invoking the operator delete().  The latter is just a definitional thing,
but the former could have significant performance impact.

-- William M. Miller, Glockenspiel, Ltd.
   wmm@world.std.com

In article <1991Feb26.015730.15749@world.std.com> wmm@world.std.com (William M Miller) writes:
|jimad@microsoft.UUCP (Jim ADCOCK) writes:
|>        shouldn't overloaded operator deletes also support a first parameter
|> of reference-to-void-pointer, so that programmers can implement their own
|> operator deletes that change pointers to null [or some other value]
|> as a side-effect of deleting via that pointer?
|
|That's an interesting thought.  It's not quite that simple, though, since a
|typed pointer is not compatible with a void*& and, in general, can't be.  On
|some architectures, the representation of an address as a void* is different
|from the representation of that same address expressed as a pointer to some
|other data type.  In order to implement your suggestion, it would require
|that all pointers be required to have the void* representation and would
|introduce an implicit cast of the operand of "delete" to void*& before
|invoking the operator delete().  The latter is just a definitional thing,
|but the former could have significant performance impact.

Okay, points well taken.  Implementations where object pointers are
compatible with void pointers can offer reference-to-void deletes
-- if so desired, and compilers in general can "automatically" null-out
pointers on delete as a debugging option.  I agree with your arguments
that this shouldn't be "required" of all implementations.