delete a pointer

[Back9]

Hi,

When my snob co-work is codereviewing my code,
he use an expression on the following code.

delete a; <== my code

//His comments : You must set the ptr values back to NULL after
delete.

I know that it is good practice after deleting a pointer variable, to
set it NULL.
But my question is is it reuqired?
I hope somebody shows me c++ delete rules on this.

TIA

 

[osmium]

When my snob co-work is codereviewing my code,
he use an expression on the following code.

delete a; <== my code

//His comments : You must set the ptr values back to NULL after
delete.

I know that it is good practice after deleting a pointer variable, to
set it NULL.
But my question is is it reuqired?
I hope somebody shows me c++ delete rules on this.

No the language does not impose such a rule. And if there were such a rule,
how could the language enforce it? It is simply thought by many to be good
practice, as you have already said.

 

[Back9]

No the language does not impose such a rule.  And if there were such a rule,
how could the language enforce it?  It is simply thought by many to be good
practice, as you have already said.

Is it legitimate to use "MUST" in his comment?

 

[osmium]

Is it legitimate to use "MUST" in his comment?

Must can be a house rule. He who pays the bills specifies the tune.

 

[gwowen]

Is it legitimate to use "MUST" in his comment?

Sure, if the word is understood in the context of "I am your boss/
superior and you MUST do what I say or run the risk of losing your
job."

It's good practice -- it does almost no harm and can turn Heisenbugs
into predictable crashes. Unless you've got a very very very good
reason not to, take the advice, smile, and get on with your life.

 

[AnonMail2005]

Hi,

When my snob co-work is codereviewing my code,
he use an expression on the following code.

delete a;     <== my code

//His comments : You must set the ptr values back to NULL after
delete.

I know that it is good practice after deleting a pointer variable, to
set it NULL.
But my question is is it reuqired?
I hope somebody shows me c++ delete rules on this.

TIA

I've seen people do this type of thing in legacy code where it's not
clear who owns the pointed to object and what it's lifetime is. This
is usually before smart pointers became widely used and usually in C
code. Setting the pointer to 0 is defensive programming. It's
suggests bad design but sometimes there is nothing you can do in
legacy code.

If there is such a concern about this, I would not rely on programmers
to to this. I would make it a coding standard to not do raw deletes.
Force people to call a function that does delete and sets the pointer
to 0. Any newly changed code could be required to do this.

HTH

 

[Kai-Uwe Bux]

Hi,

When my snob co-work is codereviewing my code,
he use an expression on the following code.

delete a; <== my code

//His comments : You must set the ptr values back to NULL after
delete.

I know that it is good practice after deleting a pointer variable, to
set it NULL.

That is debatable. If you have

delete a;
a = 0;

and later

... *a ...;

you have undefined behavior, just as you would without the a = 0. The
language rules do not specify that you have a crash for one and a silent bug
for the other.


On the other hand,

delete a;
a = 0;

and later

delete a;

is a bug turned into a null-op. I would consider it better to find and
eliminate the bug as it may indicate a deeper problem. Such double deletions
can be found using tools such as valgrind but will be covered up by setting
the pointer variable 0 after deletion.


Finally,

b = a;
...
delete a;
a = 0;

... *b ...;

is not even affected.

But my question is is it reuqired?

By whom? Maybe your local coding guidelines say so.

I hope somebody shows me c++ delete rules on this.

The important ones are: you have undefined behavior for dereferencing a
pointer variable of null value or invalid value (due to prior deletion); you
also have undefined behavior when deleting a pointer of invalid value.

Important for whether setting the pointer value to 0 after deletion are,
however, not so much the language rules (it always just says undefined
behavior) but the actual compiler and tools used: the undefined behavior can
be different from one case to another and the practice may very well affect,
which undefined behavior you see. One kind of undefined behavior may be more
welcome than the other.


Best

Kai-Uwe Bux

 

[A]

I know that it is good practice after deleting a pointer variable, to

set it NULL.
But my question is is it reuqired?

It is not required. But the value of pointer is unpredictable then.

So for example if the pointer "a" was pointing to address 12345678 after
deleting it, it will deallocate memory used by the object it was pointing to
but the "a" may still hold a value of 12345678. (I say "may" because your
compiler may automatically reset it to 0 after your "delete").

The same as if you initialize a variable:

int a;

if you read a - it may hold 0 (for my compiler), but for yours it may be
some random value (whatever was stored in that part of memory).

