🚀 go-pugleaf

Steve Clamage (clamage@Eng.Sun.COM) wrote:
: In article 95Sep1110410@physics12.Berkeley.EDU, tblancha@evolving.com (Todd Blanchard) writes:
: >This is common in C:
: >
: >#define free(X) { free(X); X=0; }
: >
: >You could do something similar in C++ as:
: >
: >void operator delete (void*& p, size_t s)
: >{
: >   ::delete p;
: >   p = 0;
: >}
: >
: >but the standard definition is:
: >void operator delete(void* p, size_t);
: >
: >Why is that?

: 1. The argument to operator delete need not be an lvalue:
: 	T* foo();
: 	...
: 	delete foo();

Possibly, but zeroing a ref to temp is still harmless.

: 2.  Believing that this approach solves the dangling pointer problem even
: in C, is naive, and leads to a false sense of security. The program might
: have any number of copies of the pointer which was deleted, and the copies
: would still dangle. You have to use a design discipline that keeps track of
: who owns the heap object and under what circumstances it is to be deleted.

This is plain insulting.  I know how to manage memory.  I continue to look
for techniques to reduce the consequences of screw-ups.

I never said it solved the dangling pointer problem.  It can help mitigate
it though.  Half a life jacket is better than no life jacket at all.  Idiotic
unix hackers that call any attempt to reduce the consequences of brain lock
"naive" and insist on leaving everything as dangerous as possible so people will
retain that heightened sense of awareness one gets living in a war zone are
clearly the naive ones.  

Designers could try telling the truth once in awhile and say something like:
"Nobody thought of it early enough and its too late to change now."
Which I suspect is more likely.

--
-----------------------------------------------------------------------
Todd Blanchard                                    tblancha@evolving.com
Evolving Systems Inc.                               VOX: (303) 689-1798
                                                    FAX: (303) 689-1399
"Never underestimate the power of stupid people in large groups."
-----------------------------------------------------------------------
---
[ 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. ]