jimad@microsoft.UUCP (Jim ADCOCK) (02/26/91)
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?
wmm@world.std.com (William M Miller) (02/26/91)
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
jimad@microsoft.UUCP (Jim ADCOCK) (02/28/91)
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.