The point is that you cannot count if that pointer will have a certain value
unless you set it again. You shouldn't use "a" after deleting it anyway
without assigning it with new value so in this case if your code is
something like:

function DoStuff()
{
int *a = new Object();

a->DoSomething();

delete a;
a = null;
}

in this case, setting a to null is completely redundant and unnecessary
because when the function ends "a" loses the scope anyway!

But I have a suggestion - rather than using delete, adopt using
std::auto_ptr - the same code looks like this then:

#include <memory>
function DoStuff()
{
std::auto_ptr <int> a(new Object);
a->DoSomething();
}

It takes some getting used to, but generally, much cleaner and no need to
worry about deleting an object.

As far as I know, auto_ptr has no performance penalties and is so much more
convenient to use. On the other hand smart pointers may have some
performance penalties.

 

[Jorgen Grahn]

Sure, if the word is understood in the context of "I am your boss/
superior and you MUST do what I say or run the risk of losing your
job."

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

Unless you've got a very very very good
reason not to, take the advice, smile, and get on with your life.

Depends on if he has a master--slave relationship, I suppose.
If not, I think it's /unprofessional/ to just bend over for
bad (or questionable) advice. It hurts the product, and it even
hurts the guy who made the rule -- he needs feedback, too.

/Jorgen

 

[A]

Here is one example where setting to null would have some use although I
would say this is a bad practice and not very clean code - it can be
probably restructured to be much cleaner:

int *a = new Object();
a->DoStuff();

if (some event) { delete a; a = null; }

// do something else

if (a != null)
{
// code if object is still defined
a->DoMoreStuff();
}
else
{
// code if object is undefined, print error or whatever
}

 

[Öö Tiib]

Not only. If there is established style/best pactice guide in house
that says it is must, then reviewer must say it is a must. Otherwise
he lies.

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.

Depends on if he has a master--slave relationship, I suppose.
If not, I think it's /unprofessional/ to just bend over for
bad (or questionable) advice.  It hurts the product, and it even
hurts the guy who made the rule -- he needs feedback, too.

You talk too much about slavery, bending over, harmful and hurting
things. This is not some sort of sado-maso newsgroup.

 

[Default User]

Is it legitimate to use "MUST" in his comment?

Do you have a Common Coding Standard for your project? If so, you be
familiar with it.



Brian

 

[Juha Nieminen]

No the language does not impose such a rule. And if there were such a rule,
how could the language enforce it?

Easily: By the compiler generating the code that assigns null to the
pointer after the object has been deleted.

Of course the C++ standard doesn't want to force compilers to do that if
the programmer doesn't want the program to spend the clock cycles on a
useless assignment in certain situations.

 

[Back9]

Hi,

When my snob co-work is codereviewing my code,
he use an expression on the following code.

delete a;     <== my code

//His comments : You must set the ptr values back to NULL after
delete.

I know that it is good practice after deleting a pointer variable, to
set it NULL.
But my question is is it reuqired?
I hope somebody shows me c++ delete rules on this.

TIA

Judging by your use of the word "snob", it sounds like the real issue
here is an underlying personal problem between you and your co-worker.
In technical terms, as other people have commented, you are not
obligated to set the pointer to NULL after delete, although it can in
some senses be seen as good practice.

The real issue, then, is how to handle any discussion with your
co-worker in a mature fashion. As a suggestion:

(a) Acknowledge that there are some arguments for what he is saying.
[Get him to listen to what you have to say next, rather than prepare for
a fight]
(b) Observe that it has the potential to hide some double deletion bugs,
so there is something of a trade-off involved. [Make your technical
point without acrimony]
(c) Suggest that it's probably not of great consequence, and perhaps
that the issue might even become moot if you were to use smart pointers
instead (depending on whether they're suitable for your project,
naturally). [Defuse the situation, and show that you are primarily
concerned about the good of the project, rather than having a pointless
fight]
(d) Offer to change your code along the lines described if he feels
strongly about it (it's possible that he doesn't: the comment doesn't
make it clear). If there's anything you want him to do, now is an
excellent time to bring it up (you're clearly implying a quid pro quo,
even if you don't explicitly link the two things). [Try and achieve a
win-win through negotiation, and build understanding for the future]

The bottom line is that the actual issue here is essentially trivial --
your real goal needs to be to maintain a good personal relationship with
your co-worker. If you waste time arguing about things like whether to
set pointers to NULL after a delete or not, your team as a whole will
suffer. Win wars, not battles.

Regards,
Stu

The point is in his code he did not follow the rule.
Seems he likes to show off his knowledge which he does not follow.

 

