Boost logo

Boost :

From: Markus Werle (numerical.simulation_at_[hidden])
Date: 2003-05-15 07:18:48

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

> 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, 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.
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

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.


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 ;-).

Compile time analytic differentiation? 
Yes, at 

Boost list run by bdawes at, gregod at, cpdaniel at, john at