🚀 go-pugleaf

tblancha@evolving.com (Todd Blanchard) writes:

>Don Organ (dorgan@megatest.com) wrote:

>: > Steve Clamage (stephen.clamage@eng.sun.com) wrote:
>: > 
>: > Except in this case, the approach had been discussed years ago and rejected
>: > as not a good idea. See D&E, for example.

>Todd Replies:  Its not there.  Got a page#?

I was certain that I had seen this in D&E or in the ARM, but the
discussion appears not to be in either place. The main reasons are
what I gave originally:

1. You can call operator delete with something which cannot be modified.
Page 63 of the ARM hints at this reason, but doesn't come out and say it.
	T* f();
	T* const p = new T;
	T& q = *(new T);
	...
	delete f();
	delete p;
	delete &q;
None of these delete expressions would be allowed if operator delete
took a void*&.

2. Even if you set the pointer to null after a delete, you may
still have other copies of the pointer in the program. If delete
did the nulling automatically, it would provide a false sense of
security that you didn't have to worry about dangling pointers
when in fact you do need to worry about them. If you use a
programming discipline that ensures pointers don't dangle, you
then don't need to set the pointers to null. If you still want
to set them to null anyway, you can. For example, use a function
to do the deleting, and set the pointer to null in that function.

I asked Bjarne Stroustrup if he had any other reasons in mind
and he confirmed that these were the reasons.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]