delete on delete !

Discussion in 'C++' started by Sandeep Grover, Jul 12, 2003.

  1. Hi,

    If I do another delete on an object which has been deleted earlier, then
    how is
    the system expected to behave ?

    Is it an unpredictable behavior ??

    Thanks
    Sandeep
    Sandeep Grover, Jul 12, 2003
    #1
    1. Advertising

  2. Sandeep Grover wrote:
    > Hi,
    >
    > If I do another delete on an object which has been deleted earlier, then
    > how is
    > the system expected to behave ?
    >
    > Is it an unpredictable behavior ??
    >


    Yes, unpredictable.

    Some will choke, some destructors SEGV, it goes on and on.
    Gianni Mariani, Jul 12, 2003
    #2
    1. Advertising

  3. Sandeep Grover

    Scott Condit Guest

    Sandeep Grover wrote:

    > If I do another delete on an object which has been deleted earlier, then
    > how is the system expected to behave?
    >
    > Is it an unpredictable behavior ??


    It's undefined, so in theory, yes; anything could happen.

    S
    Scott Condit, Jul 12, 2003
    #3

  4. > Sandeep Grover wrote:
    >
    > > If I do another delete on an object which has been deleted earlier, then
    > > how is the system expected to behave?
    > >
    > > Is it an unpredictable behavior ??

    >
    > It's undefined, so in theory, yes; anything could happen.
    >
    > S


    Thanks !

    So, if I have an array of pointers; more than one of the entries could point
    to
    the same chunk of memory (allocated using new). How do I ensure that I
    end up deleting that entry only once. I dont want to use reference-counting
    kind of thing in constructor.
    Sandeep Grover, Jul 12, 2003
    #4
  5. On Fri, 11 Jul 2003 16:53:31 -0700, Sandeep Grover <> wrote:

    >f I have an array of pointers; more than one of the entries could
    >point to the same chunk of memory (allocated using new). How do I ensure
    >that I end up deleting that entry only once. I dont want to use
    >reference-counting kind of thing in constructor.


    The sane thing to do would be to use reference-counting.

    Reference-counting is automated by many smart-pointers; the most general
    and compatible with upcoming standard is boost::shared_ptr (go to
    <url:hhtp://www.boost.org> to download the Boost library, it's free).

    Without reference-counting you can just sort the array first, on the
    pointer values; even though pointers that do not point into the same
    variable are not formally comparable, they are comparable in practice.
    But you need to know that the array contains pointers to all objects
    that you need to delete. And in that case, why not store the unique
    pointers in a separate array of the same size or less?
    Alf P. Steinbach, Jul 12, 2003
    #5
  6. "Sandeep Grover" <> wrote in message
    news:...
    >
    >
    > > Sandeep Grover wrote:
    > >
    > > > If I do another delete on an object which has been deleted earlier,

    then
    > > > how is the system expected to behave?
    > > >
    > > > Is it an unpredictable behavior ??

    > >
    > > It's undefined, so in theory, yes; anything could happen.
    > >
    > > S

    >
    > Thanks !
    >
    > So, if I have an array of pointers; more than one of the entries could

    point
    > to
    > the same chunk of memory (allocated using new). How do I ensure that I
    > end up deleting that entry only once. I dont want to use

    reference-counting
    > kind of thing in constructor.



    Use a vector of the objects you want, or a list if it suits better the
    problem, and not a built in array of pointers.







    --
    Ioannis

    * Programming pages: http://www.noicys.freeurl.com
    * Alternative URL 1: http://run.to/noicys
    * Alternative URL 2: http://www.noicys.cjb.net
    Ioannis Vranos, Jul 12, 2003
    #6
  7. Sandeep Grover

    Pete Becker Guest

    "Alf P. Steinbach" wrote:
    >
    > Without reference-counting you can just sort the array first, on the
    > pointer values; even though pointers that do not point into the same
    > variable are not formally comparable, they are comparable in practice.


    If you use std::greater, std::less, std::greater_equal, or
    std::less_equal they are comparable. It's just the builtin operators
    that are allowed to be fast. <g>

    --

    "To delight in war is a merit in the soldier,
    a dangerous quality in the captain, and a
    positive crime in the statesman."
    George Santayana

    "Bring them on."
    George W. Bush
    Pete Becker, Jul 12, 2003
    #7
  8. Sandeep Grover

    Scott Condit Guest

    Sandeep Grover wrote:
    >
    >>Sandeep Grover wrote:
    >>
    >>
    >>>If I do another delete on an object which has been deleted earlier, then
    >>>how is the system expected to behave?
    >>>
    >>>Is it an unpredictable behavior ??

    >>
    >>It's undefined, so in theory, yes; anything could happen.
    >>
    >>S

    >
    >
    > Thanks !
    >
    > So, if I have an array of pointers; more than one of the entries could point
    > to the same chunk of memory (allocated using new). How do I ensure that I
    > end up deleting that entry only once. I dont want to use reference-counting
    > kind of thing in constructor.


    A flippant answer would be not to alias pointers.

    On the other hand, techniques such as reference-counting
    are for when you need multiple pointers to the same object
    which you wish to dispose of independently, but don't need
    an invasive implementation, i.e. an implementation inside
    the pointed-to object.

    But this is really a design issue, not a language issue.

    S
    Scott Condit, Jul 12, 2003
    #8
  9. "Ioannis Vranos" <> wrote in message
    news:3f0f5032$0$240$...
    | "Sandeep Grover" <> wrote in message
    | news:...
    | > Hi,
    | >
    | > If I do another delete on an object which has been deleted earlier, then
    | > how is
    | > the system expected to behave ?
    |
    |
    | It will get angry.

    Depends.

    | > Is it an unpredictable behavior ??

    | Yes it is undefined behaviour. It may die, it may continue living and die
    | later, it may truncate data, everything.

    Again it depends.

    If you set the pointer to zero straight after you have deleted
    it, then the behaviour is very defined, and safe.

    For example:

    # include <iostream>
    # include <ostream>

    struct Base
    {
    int N;
    };

    int main()
    {
    Base* B = new Base;

    delete B;
    B = 0; // Introduce a safety net.

    for( int Idx( 0 ); Idx < 5; ++Idx )
    delete B; // Safe - no opp.

    return 0;
    }

    Cheers.
    Chris Val
    Chris \( Val \), Jul 12, 2003
    #9
  10. "Chris ( Val )" <> wrote in message
    news:beocjc$7bdj4$-berlin.de...
    >
    >
    > | Yes it is undefined behaviour. It may die, it may continue living and

    die
    > | later, it may truncate data, everything.
    >
    > Again it depends.
    >
    > If you set the pointer to zero straight after you have deleted
    > it, then the behaviour is very defined, and safe.



    He/she said:

    "If I do another delete on an object which has been deleted earlier, then
    how is the system expected to behave ?".


    That means that the pointer will not point to 0.




    --
    Ioannis

    * Programming pages: http://www.noicys.freeurl.com
    * Alternative URL 1: http://run.to/noicys
    * Alternative URL 2: http://www.noicys.cjb.net
    Ioannis Vranos, Jul 12, 2003
    #10
  11. "Ioannis Vranos" <> wrote in message
    news:3f10201e$0$233$...
    | "Chris ( Val )" <> wrote in message
    | news:beocjc$7bdj4$-berlin.de...
    | >
    | >
    | > | Yes it is undefined behaviour. It may die, it may continue living and
    | die
    | > | later, it may truncate data, everything.
    | >
    | > Again it depends.
    | >
    | > If you set the pointer to zero straight after you have deleted
    | > it, then the behaviour is very defined, and safe.
    |
    |
    | He/she said:
    |
    | "If I do another delete on an object which has been deleted earlier, then
    | how is the system expected to behave ?".

    Yes, I know that.

    | That means that the pointer will not point to 0.

    That is why I said:

    *If you set the pointer to zero *straight after* you have deleted it*

    Meaning, the first time you delete it, set it to zero, making the
    behaviour of deleting it again defined and safe.

    Cheers.
    Chris Val
    Chris \( Val \), Jul 12, 2003
    #11
  12. On Sun, 13 Jul 2003 02:21:37 +1000, "Chris \( Val \)" <> wrote:

    >
    >"Ioannis Vranos" <> wrote in message
    >news:3f10201e$0$233$...
    >| "Chris ( Val )" <> wrote in message
    >| news:beocjc$7bdj4$-berlin.de...
    >| >
    >| >
    >| > | Yes it is undefined behaviour. It may die, it may continue living and
    >| die
    >| > | later, it may truncate data, everything.
    >| >
    >| > Again it depends.
    >| >
    >| > If you set the pointer to zero straight after you have deleted
    >| > it, then the behaviour is very defined, and safe.
    >|
    >|
    >| He/she said:
    >|
    >| "If I do another delete on an object which has been deleted earlier, then
    >| how is the system expected to behave ?".
    >
    >Yes, I know that.
    >
    >| That means that the pointer will not point to 0.
    >
    >That is why I said:
    >
    >*If you set the pointer to zero *straight after* you have deleted it*
    >
    >Meaning, the first time you delete it, set it to zero, making the
    >behaviour of deleting it again defined and safe.


    It's possibly not meaningful to discuss the finer points of language
    here, but at least regarding the last few postings there seems to be
    confusion about the concept of deleting an object (which cannot be
    done without a non-null pointer value) and "deleting a pointer",
    probably meaning to use that pointer in a delete expression, which if
    it has a technical meaning would be a totally _different_ meaning.

    Since the original poster wrote about deleting objects, not pointers,
    and furthermore about deleting the same object twice, the only
    reasonable interpretation is that what was meant was first deleting
    the object, and then performing a delete operation again on the now
    invalid pointer value (which for this technically can't be zero).

    Setting a pointer to zero after the object it denoted has been
    deleted is not an evil practice, though, but don't rely on it to catch
    all errors associated with deallocation -- some argue that it might
    give a false sense of security + complicates the code + may hide some
    errors/bugs, and therefore should be _avoided_ one hundred percent.
    Alf P. Steinbach, Jul 12, 2003
    #12
  13. "Alf P. Steinbach" <> wrote in message
    news:...
    | On Sun, 13 Jul 2003 02:21:37 +1000, "Chris \( Val \)" <> wrote:
    |
    | >
    | >"Ioannis Vranos" <> wrote in message
    | >news:3f10201e$0$233$...
    | >| "Chris ( Val )" <> wrote in message
    | >| news:beocjc$7bdj4$-berlin.de...
    | >| >
    | >| >
    | >| > | Yes it is undefined behaviour. It may die, it may continue living and
    | >| die
    | >| > | later, it may truncate data, everything.
    | >| >
    | >| > Again it depends.
    | >| >
    | >| > If you set the pointer to zero straight after you have deleted
    | >| > it, then the behaviour is very defined, and safe.
    | >|
    | >|
    | >| He/she said:
    | >|
    | >| "If I do another delete on an object which has been deleted earlier, then
    | >| how is the system expected to behave ?".
    | >
    | >Yes, I know that.
    | >
    | >| That means that the pointer will not point to 0.
    | >
    | >That is why I said:
    | >
    | >*If you set the pointer to zero *straight after* you have deleted it*
    | >
    | >Meaning, the first time you delete it, set it to zero, making the
    | >behaviour of deleting it again defined and safe.
    |
    | It's possibly not meaningful to discuss the finer points of language
    | here, but at least regarding the last few postings there seems to be
    | confusion about the concept of deleting an object (which cannot be
    | done without a non-null pointer value) and "deleting a pointer",
    | probably meaning to use that pointer in a delete expression, which if
    | it has a technical meaning would be a totally _different_ meaning.

    Fair enough.

    | Since the original poster wrote about deleting objects, not pointers,
    | and furthermore about deleting the same object twice, the only
    | reasonable interpretation is that what was meant was first deleting
    | the object, and then performing a delete operation again on the now
    | invalid pointer value (which for this technically can't be zero).

    I understand the context in which the OP posted his/her question.

    I only provided an suggestion. That is why I used words such as:
    'depends', 'if' and 'after'.

    | Setting a pointer to zero after the object it denoted has been
    | deleted is not an evil practice, though, but don't rely on it to catch
    | all errors associated with deallocation -- some argue that it might
    | give a false sense of security + complicates the code + may hide some
    | errors/bugs, and therefore should be _avoided_ one hundred percent.

    I've never heard anyone suggest that before.
    Can you give me an example of where such circumstances can arise ?.

    Cheers.
    Chris Val
    Chris \( Val \), Jul 12, 2003
    #13
  14. On Sun, 13 Jul 2003 03:29:50 +1000, "Chris \( Val \)" <> wrote:

    >"Alf P. Steinbach" <> wrote in message
    >news:...
    >| Setting a pointer to zero after the object it denoted has been
    >| deleted is not an evil practice, though, but don't rely on it to catch
    >| all errors associated with deallocation -- some argue that it might
    >| give a false sense of security + complicates the code + may hide some
    >| errors/bugs, and therefore should be _avoided_ one hundred percent.
    >
    >I've never heard anyone suggest that before.
    >Can you give me an example of where such circumstances can arise ?.


    Not that this is my argument, I think the pros and cons nearly cancel
    out, but here is one scenario. A firm or shop or project standardizes
    on setting pointers to zero after delete. Such pointers can safely be
    passed to functions that check for null, and so they're passed around.
    In one function there is an incorrect delete via the passed pointer.
    This isn't detected because the pointer is null. Later that function
    is used with a more valuable real pointer value. It then incorrectly
    deletes an object it shouldn't. The effect only shows up much later
    in the code execution, and it's then very hard to track down the cause.
    Alf P. Steinbach, Jul 12, 2003
    #14
  15. "Chris ( Val )" <> wrote in message
    news:bepgic$7fgni$-berlin.de...
    >
    >
    > I've never heard anyone suggest that before.
    > Can you give me an example of where such circumstances can arise ?.




    There are many philosophical approaches. Many believe -including me- that
    the second deletion of an object is the last thing of improper use one will
    do on it, before he will have tried to read or write to it.

    A better use is always use the standard library containers instead of
    allocating and deallocating memory explicitly. So for example, instead of
    using an array of pointers, use a vector of objects or whatever container of
    the standard library fits your purpose better (e.g. a list).







    --
    Ioannis

    * Programming pages: http://www.noicys.freeurl.com
    * Alternative URL 1: http://run.to/noicys
    * Alternative URL 2: http://www.noicys.cjb.net
    Ioannis Vranos, Jul 12, 2003
    #15
  16. "Ioannis Vranos" <> wrote in message
    news:3f10654a$0$240$...
    | "Chris ( Val )" <> wrote in message
    | news:bepgic$7fgni$-berlin.de...
    | >
    | >
    | > I've never heard anyone suggest that before.
    | > Can you give me an example of where such circumstances can arise ?.
    |
    |
    |
    | There are many philosophical approaches. Many believe -including me- that
    | the second deletion of an object is the last thing of improper use one will
    | do on it, before he will have tried to read or write to it.

    Point taken.

    | A better use is always use the standard library containers instead of
    | allocating and deallocating memory explicitly. So for example, instead of
    | using an array of pointers, use a vector of objects or whatever container of
    | the standard library fits your purpose better (e.g. a list).

    Agreed.

    Cheers.
    Chris Val
    Chris \( Val \), Jul 13, 2003
    #16
  17. Sandeep Grover

    Ashish Guest

    "Sandeep Grover" <> wrote in message
    news:...
    >
    >
    > > Sandeep Grover wrote:
    > >
    > > > If I do another delete on an object which has been deleted earlier,

    then
    > > > how is the system expected to behave?
    > > >
    > > > Is it an unpredictable behavior ??

    > >
    > > It's undefined, so in theory, yes; anything could happen.
    > >
    > > S

    >
    > Thanks !
    >
    > So, if I have an array of pointers; more than one of the entries could

    point
    > to
    > the same chunk of memory (allocated using new). How do I ensure that I
    > end up deleting that entry only once. I dont want to use

    reference-counting
    > kind of thing in constructor.
    >


    How can you point two pointers (allocated using new) to the same location???
    If you are pointing a pointer to an already allocated piece of memory, you
    CANT use the "reference-counting kind of thing in constructor".

    The best solution, IMHO, would be to use smart pointers.


    --
    -Ashish
    --------------------------------------------------------------------------
    Hi! I'm a shareware signature! Send $5 if you use me, send $10 for manual!
    http://www.123ashish.com http://www.softwarefreaks.com

    >
    >
    Ashish, Jul 14, 2003
    #17
  18. Sandeep Grover

    Ashish Guest

    "Chris ( Val )" <> wrote in message
    news:bepcig$70vir$-berlin.de...
    >
    > "Ioannis Vranos" <> wrote in message
    > news:3f10201e$0$233$...
    > | "Chris ( Val )" <> wrote in message
    > | news:beocjc$7bdj4$-berlin.de...
    > | >
    > | >
    > | > | Yes it is undefined behaviour. It may die, it may continue living

    and
    > | die
    > | > | later, it may truncate data, everything.
    > | >
    > | > Again it depends.
    > | >
    > | > If you set the pointer to zero straight after you have deleted
    > | > it, then the behaviour is very defined, and safe.
    > |
    > |
    > | He/she said:
    > |
    > | "If I do another delete on an object which has been deleted earlier,

    then
    > | how is the system expected to behave ?".
    >
    > Yes, I know that.
    >
    > | That means that the pointer will not point to 0.
    >
    > That is why I said:
    >
    > *If you set the pointer to zero *straight after* you have deleted it*


    I think you have misunderstood the problem.
    The OP's problem is that more than one pointers point to the same location.

    Lets assume that p1 and p2 point to location m1.
    Delete m1 using p1.
    Set p1 to NULL.
    So far so good.
    Now, delete p2, the behaviour is undefined. And you had no idea that p2 also
    points to m1.


    >
    > Meaning, the first time you delete it, set it to zero, making the
    > behaviour of deleting it again defined and safe.
    >
    > Cheers.
    > Chris Val
    >
    >



    --
    -Ashish
    --------------------------------------------------------------------------
    Hi! I'm a shareware signature! Send $5 if you use me, send $10 for manual!
    http://www.123ashish.com http://www.softwarefreaks.com
    Ashish, Jul 14, 2003
    #18
  19. "Chris ( Val )" wrote:
    >
    > | I think you have misunderstood the problem.
    > | The OP's problem is that more than one pointers point to the same location.
    > |
    > | Lets assume that p1 and p2 point to location m1.
    > | Delete m1 using p1.
    > | Set p1 to NULL.
    > | So far so good.
    > | Now, delete p2, the behaviour is undefined. And you had no idea that p2 also
    > | points to m1.
    >
    > Yes, that is true.
    >
    > However, its the programmers job and responsibility to keep
    > track of such things, and take preventative measures to avoid
    > this issue all together.
    >


    Exactly.

    But especially newbies tend to think: If I set the pointer to
    0 immediatly after the delete, nothing bad can happen any more.
    This (having a second pointer to the same object) is a counter-
    example. That's why lots of programmers warn about setting
    a pointer to 0: It creates a false sense of security.
    Don't get me wrong: setting a pointer to 0 can't do any harm
    and is often a good idea. But it doesn't solve all dynamic
    memory related problems.

    --
    Karl Heinz Buchegger
    Karl Heinz Buchegger, Jul 15, 2003
    #19
  20. "Karl Heinz Buchegger" <> wrote in message
    news:...
    |
    |
    | "Chris ( Val )" wrote:
    | >
    | > | I think you have misunderstood the problem.
    | > | The OP's problem is that more than one pointers point to the same location.
    | > |
    | > | Lets assume that p1 and p2 point to location m1.
    | > | Delete m1 using p1.
    | > | Set p1 to NULL.
    | > | So far so good.
    | > | Now, delete p2, the behaviour is undefined. And you had no idea that p2 also
    | > | points to m1.
    | >
    | > Yes, that is true.
    | >
    | > However, its the programmers job and responsibility to keep
    | > track of such things, and take preventative measures to avoid
    | > this issue all together.
    | >
    |
    | Exactly.
    |
    | But especially newbies tend to think: If I set the pointer to
    | 0 immediatly after the delete, nothing bad can happen any more.
    | This (having a second pointer to the same object) is a counter-
    | example. That's why lots of programmers warn about setting
    | a pointer to 0: It creates a false sense of security.
    | Don't get me wrong: setting a pointer to 0 can't do any harm
    | and is often a good idea. But it doesn't solve all dynamic
    | memory related problems.

    Point taken :).

    Thanks Karl.
    Chris Val
    Chris \( Val \), Jul 22, 2003
    #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. HeroOfSpielburg
    Replies:
    1
    Views:
    385
    Alf P. Steinbach
    Aug 6, 2003
  2. 0to60
    Replies:
    4
    Views:
    311
    Jerry Coffin
    Dec 19, 2003
  3. Mathieu Malaterre

    delete NULL, what about delete[] NULL

    Mathieu Malaterre, Aug 17, 2004, in forum: C++
    Replies:
    2
    Views:
    3,819
    Mathieu Malaterre
    Aug 17, 2004
  4. Jef Driesen
    Replies:
    1
    Views:
    500
    Gernot Frisch
    Jan 19, 2005
  5. DamonChong
    Replies:
    11
    Views:
    565
    msalters
    Jan 31, 2005
Loading...

Share This Page