Set a pointer to null when deleting?

[Joe Van Dyk]

When you delete a pointer, you should set it to NULL, right?

Joe

[Old Wolf]

Phlip wrote:

Noah Roberts wrote:

p = getPointerFromW hatever();
if (p)
p->method(42); p = getPointerFromW hatever();
assert(p);
p->method(42);

The code is one tick simpler; it has one less 'if' statement.

Really? What is that assert doing there then?

It is not increasing the mental burden of reading the function.

I find the if(p) version less burdensome to read, and simpler.
You mention that the assert version is "simpler" because it
does not have a "control structure". But the assert() is
performing control flow. What's worse is that that flow
is opaque: what happens when the assert fails? We can't
tell from this example. But in the if() code, if p is null
then we know exactly what will happen (the code will
continue on with whatever statements follow this snippet).

[Noah Roberts]

Old Wolf wrote:

I find the if(p) version less burdensome to read, and simpler.
You mention that the assert version is "simpler" because it
does not have a "control structure". But the assert() is
performing control flow. What's worse is that that flow
is opaque: what happens when the assert fails? We can't
tell from this example. But in the if() code, if p is null
then we know exactly what will happen (the code will
continue on with whatever statements follow this snippet).

I think for most cases the if (p) version is adiquate, simplest, and
more easily read/dealt with. There are some cases when a null object
is better such as when dealing with states where there can be a 'null'
state. If you have a bunch of polymorphic objects implementing an
abstract interface anyway it can be better to implement the null
condition with an actual object than with a 0 pointer...somet imes.
However, replacing every occurance of 'if(p)' with a null object is
crazyness and if you have no control over the class you are pointing to
it just plain won't work in most cases.

[Ian Collins]

Old Wolf wrote:

Phlip wrote:

Noah Roberts wrote:

p = getPointerFromW hatever();
if (p)
p->method(42);

p = getPointerFromW hatever();
assert(p);
p->method(42);

The code is one tick simpler; it has one less 'if' statement.

Really? What is that assert doing there then?

It is not increasing the mental burden of reading the function.

I find the if(p) version less burdensome to read, and simpler.
You mention that the assert version is "simpler" because it
does not have a "control structure". But the assert() is
performing control flow. What's worse is that that flow
is opaque: what happens when the assert fails? We can't
tell from this example. But in the if() code, if p is null
then we know exactly what will happen (the code will
continue on with whatever statements follow this snippet).

Potentially dangerous without an else?

I'm not supporting the assert alternative, but there should be some
error handling. On a lot of systems, the assert would be largely
superfluous as attempting to dereference the (NULL) pointer would case a
crash.

--
Ian Collins.

[Noah Roberts]

Ian Collins wrote:

Potentially dangerous without an else?

I'm not supporting the assert alternative, but there should be some
error handling. On a lot of systems, the assert would be largely
superfluous as attempting to dereference the (NULL) pointer would case a
crash.

Well, in this case, the original code that used the assert used a 'null
object'. It was used as an argument for such constructs and the
question of how it applied was never really adiquately answered. The
idea was that with a normal pointer you had to use an if (p) p->do()
where with a null object you would assert(p); p->do();...and this is
simpler...

- shrug -

[peter koch]

Noah Roberts skrev:

C. J. Clegg wrote:

On Mon, 10 Apr 2006 13:58:52 GMT, Joe Van Dyk <jo********@boe ing.com>
wrote:

> When you delete a pointer, you should set it to NULL, right?
You don't HAVE to.
doesn't hurt and is often helpful.

It is not always helpful. Also the ptr = 0 sends the wrong message to
the reader - is the pointer reset now and then or what is it that takes
place. And there it is. There is no reason NOT to beyond linespace fetishes.
There is one very good reason: to verify your program logic. Accessing
a resource that is no longer present is an obvious programming error,
and setting the pointer to 0 might just prevent that situation from
being identified.
If you are going to set the pointer to anything, it is a far better
idea to set it to some illegal value the same way as operator delete
sets memory to an often illegal pattern in some debug builds.
If the pointer is used to designate an optional value, the situation is
different and you should set the pointer to 0. It can save from hours to days debugging. In fact, if you set your
pointers to 0 all the time then some bugs will never bite you that
otherwise would have taken hours or days to debug. Deleting a 0
pointer is not an error, deleting any other pointer that has been
deleted already is and can be one of the most difficult types of errors
to track down.

It is one minor step you can use to help you keep bugs out of your
programs. Scope isn't the issue, getting in the habit of ALWAYS doing
it benefits you in numerous ways.

Also notice that the reset will not always prevent the error. Actually,
I believe that it will do so only in the most trivial of situations.
The OPs problem would not be solved by setting the pointer to 0, for
example.

/Peter

[Phlip]

Ian Collins wrote:

I'm not supporting the assert alternative

There never was an assert() alternative. The question was raised why
advanced programmers were not simply declaring all dead pointers should be
NULLed. I brought in NullObjects as an advanced alternative. The assert()
was to prevent nitpicking. A better implementation would hide the pointer,
and its assertions, and pass around a reference.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Noah Roberts]

peter koch wrote:

Noah Roberts skrev:

C. J. Clegg wrote:

On Mon, 10 Apr 2006 13:58:52 GMT, Joe Van Dyk <jo********@boe ing.com>
wrote:

>> When you delete a pointer, you should set it to NULL, right?

You don't HAVE to.
doesn't hurt and is often helpful.

It is not always helpful. Also the ptr = 0 sends the wrong message to
the reader - is the pointer reset now and then or what is it that takes
place.

