[boost] Re: checked_delete without assignment to 0 - why?

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2003-05-15 10:26:59

On Thu, 15 May 2003 14:18:48 +0200, Markus Werle
<numerical.simulation_at_[hidden]> wrote:

>Gennaro Prota wrote:
>
>> [...] 
>
>> nullifying the pointer is generally considered 
>> a way to _hide_ bugs, 
>
>I doubt Herb Sutter hides bugs.
>sed -es/generally considered/IMHO/g

But have you seen his code? The '=0' is in the destructor of the
object that contains the pointer! It is absolutely useless there.
That's one of the things that made me suppose you were a newbie. The
other one, heavier, was that you wanted to zero-out a pointer passed
by value. Of course it's not a misdeed either to be a newbie and to
direct someone to a beginners' newsgroup. To me the question seemed 3%
about a boost design/naming decision, and 97% about why nullifying the
pointer isn't logically part of the deletion, or a "safe" thing to do
in general. It is not, and that should appear obvious if you think how
many pointers to the same memory you can have.

>
>> rather than eliminating them. I don't want to be dogmatic
>> here, but I've never encountered the necessity to double delete
>> anything.
>
>It is not about double delete,

Ok.

>but about code which 
>is guaranteed to check some pointer for equality with 0 
>before use:
>
>E.g. in my application it is cheaper to run over a 
>fixed-sized vector of pointers rather than using a container 
>holding only the ones pointing to accessible data.
>
>This is where a simple deletion is insufficient and nullifying 
>is _not_ hiding bugs, but the correct way to express
>a _complete_ destruction/erasure alias a true zero.

Then you can use delete_and_null :-)

>Any use of smart pointers in that place multiplies the 
>runtime by inacceptable factors, so the use of raw pointers 
>and DeleteAndNullify is _the_ thing to do.
>
>Therefore I was thinking of re-using something like 
>boost::checked_delete, and simply curious about why the 
>assignment was omitted, which was the reason for the OP. 
> 
>After taking a closer look at the boost::smart_pointer's code
>I can finally see they never rely on the "value" of the raw 
>pointer after its deletion and therefore it is perfectly OK 
>to avoid additional assignment in checked_delete for the sake of 
>efficiency.
>
>OTOH, since I think 
>template <typename T> void delete_and_null(T*& p);
>is a useful function I would propose it for inclusion into boost.
>
>
>Markus
>
>
>P.S.: Thank You for pointing me to alt.comp.lang.learn.c-c++,
>but I doubt they tell me the reason for design or naming decisions 
>in the boost library ;-). 

They won't :-) However I don't see what nullifying the pointer has to
do with "checked" delete. Your question appeared to me more like "why
don't we make it even safer by nullifying the pointer?" than anything
else. And that's surely a newbie one (a similar question: why C++
doesn't nullify... etc. is even in Bjarne Stroustrup's FAQ, IIRC). If
there's a way to find *all* pointers to an object and nullify them
then I understand. Otherwise making the nullify a logical part of the
delete only gives a false sense of security.

int * p = .....;
...
q = p;

delete p;
p=0;

...

if (q != 0) // oops...

The very same 'if' above is undefined behavior, even if q isn't
dereferenced. I've read this a lot of times on c.l.c++.m, and that's
why I said "generally considered", rather than IMHO :-) Sorry if you
felt hurt though, it wasn't my intention.

Genny.