Puppet_Sock wrote:
Lav wrote:
[snip] Better practice would be
delete b1;
b1 = NULL;
because you never know how delete 'ed variable are going to respond.
While this won't *cause* problems (so far as I'm aware)
it won't catch plenty of common newbie problems.
Name one problem that it won't catch that not setting to 0 does.
I try to keep pointers as data members of a class.
I also try to keep it such that the pointer is assigned to
memory in an initiation step such as a ctor or a named
ctor, and deleted in the dtor. This way, my memory leaks
and wild pointers are as localized as I can make them,
and tend to be easier to find and easier to correct.
It is much easier to tell that there is a problem when the pointer has
an obviously erroneous value, like 0, instead of a possibly valid one.
It is hard to figure out that the problem is caused by your object
having been deleted if it looks like a valid object. By setting to 0
you not only increase the likely hood of being able to check if the
pointer has been deleted before calling it, you also increase the
obviousness of the problem when you don't. It is also, though
undefined, much more likely to crash than do something completely
random as read/write to location 0 is always bad and outside your
memory space.
For example. Say you have the following code:
delete x;
When it runs you get an explosion. Why? You look at your ptr and it
has some random value...the object appears normal. Why did it blow up?
You trace back a few miles and end up in some OS specific event loop
and into no-man's land. There is no indication as to why you are
exploding, yet it does. Somewhere, in response to some previous event,
/something/ happened to some object related to that instruction...or
maybe it suffered from a heap thrashing as described below...
What would happen if you had set that value to 0?
Imagine the following code in that scenario:
x->doY(); // doY() writes to a buffer inside an X.
What happens if that pointer was not set to 0? Half the time it
crashes and half the time you get odd heap corruptions and you crash in
totally unrelated areas of code; now you need special debugger tools
and libraries to track buffer overruns and heap corruptions when they
occur and not when their effect is felt...this can take hours, days,
weeks.... What if you had set that to 0? Well, in most systems, you
would crash immediately (except in cases like the OP when the class is
VERY trivial) and the fact that it was because the ptr is invalid would
be very obvious. You could then either fix the logic error that caused
you to do this on a deleted pointer, or if there is no logic problem
and you just need to make sure it never happens:
if (x) x->doY();
There are numerous cases when setting the pointer to 0 saves time by
making bugs more obvious, making intent and purpose clear, and removing
double deletions. There are a few situations in which it doesn't
matter. There is no situation in which it is better not to and there
is no way to track what is happening unless you do.