ptr = 0 is well defined. Everyone that is familiar with the language
knows exactly what it does.

And there it is. There is no reason NOT to beyond linespace fetishes.

There is one very good reason: to verify your program logic. Accessing
a resource that is no longer present is an obvious programming error,
and setting the pointer to 0 might just prevent that situation from
being identified.

Not true.
If you are going to set the pointer to anything, it is a far better
idea to set it to some illegal value the same way as operator delete
sets memory to an often illegal pattern in some debug builds.
This idea is very non-portable for one and doesn't follow standard
practice. Talk about being difficult to understand...

There is absolutely no reason to go looking for some other value to set
a pointer to. All that does is introduce problems in both
understandabili ty, platform dependance, and undefined behavior.
If the pointer is used to designate an optional value, the situation is
different and you should set the pointer to 0.

It can save from hours to days debugging. In fact, if you set your
pointers to 0 all the time then some bugs will never bite you that
otherwise would have taken hours or days to debug. Deleting a 0
pointer is not an error, deleting any other pointer that has been
deleted already is and can be one of the most difficult types of errors
to track down.

It is one minor step you can use to help you keep bugs out of your
programs. Scope isn't the issue, getting in the habit of ALWAYS doing
it benefits you in numerous ways.

Also notice that the reset will not always prevent the error. Actually,
I believe that it will do so only in the most trivial of situations.
The OPs problem would not be solved by setting the pointer to 0, for
example.

The problem of deleting a pointer that was already deleted, the problem
I was talking about in the quote above, will ALWAYS be solved by
setting the pointer's value to 0. No other access can be solved in
this manner beyond the fact that you can now check the pointer's value
before accessing it...just as delete does.

[Noah Roberts]

Phlip wrote:

Ian Collins wrote:

I'm not supporting the assert alternative

There never was an assert() alternative. The question was raised why
advanced programmers were not simply declaring all dead pointers should be
NULLed. I brought in NullObjects as an advanced alternative. The assert()
was to prevent nitpicking. A better implementation would hide the pointer,
and its assertions, and pass around a reference.

Dude, the null object pattern has its place, and it isn't _everywhere_.

[andrew queisser]

"Phlip" <ph******@yahoo .com> wrote in message
news:2h******** *********@newss vr33.news.prodi gy.com...

Ian Collins wrote:

I'm not supporting the assert alternative

There never was an assert() alternative. The question was raised why
advanced programmers were not simply declaring all dead pointers should be
NULLed.

Phlip,

If you're referring to my statement "I'm a little surprised at the responses
you've been getting from some very experienced programmers.", what I meant
was that I'm surprised that in response to a very specific question the
replies were "smart pointer" and some guesses about what the pointer is
actually pointing at. I'm not at all surprised that experienced programmers
would not advocate "set all dead pointers to NULL." Over the years I've come
to the conclusion that mindlessly adding good- practice code snippets can do
more harm than good.

Andrew

[peter koch]

Noah Roberts skrev:

peter koch wrote:

Noah Roberts skrev:

C. J. Clegg wrote:
> On Mon, 10 Apr 2006 13:58:52 GMT, Joe Van Dyk <jo********@boe ing.com>
> wrote:
>
> >> When you delete a pointer, you should set it to NULL, right?
>
> You don't HAVE to.
> doesn't hurt and is often helpful.
It is not always helpful. Also the ptr = 0 sends the wrong message to
the reader - is the pointer reset now and then or what is it that takes
place.

ptr = 0 is well defined. Everyone that is familiar with the language
knows exactly what it does.

Surely, But the reader asks "why" and thats a different question to
answer.

And there it is. There is no reason NOT to beyond linespace fetishes.
There is one very good reason: to verify your program logic. Accessing
a resource that is no longer present is an obvious programming error,
and setting the pointer to 0 might just prevent that situation from
being identified.

Not true.

Sure? Examples given in this thread would specifically behave that way.
Far to often you write if (p != 0) p->action() instead of assert(p !=
0); p->action();

If you are going to set the pointer to anything, it is a far better
idea to set it to some illegal value the same way as operator delete
sets memory to an often illegal pattern in some debug builds.
This idea is very non-portable for one and doesn't follow standard
practice. Talk about being difficult to understand...

There is absolutely no reason to go looking for some other value to set
a pointer to. All that does is introduce problems in both
understandabili ty, platform dependance, and undefined behavior.

That is a small problem as this is only something to do while
debugging.

If the pointer is used to designate an optional value, the situation is
different and you should set the pointer to 0.

It can save from hours to days debugging. In fact, if you set your
pointers to 0 all the time then some bugs will never bite you that
otherwise would have taken hours or days to debug. Deleting a 0
pointer is not an error, deleting any other pointer that has been
deleted already is and can be one of the most difficult types of errors
to track down.

It is one minor step you can use to help you keep bugs out of your
programs. Scope isn't the issue, getting in the habit of ALWAYS doing
it benefits you in numerous ways.

Also notice that the reset will not always prevent the error. Actually,
I believe that it will do so only in the most trivial of situations.
The OPs problem would not be solved by setting the pointer to 0, for
example.

The problem of deleting a pointer that was already deleted, the problem
I was talking about in the quote above, will ALWAYS be solved by
setting the pointer's value to 0. No other access can be solved in
this manner beyond the fact that you can now check the pointer's value
before accessing it...just as delete does.

Right. But that is a trivial situation - in all respects. Typically you
instead have two pointers pointing to the same object and delete one of
these. A problem that can't be solved without using smart pointers (or
discipline).

/Peter