[Puppet_Sock]

Using 0 to flag a pointer that doesn't point to an object is a valid
technique, but it has to be designed into the application, not applied
ad hoc.

Probably true for most "guru advice" one could give
about C++, or many coding languages. <good practice X>
is a <positive adjective> technique, but it has to be
designed into the application, not applied ad hoc.

Personally, I try to keep my new-ed memory allocs in
classes. That way, for the most part, I'm only calling
delete in the dtor. Or in situations like a copy ctor
or an assignment, where the delete is followed in
short order by a new (or a copy or whatever). That
I'm not passing on over a pointer to invalid stuff.
Socks

 

[Puppet_Sock]

On May 7, 9:53 am, "(e-mail address removed)" <[email protected]>
wrote:
[snip]

If there is such a concern about this, I would not rely on programmers
to to this. I would make it a coding standard to not do raw deletes.
Force people to call a function that does delete and sets the pointer
to 0.  Any newly changed code could be required to do this.

Hmmm... I'm chewing on that one. I can't think of a
reason not to, but, well, hmmm...

So, the delete-in-a-condom-function. It's a template?
Socks

 

[AnonMail2005]

On May 7, 9:53 am, "(e-mail address removed)" <[email protected]>
wrote:
[snip]

If there is such a concern about this, I would not rely on programmers
to to this. I would make it a coding standard to not do raw deletes.
Force people to call a function that does delete and sets the pointer
to 0.  Any newly changed code could be required to do this.

Hmmm... I'm chewing on that one. I can't think of a
reason not to, but, well, hmmm...

So, the delete-in-a-condom-function. It's a template?
Socks

That's left as a exercise .

 

[Öö Tiib]

Judging by your use of the word "snob", it sounds like the real issue
here is an underlying personal problem between you and your co-worker.
In technical terms, as other people have commented, you are not
obligated to set the pointer to NULL after delete, although it can in
some senses be seen as good practice.

The real issue, then, is how to handle any discussion with your
co-worker in a mature fashion. As a suggestion:

(a) Acknowledge that there are some arguments for what he is saying.
[Get him to listen to what you have to say next, rather than prepare for
a fight]
(b) Observe that it has the potential to hide some double deletion bugs,
so there is something of a trade-off involved. [Make your technical
point without acrimony]
(c) Suggest that it's probably not of great consequence, and perhaps
that the issue might even become moot if you were to use smart pointers
instead (depending on whether they're suitable for your project,
naturally). [Defuse the situation, and show that you are primarily
concerned about the good of the project, rather than having a pointless
fight]
(d) Offer to change your code along the lines described if he feels
strongly about it (it's possible that he doesn't: the comment doesn't
make it clear). If there's anything you want him to do, now is an
excellent time to bring it up (you're clearly implying a quid pro quo,
even if you don't explicitly link the two things). [Try and achieve a
win-win through negotiation, and build understanding for the future]

The bottom line is that the actual issue here is essentially trivial --
your real goal needs to be to maintain a good personal relationship with
your co-worker. If you waste time arguing about things like whether to
set pointers to NULL after a delete or not, your team as a whole will
suffer. Win wars, not battles.

Regards,
Stu

The point is in his code he did not follow the rule.
Seems he likes to show off his knowledge which he does not follow.

Why you deal with his problems. Deal with yours. Learn to use good C++
programming practices.

As for review, it is good practice in good team to review each others
code. No one of us is a god, so we all make mistakes always. Someone
reviewing others code should have comments, otherwise it is clear that
he did not read it. It is sad that you take such comments personally.

 

[James Kanze]

When my snob co-work is codereviewing my code,
he use an expression on the following code.

delete a; <== my code

//His comments : You must set the ptr values back to NULL after
delete.

I know that it is good practice after deleting a pointer variable, to
set it NULL.
But my question is is it reuqired?
I hope somebody shows me c++ delete rules on this.

It's certainly not a C++ rule, and it's not generally considered
good practice (except in specific cases), since it doesn't buy
you anything.

 

[James Kanze]

Sure, if the word is understood in the context of "I am your
boss/ superior and you MUST do what I say or run the risk of
losing your job."

Then it's probably time to look for another job.

It's good practice -- it does almost no harm and can turn
Heisenbugs into predictable crashes. Unless you've got a very
very very good reason not to, take the advice, smile, and get
on with your life.

It's not generally considered good practice, since it doesn't
really change anything---all it does is give some people a false
sense of security.