Re: delete a pointer
On 09.05.2010 14:38, * ?? Tiib:
On 8 mai, 21:23, James Kanze<james.ka...@gmail.com> wrote:
On May 7, 4:40 pm, ?? Tiib<oot...@hot.ee> wrote:
On May 7, 5:34 pm, Jorgen Grahn<grahn+n...@snipabacken.se> wrote:
On Fri, 2010-05-07, gwowen wrote:
On May 7, 2:12 pm, Back9<backgoo...@gmail.com> wrote:
It's good practice -- it does almost no harm and can turn
Heisenbugs into predictable crashes.
It will also hide bugs from memory debuggers (which are in
wide use these days, with valgrind being available for
free). I don't like the rule at all -- I find it harmful (as
a general rule).
What bugs will hide:
delete a;
a = NULL;
From what it will hide these? Sounds surprizing. It exposes
bugs and does not hide. You should explain how this rule is
harmful.
It creates the impression that it exposes bugs, but it doesn't.
(I don't think it hides any, however. It just gives a false
sense of security.)
It does give that "this pointer does not propagate dangling values"
sense of security. How this is false sense?
First, you can have more than one pointer to the same object, and in that case
the assignment of 0 just lies.
Secondly, the only purpose of the 0 is to check it. Checking it means that the
code holds on to that pointer variable so that there's a need for checking it.
This in turn means fewer invariants available and higher complexity, which means
higher probability of bugs, not lower.
And so it *can* give a false sense of security.
On the other hand, 0 can be more likely to be detected when the pointer is later
used incorrectly.
So it all depends.
The one case such a rule might make sense is if you're using
garbage collection, since a garbage collector won't collect the
memory if there is a valid pointer to it (even if the destructor
has run). Most of the time, even there, however, there's no
point in it, since the pointer will either be reused, or go out
of scope.
Assigning 0 to pointer is valid form of reusing it. 0 is useful value
of pointer. Value that points at unavailable places causes bugs when
it is used.
No, such values do not cause bugs. They /are/ bugs. But I think you mean that
it's easier to detect incorrect use of a pointer when it's 0, and it may be.
The only time this rule makes any sense at all is if the pointer
will be reused, but not immediately, and you have to check to
determine whether it is already in use before reusing it. (The
classical example is a cached computed value. If you do
anything which might change the value, you delete and null the
pointer, and if you need the value, you check for null before
recalculating it.)
It seems like there are just fixed set of cases. In some cases
assigning 0 is pointless and in other cases it is fruitful. The cases
when the rule does not make sense are when pointer is immediately
reused again or leaves scope or is destroyed itself.
Or when there are other pointers to the object. Or when the quality is high
enough that the costs of assigning 0 outweights the marginal advantage. The
costs include false sense of security, more code, and being steered towards
using unsafe raw pointer handling.
So, again, it all depends.
Cheers, & hth.,
- Alf
(blog at <url: alfps.wordpress.com>, started on thursday)