operator delete modifying pointers?

Thread View: comp.std.c++

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Jim ADCOCK Mon, 25 Feb 1991 22:05

#858

Author: Jim ADCOCK
Date: Mon, 25 Feb 1991 22:05

12 lines
1022 bytes

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?

Re: operator delete modifying pointers?

#863

Author: William M Miller
Date: Tue, 26 Feb 1991 01:57

18 lines
1536 bytes

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

Re: operator delete modifying pointers?

#887

Author: Jim ADCOCK
Date: Wed, 27 Feb 1991 22:04

22 lines
1884 bytes

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.

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads