delete a pointer

Discussion in 'C++' started by Back9, May 7, 2010.

  1. Back9

    Back9 Guest

    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
     
    Back9, May 7, 2010
    #1
    1. Advertising

  2. Back9

    osmium Guest

    Back9 wrote:

    > 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.
     
    osmium, May 7, 2010
    #2
    1. Advertising

  3. Back9

    Back9 Guest

    On May 7, 9:03 am, "osmium" <> wrote:
    > Back9 wrote:
    > > 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.


    Is it legitimate to use "MUST" in his comment?
     
    Back9, May 7, 2010
    #3
  4. Back9

    osmium Guest

    Back9 wrote:

    > On May 7, 9:03 am, "osmium" <> wrote:
    >> Back9 wrote:
    >>> 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.

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


    Must can be a house rule. He who pays the bills specifies the tune.
     
    osmium, May 7, 2010
    #4
  5. Back9

    gwowen Guest

    On May 7, 2:12 pm, Back9 <> wrote:
    > > 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?


    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.
     
    gwowen, May 7, 2010
    #5
  6. Back9

    Guest

    On May 7, 8:52 am, Back9 <> wrote:
    > 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
     
    , May 7, 2010
    #6
  7. Back9

    Kai-Uwe Bux Guest

    Back9 wrote:

    > 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
     
    Kai-Uwe Bux, May 7, 2010
    #7
  8. Back9

    A Guest

    > 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.
     
    A, May 7, 2010
    #8
  9. Back9

    Jorgen Grahn Guest

    On Fri, 2010-05-07, gwowen wrote:
    > On May 7, 2:12 pm, Back9 <> wrote:
    >> > 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?

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

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, May 7, 2010
    #9
  10. Back9

    A Guest

    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
    }
     
    A, May 7, 2010
    #10
  11. Back9

    Öö Tiib Guest

    On May 7, 5:34 pm, Jorgen Grahn <> wrote:
    > On Fri, 2010-05-07, gwowen wrote:
    > > On May 7, 2:12 pm, Back9 <> wrote:
    > >> > 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?

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


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

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


    You talk too much about slavery, bending over, harmful and hurting
    things. This is not some sort of sado-maso newsgroup. :D
     
    Öö Tiib, May 7, 2010
    #11
  12. Back9

    Default User Guest

    "Back9" <> wrote in message
    news:...

    > 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
     
    Default User, May 7, 2010
    #12
  13. osmium <> wrote:
    > 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.
     
    Juha Nieminen, May 7, 2010
    #13
  14. Back9

    Back9 Guest

    On May 7, 11:15 am, Stuart Golodetz
    <> wrote:
    > Back9 wrote:
    > > 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.
     
    Back9, May 7, 2010
    #14
  15. Back9

    Puppet_Sock Guest

    On May 7, 12:51 pm, Pete Becker <> wrote:
    [snip]
    > 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, May 7, 2010
    #15
  16. Back9

    Puppet_Sock Guest

    On May 7, 9:53 am, "" <>
    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
     
    Puppet_Sock, May 7, 2010
    #16
  17. Back9

    Guest

    On May 7, 1:58 pm, Puppet_Sock <> wrote:
    > On May 7, 9:53 am, "" <>
    > 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 ;).
     
    , May 7, 2010
    #17
  18. Back9

    Öö Tiib Guest

    On 7 mai, 19:59, Back9 <> wrote:
    > On May 7, 11:15 am, Stuart Golodetz
    >
    >
    >
    > <> wrote:
    > > Back9 wrote:
    > > > 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.


    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.
     
    Öö Tiib, May 8, 2010
    #18
  19. Back9

    James Kanze Guest

    On May 7, 1:52 pm, Back9 <> wrote:
    > 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
     
    James Kanze, May 8, 2010
    #19
  20. Back9

    James Kanze Guest

    On May 7, 2:19 pm, gwowen <> wrote:
    > On May 7, 2:12 pm, Back9 <> wrote:


    > > > 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?


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

    --
    James Kanze
     
    James Kanze, May 8, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    10
    Views:
    704
    Chris Torek
    Feb 4, 2005
  2. jimjim
    Replies:
    16
    Views:
    843
    Jordan Abel
    Mar 28, 2006
  3. morz
    Replies:
    7
    Views:
    453
    Marco Wahl
    Feb 6, 2006
  4. Replies:
    4
    Views:
    1,268
    Fred Zwarts
    Jul 2, 2009
  5. A
    Replies:
    7
    Views:
    639
Loading...

Share This Page