Check If Object Deleted

Discussion in 'C++' started by Mark, Sep 29, 2007.

  1. Mark

    Mark Guest

    Hi,

    I would like to check if my object has been deleted or not, but my
    program keeps crashing. Here's the simplified code (in infinite loop)

    delete tetromino;
    //if(tetromino==NULL)
    tetromino = new TetrominoI;

    This continuously replaces the tetromino as expected, but if I take
    away the comment it crashes. How can I check if my object has been
    deleted or not?

    Thanks
     
    Mark, Sep 29, 2007
    #1
    1. Advertising

  2. Mark

    Ian Collins Guest

    Mark wrote:
    > Hi,
    >
    > I would like to check if my object has been deleted or not, but my
    > program keeps crashing. Here's the simplified code (in infinite loop)
    >
    > delete tetromino;
    > //if(tetromino==NULL)
    > tetromino = new TetrominoI;
    >
    > This continuously replaces the tetromino as expected, but if I take
    > away the comment it crashes. How can I check if my object has been
    > deleted or not?
    >

    You can't, unless you either set the pointer to NULL after you delete
    it, or the object's destructor sets some kind of static flag to indicate
    it has been deleted.

    --
    Ian Collins.
     
    Ian Collins, Sep 29, 2007
    #2
    1. Advertising

  3. Mark

    Kai-Uwe Bux Guest

    Mark wrote:

    > Hi,
    >
    > I would like to check if my object has been deleted or not, but my
    > program keeps crashing. Here's the simplified code (in infinite loop)
    >
    > delete tetromino;
    > //if(tetromino==NULL)
    > tetromino = new TetrominoI;
    >
    > This continuously replaces the tetromino as expected, but if I take
    > away the comment it crashes. How can I check if my object has been
    > deleted or not?


    a) You need not. The call to delete guarantees that the object is deleted.

    b) Some people do

    delete tetromino;
    tetromino = 0;

    However, note that if there is another pointer to *tetromino, and you delete
    the pointee through that one, the test tetromino == 0 will buy you nothing
    because tetromino will not magically be nulled. This idiom is dangerous at
    best.

    c) You can find / implement a smart pointer that reverts to 0 whenever the
    pointee is delete through any of its handles.

    _However_:

    d) You should rethink your design. Your wish to check whether the pointer is
    deleted is indicative that your headed the wrong way.


    Best

    Kai-Uwe Bux
     
    Kai-Uwe Bux, Sep 29, 2007
    #3
  4. Mark

    Jim Langston Guest

    "Mark" <> wrote in message
    news:...
    > Hi,
    >
    > I would like to check if my object has been deleted or not, but my
    > program keeps crashing. Here's the simplified code (in infinite loop)
    >
    > delete tetromino;
    > //if(tetromino==NULL)
    > tetromino = new TetrominoI;
    >
    > This continuously replaces the tetromino as expected, but if I take
    > away the comment it crashes. How can I check if my object has been
    > deleted or not?


    delete does not change the pointer. Just where the pointer points. If you
    want a pointer to point to NULL after you delete it, you need to do so
    yourself.

    delete tetromino;
    tetromino = NULL;

    if ( tetromino == NULL )
    tetromino = new Tetromino;

    It doesn't make much sense in this short piece of code, but it can in a
    class heirarchy. I've sometimes used it for static variables too.

    static jTexture* = NULL;
    if ( jTexture = NULL )
    {
    // load texture
    }

    and in classes.

    Also, it is perfectly safe to delete a NULL pointer. It's a non-op, nothing
    happens. Deleting a pointer that's already been deleted however will cause
    a crash.
     
    Jim Langston, Sep 29, 2007
    #4
  5. Mark

    Mark Guest

    On Sep 29, 6:36 am, "Jim Langston" <> wrote:
    > "Mark" <> wrote in message
    >
    > news:...
    >
    > > Hi,

    >
    > > I would like to check if my object has been deleted or not, but my
    > > program keeps crashing. Here's the simplified code (in infinite loop)

    >
    > > delete tetromino;
    > > //if(tetromino==NULL)
    > > tetromino = new TetrominoI;

    >
    > > This continuously replaces the tetromino as expected, but if I take
    > > away the comment it crashes. How can I check if my object has been
    > > deleted or not?

    >
    > delete does not change the pointer. Just where the pointer points. If you
    > want a pointer to point to NULL after you delete it, you need to do so
    > yourself.
    >
    > delete tetromino;
    > tetromino = NULL;
    >
    > if ( tetromino == NULL )
    > tetromino = new Tetromino;
    >
    > It doesn't make much sense in this short piece of code, but it can in a
    > class heirarchy. I've sometimes used it for static variables too.
    >
    > static jTexture* = NULL;
    > if ( jTexture = NULL )
    > {
    > // load texture
    >
    > }
    >
    > and in classes.
    >
    > Also, it is perfectly safe to delete a NULL pointer. It's a non-op, nothing
    > happens. Deleting a pointer that's already been deleted however will cause
    > a crash.


    Well, I was actually trying to get an object to kill itself (delete
    this). Then in the main program I need to check if it's been deleted
    or not. I don't think I could do something like this=NULL could I?

    My other option is to use a global boolean (del=true) as I am now...
    but I don't like the idea.
     
    Mark, Oct 2, 2007
    #5
  6. Mark

    Bo Persson Guest

    Mark wrote:
    :: On Sep 29, 6:36 am, "Jim Langston" <>
    :: wrote:
    ::: "Mark" <> wrote in message
    :::
    ::: news:...
    :::
    :::: Hi,
    :::
    :::: I would like to check if my object has been deleted or not, but
    :::: my program keeps crashing. Here's the simplified code (in
    :::: infinite loop)
    :::
    :::: delete tetromino;
    :::: //if(tetromino==NULL)
    :::: tetromino = new TetrominoI;
    :::
    :::: This continuously replaces the tetromino as expected, but if I
    :::: take away the comment it crashes. How can I check if my object
    :::: has been deleted or not?
    :::
    ::: delete does not change the pointer. Just where the pointer
    ::: points. If you want a pointer to point to NULL after you delete
    ::: it, you need to do so yourself.
    :::
    ::: delete tetromino;
    ::: tetromino = NULL;
    :::
    ::: if ( tetromino == NULL )
    ::: tetromino = new Tetromino;
    :::
    ::: It doesn't make much sense in this short piece of code, but it
    ::: can in a class heirarchy. I've sometimes used it for static
    ::: variables too.
    :::
    ::: static jTexture* = NULL;
    ::: if ( jTexture = NULL )
    ::: {
    ::: // load texture
    :::
    ::: }
    :::
    ::: and in classes.
    :::
    ::: Also, it is perfectly safe to delete a NULL pointer. It's a
    ::: non-op, nothing happens. Deleting a pointer that's already been
    ::: deleted however will cause a crash.
    ::
    :: Well, I was actually trying to get an object to kill itself (delete
    :: this). Then in the main program I need to check if it's been
    :: deleted or not. I don't think I could do something like this=NULL
    :: could I?
    ::

    Why? Don't you trust your objects? :)

    Isn't the solution to just decide who is responsible for the
    destruction? Then let the one responsible do what should be done.


    Bo Persson
     
    Bo Persson, Oct 2, 2007
    #6
  7. Mark

    Jim Langston Guest

    "Mark" <> wrote in message
    news:...
    > On Sep 29, 6:36 am, "Jim Langston" <> wrote:
    >> "Mark" <> wrote in message
    >>
    >> news:...
    >>
    >> > Hi,

    >>
    >> > I would like to check if my object has been deleted or not, but my
    >> > program keeps crashing. Here's the simplified code (in infinite loop)

    >>
    >> > delete tetromino;
    >> > //if(tetromino==NULL)
    >> > tetromino = new TetrominoI;

    >>
    >> > This continuously replaces the tetromino as expected, but if I take
    >> > away the comment it crashes. How can I check if my object has been
    >> > deleted or not?

    >>
    >> delete does not change the pointer. Just where the pointer points. If
    >> you
    >> want a pointer to point to NULL after you delete it, you need to do so
    >> yourself.
    >>
    >> delete tetromino;
    >> tetromino = NULL;
    >>
    >> if ( tetromino == NULL )
    >> tetromino = new Tetromino;
    >>
    >> It doesn't make much sense in this short piece of code, but it can in a
    >> class heirarchy. I've sometimes used it for static variables too.
    >>
    >> static jTexture* = NULL;
    >> if ( jTexture = NULL )
    >> {
    >> // load texture
    >>
    >> }
    >>
    >> and in classes.
    >>
    >> Also, it is perfectly safe to delete a NULL pointer. It's a non-op,
    >> nothing
    >> happens. Deleting a pointer that's already been deleted however will
    >> cause
    >> a crash.

    >
    > Well, I was actually trying to get an object to kill itself (delete
    > this). Then in the main program I need to check if it's been deleted
    > or not. I don't think I could do something like this=NULL could I?
    >
    > My other option is to use a global boolean (del=true) as I am now...
    > but I don't like the idea.


    If an object does a delete this, whatever points to that object doesn't
    change. That is, the pointer still points to where it was/is in memory. I
    think if you wanted to use delete this then the method that did that should
    return the fact if it was deleted or not so whatever called it could handle
    it. Something like:

    bool Foo::Check()
    {
    if ( something_or_other )
    {
    delete this;
    return true;
    }
    else
    return false;
    }

    Then in your mainline you could check the return value to see if the object
    is still around.
     
    Jim Langston, Oct 2, 2007
    #7
  8. On Oct 3, 1:35 am, "Jim Langston" <> wrote:
    > "Mark" <> wrote in message
    >
    > news:...


    [snip]

    > If an object does a delete this, whatever points to that object doesn't
    > change. That is, the pointer still points to where it was/is in memory. I
    > think if you wanted to use delete this then the method that did that should
    > return the fact if it was deleted or not so whatever called it could handle
    > it. Something like:
    >
    > bool Foo::Check()
    > {
    > if ( something_or_other )
    > {
    > delete this;
    > return true;
    > }
    > else
    > return false;
    >
    > }
    >
    > Then in your mainline you could check the return value to see if the object
    > is still around.


    There is no need to do that. An object can be made to manage its own
    resources
    via its destructor.

    This is a well known technique known as:

    RAII (Resource Acquisition Is Initialization)

    ....which even the Standard C++ library make good use of.

    --
    Chris Val
     
    Chris ( Val ), Oct 2, 2007
    #8
  9. Mark

    Mark Guest

    On Oct 2, 9:15 am, "Chris ( Val )" <> wrote:
    > On Oct 3, 1:35 am, "Jim Langston" <> wrote:
    >
    > > "Mark" <> wrote in message

    >
    > >news:...

    >
    > [snip]
    >
    >
    >
    > > If an object does a delete this, whatever points to that object doesn't
    > > change. That is, the pointer still points to where it was/is in memory. I
    > > think if you wanted to use delete this then the method that did that should
    > > return the fact if it was deleted or not so whatever called it could handle
    > > it. Something like:

    >
    > > bool Foo::Check()
    > > {
    > > if ( something_or_other )
    > > {
    > > delete this;
    > > return true;
    > > }
    > > else
    > > return false;

    >
    > > }

    >
    > > Then in your mainline you could check the return value to see if the object
    > > is still around.

    >
    > There is no need to do that. An object can be made to manage its own
    > resources
    > via its destructor.
    >
    > This is a well known technique known as:
    >
    > RAII (Resource Acquisition Is Initialization)
    >
    > ...which even the Standard C++ library make good use of.
    >
    > --
    > Chris Val


    Judging from the wikipedia article I just found, RAII is mainly used
    for when an object goes out of scope. My object is global, and it
    needs to be deleted before the program exits. I assume you mean that
    I should do my handling inside the destructor then, but that doesn't
    seem quite logical. When the object dies (tetris piece) it's supposed
    to create a new one. I don't think objects should be creating
    themselves. Anyway, the return true/false thing seems most
    appropriate.

    Thanks,
    Mark
     
    Mark, Oct 2, 2007
    #9
  10. Mark

    Mark Guest

    On Oct 2, 8:35 am, "Jim Langston" <> wrote:
    > "Mark" <> wrote in message
    >
    > news:...
    >
    >
    >
    > > On Sep 29, 6:36 am, "Jim Langston" <> wrote:
    > >> "Mark" <> wrote in message

    >
    > >>news:...

    >
    > >> > Hi,

    >
    > >> > I would like to check if my object has been deleted or not, but my
    > >> > program keeps crashing. Here's the simplified code (in infinite loop)

    >
    > >> > delete tetromino;
    > >> > //if(tetromino==NULL)
    > >> > tetromino = new TetrominoI;

    >
    > >> > This continuously replaces the tetromino as expected, but if I take
    > >> > away the comment it crashes. How can I check if my object has been
    > >> > deleted or not?

    >
    > >> delete does not change the pointer. Just where the pointer points. If
    > >> you
    > >> want a pointer to point to NULL after you delete it, you need to do so
    > >> yourself.

    >
    > >> delete tetromino;
    > >> tetromino = NULL;

    >
    > >> if ( tetromino == NULL )
    > >> tetromino = new Tetromino;

    >
    > >> It doesn't make much sense in this short piece of code, but it can in a
    > >> class heirarchy. I've sometimes used it for static variables too.

    >
    > >> static jTexture* = NULL;
    > >> if ( jTexture = NULL )
    > >> {
    > >> // load texture

    >
    > >> }

    >
    > >> and in classes.

    >
    > >> Also, it is perfectly safe to delete a NULL pointer. It's a non-op,
    > >> nothing
    > >> happens. Deleting a pointer that's already been deleted however will
    > >> cause
    > >> a crash.

    >
    > > Well, I was actually trying to get an object to kill itself (delete
    > > this). Then in the main program I need to check if it's been deleted
    > > or not. I don't think I could do something like this=NULL could I?

    >
    > > My other option is to use a global boolean (del=true) as I am now...
    > > but I don't like the idea.

    >
    > If an object does a delete this, whatever points to that object doesn't
    > change. That is, the pointer still points to where it was/is in memory. I
    > think if you wanted to use delete this then the method that did that should
    > return the fact if it was deleted or not so whatever called it could handle
    > it. Something like:
    >
    > bool Foo::Check()
    > {
    > if ( something_or_other )
    > {
    > delete this;
    > return true;
    > }
    > else
    > return false;
    >
    > }
    >
    > Then in your mainline you could check the return value to see if the object
    > is still around.


    Thanks for the suggestion! I guess I should have thought of that
    myself.

    Mark
     
    Mark, Oct 2, 2007
    #10
  11. Mark

    Jim Langston Guest

    "Chris ( Val )" <> wrote in message
    news:...
    > On Oct 3, 1:35 am, "Jim Langston" <> wrote:
    >> "Mark" <> wrote in message
    >>
    >> news:...

    >
    > [snip]
    >
    >> If an object does a delete this, whatever points to that object doesn't
    >> change. That is, the pointer still points to where it was/is in memory.
    >> I
    >> think if you wanted to use delete this then the method that did that
    >> should
    >> return the fact if it was deleted or not so whatever called it could
    >> handle
    >> it. Something like:
    >>
    >> bool Foo::Check()
    >> {
    >> if ( something_or_other )
    >> {
    >> delete this;
    >> return true;
    >> }
    >> else
    >> return false;
    >>
    >> }
    >>
    >> Then in your mainline you could check the return value to see if the
    >> object
    >> is still around.

    >
    > There is no need to do that. An object can be made to manage its own
    > resources
    > via its destructor.
    >
    > This is a well known technique known as:
    >
    > RAII (Resource Acquisition Is Initialization)
    >
    > ...which even the Standard C++ library make good use of.


    Yes, but I'm pretty sure that Mark is talking about delete this before the
    object goes out of scope and not in the destructor. Consider.

    Foo Bar();
    Bar.MaybeDeleteMe();

    Now consider that DeleteMe does a delete this. Or not (for whatever
    reason). Mainline has no clue if Bar is still good or not. If Bar's
    instance was, in fact, deleted any attempt to use Bar's variables should
    provoke undefined behavior. Even if Bar was a pointer.

    Foo* Bar = new Foo();
    Bar->MaybeDeleteMe();

    If MaybeDeleteMe does a delete this or not, Bar will still point to some
    memory location which will now be invalid. Again, any attempt to
    dereference Bar will cause undefined behavior. Which is where the use of
    the bool can come in.

    Foo* Bar = new Foo();
    if ( Bar->MaybeDeleteMe() )
    Bar =NULL;

    Now we would still have to check if Bar is a null pointer or not, but we
    know if the instance is good or not.
     
    Jim Langston, Oct 3, 2007
    #11
  12. Mark

    Mark Guest

    On Oct 2, 6:07 pm, "Jim Langston" <> wrote:
    > "Chris ( Val )" <> wrote in messagenews:...
    >
    >
    >
    > > On Oct 3, 1:35 am, "Jim Langston" <> wrote:
    > >> "Mark" <> wrote in message

    >
    > >>news:...

    >
    > > [snip]

    >
    > >> If an object does a delete this, whatever points to that object doesn't
    > >> change. That is, the pointer still points to where it was/is in memory.
    > >> I
    > >> think if you wanted to use delete this then the method that did that
    > >> should
    > >> return the fact if it was deleted or not so whatever called it could
    > >> handle
    > >> it. Something like:

    >
    > >> bool Foo::Check()
    > >> {
    > >> if ( something_or_other )
    > >> {
    > >> delete this;
    > >> return true;
    > >> }
    > >> else
    > >> return false;

    >
    > >> }

    >
    > >> Then in your mainline you could check the return value to see if the
    > >> object
    > >> is still around.

    >
    > > There is no need to do that. An object can be made to manage its own
    > > resources
    > > via its destructor.

    >
    > > This is a well known technique known as:

    >
    > > RAII (Resource Acquisition Is Initialization)

    >
    > > ...which even the Standard C++ library make good use of.

    >
    > Yes, but I'm pretty sure that Mark is talking about delete this before the
    > object goes out of scope and not in the destructor. Consider.
    >
    > Foo Bar();
    > Bar.MaybeDeleteMe();
    >
    > Now consider that DeleteMe does a delete this. Or not (for whatever
    > reason). Mainline has no clue if Bar is still good or not. If Bar's
    > instance was, in fact, deleted any attempt to use Bar's variables should
    > provoke undefined behavior. Even if Bar was a pointer.
    >
    > Foo* Bar = new Foo();
    > Bar->MaybeDeleteMe();
    >
    > If MaybeDeleteMe does a delete this or not, Bar will still point to some
    > memory location which will now be invalid. Again, any attempt to
    > dereference Bar will cause undefined behavior. Which is where the use of
    > the bool can come in.
    >
    > Foo* Bar = new Foo();
    > if ( Bar->MaybeDeleteMe() )
    > Bar =NULL;
    >
    > Now we would still have to check if Bar is a null pointer or not, but we
    > know if the instance is good or not.


    That's precisely what I'm trying to do, except that I can put all the
    "if deleted" code in place of Bar=NULL since I don't really need to
    check it anywhere else.
     
    Mark, Oct 3, 2007
    #12
  13. Mark

    James Kanze Guest

    On Oct 2, 10:51 pm, Mark <> wrote:

    > Judging from the wikipedia article I just found, RAII is
    > mainly used for when an object goes out of scope.


    RAII is, in fact, a means of causing arbitrary code to be
    executed when leaving a given scope. It really only makes sense
    for objects which are normally (or only) created as local
    objectgs.

    > My object is global, and it needs to be deleted before the
    > program exits. I assume you mean that I should do my handling
    > inside the destructor then, but that doesn't seem quite
    > logical. When the object dies (tetris piece) it's supposed to
    > create a new one.


    This is a somewhat different case. A Tetris piece is an entity
    object which managed by the game; it may have some behavior
    itself, but normally, it will be "owned" by the game: the game
    will decide when to create it, and the game will decide when it
    disappears (which corresponds to delete).

    > I don't think objects should be creating themselves. Anyway,
    > the return true/false thing seems most appropriate.


    I'm not sure. Depending on the details of the design, the fact
    that a Tetris piece is no longer visible may be an event for the
    Tetris piece, in which case delete this is appropriate, or it
    may be handled at a higher level. But in both cases, it is the
    higher level which makes the decision. And since it knows where
    the pointers are, it can handle them appropriately.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Oct 3, 2007
    #13
  14. Mark

    James Kanze Guest

    Jim Langston wrote:

    [...]
    > Yes, but I'm pretty sure that Mark is talking about delete this before the
    > object goes out of scope and not in the destructor. Consider.


    > Foo Bar();
    > Bar.MaybeDeleteMe();


    > Now consider that DeleteMe does a delete this. Or not (for whatever
    > reason). Mainline has no clue if Bar is still good or not. If Bar's
    > instance was, in fact, deleted any attempt to use Bar's variables should
    > provoke undefined behavior. Even if Bar was a pointer.


    > Foo* Bar = new Foo();
    > Bar->MaybeDeleteMe();


    > If MaybeDeleteMe does a delete this or not, Bar will still point to some
    > memory location which will now be invalid. Again, any attempt to
    > dereference Bar will cause undefined behavior. Which is where the use of
    > the bool can come in.


    > Foo* Bar = new Foo();
    > if ( Bar->MaybeDeleteMe() )
    > Bar =NULL;


    > Now we would still have to check if Bar is a null pointer or not, but we
    > know if the instance is good or not.


    Can you think of any concrete case where this would be
    appropriate? I can't.

    In most applications, most objects tend to be either value
    objects or entity objects. Value objects are normally copied,
    and are not very often allocated dynamically. Entity objects
    often manage their own lifetime, but entities interested in the
    entity object are registered as observers with it, will be
    notified by the object when it is destructed, and will take the
    appropriate actions.

    The other more or less frequent case involves "entity" objects
    which really do belong to other objects, and are more or less
    managed by it. Such objects do not normally appear at the
    interface of the managing object, however, or if so, only
    fleetingly---other entities should not keep pointers to them.
    Since the managing object knows what it is doing (hopefully), it
    can take appropriate action.

    Tetris pieces were mentionned. One possible design would have
    each row displayed at the bottom contain an array of pointers to
    the pieces it contains---an array with a fixed dimension, one
    entry for each square. The piece is notified when it reaches
    the static display at the bottom, and sets a counter to the
    number of squares it occupies. Each time a row is removed, a
    function for the piece is called, once for each square occupied,
    and this function decrements the counter, and does a delete this
    if the count reaches 0. There is no need to set any pointer to
    null, of course, because once the counter is set, the count
    corresponds to the number of pointers to the object, and when it
    reaches 0, no more pointers are left.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Oct 3, 2007
    #14
  15. On Oct 3, 11:07 am, "Jim Langston" <> wrote:
    > "Chris ( Val )" <> wrote in messagenews:...
    >
    >
    >
    >
    >
    > > On Oct 3, 1:35 am, "Jim Langston" <> wrote:
    > >> "Mark" <> wrote in message

    >
    > >>news:...

    >
    > > [snip]

    >
    > >>Ifanobjectdoes a delete this, whatever points to thatobjectdoesn't
    > >> change. That is, the pointer still points to where it was/is in memory.
    > >> I
    > >> thinkifyou wanted to use delete this then the method that did that
    > >> should
    > >> return the factifit wasdeletedor not so whatever called it could
    > >> handle
    > >> it. Something like:

    >
    > >> bool Foo::Check()
    > >> {
    > >> if( something_or_other )
    > >> {
    > >> delete this;
    > >> return true;
    > >> }
    > >> else
    > >> return false;

    >
    > >> }

    >
    > >> Then in your mainline you couldcheckthe return value to seeifthe
    > >>object
    > >> is still around.

    >
    > > There is no need to do that. Anobjectcan be made to manage its own
    > > resources
    > > via its destructor.

    >
    > > This is a well known technique known as:

    >
    > > RAII (Resource Acquisition Is Initialization)

    >
    > > ...which even the Standard C++ library make good use of.

    >
    > Yes, but I'm pretty sure that Mark is talking about delete this before theobjectgoes out of scope and not in the destructor. Consider.


    [snip]

    Thats fine.

    I wasn't entriely sure of the OP's design and or requirements.

    I mentioned it because there are times when an object needs to
    manage its own resources, and this was one good way of doing it.

    Using a template, the RAII idiom, and a little thought in design,
    you could implement your own version of an "auto pointer", etc...

    --
    Chris Val
     
    Chris ( Val ), Oct 3, 2007
    #15
  16. Mark

    Jim Langston Guest

    "Mark" <> wrote in message
    news:...
    > On Oct 2, 9:15 am, "Chris ( Val )" <> wrote:
    >> On Oct 3, 1:35 am, "Jim Langston" <> wrote:
    >>
    >> > "Mark" <> wrote in message

    >>
    >> >news:...

    >>
    >> [snip]
    >>
    >>
    >>
    >> > If an object does a delete this, whatever points to that object doesn't
    >> > change. That is, the pointer still points to where it was/is in
    >> > memory. I
    >> > think if you wanted to use delete this then the method that did that
    >> > should
    >> > return the fact if it was deleted or not so whatever called it could
    >> > handle
    >> > it. Something like:

    >>
    >> > bool Foo::Check()
    >> > {
    >> > if ( something_or_other )
    >> > {
    >> > delete this;
    >> > return true;
    >> > }
    >> > else
    >> > return false;

    >>
    >> > }

    >>
    >> > Then in your mainline you could check the return value to see if the
    >> > object
    >> > is still around.

    >>
    >> There is no need to do that. An object can be made to manage its own
    >> resources
    >> via its destructor.
    >>
    >> This is a well known technique known as:
    >>
    >> RAII (Resource Acquisition Is Initialization)
    >>
    >> ...which even the Standard C++ library make good use of.
    >>
    >> --
    >> Chris Val

    >
    > Judging from the wikipedia article I just found, RAII is mainly used
    > for when an object goes out of scope. My object is global, and it
    > needs to be deleted before the program exits. I assume you mean that
    > I should do my handling inside the destructor then, but that doesn't
    > seem quite logical. When the object dies (tetris piece) it's supposed
    > to create a new one. I don't think objects should be creating
    > themselves. Anyway, the return true/false thing seems most
    > appropriate.


    I do it a bit differently in my code. I have a vector for beams that can go
    out of range and need to be deleted. I handle it in the class and in
    mainline:

    // Update ALL the -On-The-Fly- or Fired 'Beams' to NEW positions.
    for ( BeamEffectsType::iterator it = Client.BeamEffects.begin(); it !=
    Client.BeamEffects.end(); )
    {
    if ( !(*it).second->Update() )
    {
    delete (*it).second;
    it = Client.BeamEffects.erase(it);
    }
    else
    ++it;
    }

    I do not have Update do a delete this, but isntead return a boolean stating
    if the beam should be deleted or not. I could, if I wished, wrap this code
    in a class that contains the vector of beams if I wished. I just haven't
    chosen to do that (yet).
     
    Jim Langston, Oct 3, 2007
    #16
  17. Mark

    Jim Langston Guest

    "James Kanze" <> wrote in message
    news:...
    Jim Langston wrote:

    [...]
    > Yes, but I'm pretty sure that Mark is talking about delete this before the
    > object goes out of scope and not in the destructor. Consider.


    > Foo Bar();
    > Bar.MaybeDeleteMe();


    > Now consider that DeleteMe does a delete this. Or not (for whatever
    > reason). Mainline has no clue if Bar is still good or not. If Bar's
    > instance was, in fact, deleted any attempt to use Bar's variables should
    > provoke undefined behavior. Even if Bar was a pointer.


    > Foo* Bar = new Foo();
    > Bar->MaybeDeleteMe();


    > If MaybeDeleteMe does a delete this or not, Bar will still point to some
    > memory location which will now be invalid. Again, any attempt to
    > dereference Bar will cause undefined behavior. Which is where the use of
    > the bool can come in.


    > Foo* Bar = new Foo();
    > if ( Bar->MaybeDeleteMe() )
    > Bar =NULL;


    > Now we would still have to check if Bar is a null pointer or not, but we
    > know if the instance is good or not.


    Can you think of any concrete case where this would be
    appropriate? I can't.

    In most applications, most objects tend to be either value
    objects or entity objects. Value objects are normally copied,
    and are not very often allocated dynamically. Entity objects
    often manage their own lifetime, but entities interested in the
    entity object are registered as observers with it, will be
    notified by the object when it is destructed, and will take the
    appropriate actions.

    The other more or less frequent case involves "entity" objects
    which really do belong to other objects, and are more or less
    managed by it. Such objects do not normally appear at the
    interface of the managing object, however, or if so, only
    fleetingly---other entities should not keep pointers to them.
    Since the managing object knows what it is doing (hopefully), it
    can take appropriate action.

    Tetris pieces were mentionned. One possible design would have
    each row displayed at the bottom contain an array of pointers to
    the pieces it contains---an array with a fixed dimension, one
    entry for each square. The piece is notified when it reaches
    the static display at the bottom, and sets a counter to the
    number of squares it occupies. Each time a row is removed, a
    function for the piece is called, once for each square occupied,
    and this function decrements the counter, and does a delete this
    if the count reaches 0. There is no need to set any pointer to
    null, of course, because once the counter is set, the count
    corresponds to the number of pointers to the object, and when it
    reaches 0, no more pointers are left.

    ===========

    I concur. I do not think it would be proper for an object to delete itself
    without going out of scope. An object indicating if it should be deleted or
    not, however, is more appropriate.
     
    Jim Langston, Oct 3, 2007
    #17
  18. Mark

    Colonel Guest

    After being deleted, the vlaue of the pointer tetromino should remain the
    same, however, the memory that the pointer point to has been freed.
    "Mark" <>
    ??????:...
    > Hi,
    >
    > I would like to check if my object has been deleted or not, but my
    > program keeps crashing. Here's the simplified code (in infinite loop)
    >
    > delete tetromino;
    > //if(tetromino==NULL)
    > tetromino = new TetrominoI;
    >
    > This continuously replaces the tetromino as expected, but if I take
    > away the comment it crashes. How can I check if my object has been
    > deleted or not?
    >
    > Thanks
    >
     
    Colonel, Oct 4, 2007
    #18
  19. Mark

    Mark Guest

    On Oct 3, 6:10 am, James Kanze <> wrote:
    > Jim Langston wrote:
    >
    > [...]
    >
    >
    >
    > > Yes, but I'm pretty sure that Mark is talking about delete this before the
    > > object goes out of scope and not in the destructor. Consider.
    > > Foo Bar();
    > > Bar.MaybeDeleteMe();
    > > Now consider that DeleteMe does a delete this. Or not (for whatever
    > > reason). Mainline has no clue if Bar is still good or not. If Bar's
    > > instance was, in fact, deleted any attempt to use Bar's variables should
    > > provoke undefined behavior. Even if Bar was a pointer.
    > > Foo* Bar = new Foo();
    > > Bar->MaybeDeleteMe();
    > > If MaybeDeleteMe does a delete this or not, Bar will still point to some
    > > memory location which will now be invalid. Again, any attempt to
    > > dereference Bar will cause undefined behavior. Which is where the use of
    > > the bool can come in.
    > > Foo* Bar = new Foo();
    > > if ( Bar->MaybeDeleteMe() )
    > > Bar =NULL;
    > > Now we would still have to check if Bar is a null pointer or not, but we
    > > know if the instance is good or not.

    >
    > Can you think of any concrete case where this would be
    > appropriate? I can't.
    >
    > In most applications, most objects tend to be either value
    > objects or entity objects. Value objects are normally copied,
    > and are not very often allocated dynamically. Entity objects
    > often manage their own lifetime, but entities interested in the
    > entity object are registered as observers with it, will be
    > notified by the object when it is destructed, and will take the
    > appropriate actions.
    >
    > The other more or less frequent case involves "entity" objects
    > which really do belong to other objects, and are more or less
    > managed by it. Such objects do not normally appear at the
    > interface of the managing object, however, or if so, only
    > fleetingly---other entities should not keep pointers to them.
    > Since the managing object knows what it is doing (hopefully), it
    > can take appropriate action.
    >
    > Tetris pieces were mentionned. One possible design would have
    > each row displayed at the bottom contain an array of pointers to
    > the pieces it contains---an array with a fixed dimension, one
    > entry for each square. The piece is notified when it reaches
    > the static display at the bottom, and sets a counter to the
    > number of squares it occupies. Each time a row is removed, a
    > function for the piece is called, once for each square occupied,
    > and this function decrements the counter, and does a delete this
    > if the count reaches 0. There is no need to set any pointer to
    > null, of course, because once the counter is set, the count
    > corresponds to the number of pointers to the object, and when it
    > reaches 0, no more pointers are left.
    >
    > --
    > James Kanze (GABI Software) email:
    > Conseils en informatique orientée objet/
    > Beratung in objektorientierter Datenverarbeitung
    > 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


    My design is a little different. When the tetris pieces reach the
    bottom of the screen (land on another piece) they are deleted, and the
    corresponding blocks that it occupies are entered into a 10x20 array.

    The game loop creates a tetris piece at the start of the game, and
    calls the tetris piece's move/drop function every iteration. When the
    piece detects that it's hit the bottom, it deletes itself (and inserts
    itself into the array). The main game loop needs to be notified so
    that it can create another piece at the top. My code is actually more
    like

    mainloop {
    tetrispiece->idle();
    if(tetromino deleted itself) { // <--- this is the part i was asking
    about (using a boolean right now since there's only one piece... but
    might convert to if(tetromino->idle()) {}
    create new tetris piece
    do a bunch of other stuff
    }
    }
     
    Mark, Oct 6, 2007
    #19
  20. Mark

    James Kanze Guest

    On Oct 6, 11:15 pm, Mark <> wrote:
    > On Oct 3, 6:10 am, James Kanze <> wrote:


    [...]
    > My design is a little different. When the tetris pieces reach the
    > bottom of the screen (land on another piece) they are deleted, and the
    > corresponding blocks that it occupies are entered into a 10x20 array.


    That's another alternative. I was just trying to imagine a
    reasonable design which used delete this.

    > The game loop creates a tetris piece at the start of the game, and
    > calls the tetris piece's move/drop function every iteration. When the
    > piece detects that it's hit the bottom, it deletes itself (and inserts
    > itself into the array). The main game loop needs to be notified so
    > that it can create another piece at the top.


    That's sort of organization is typically what I'd use for most
    entity objects, but I'm not sure that it's appropriate here.
    I'm not even sure that it should be the piece itself which
    detects hitting the bottom---off hand, it sounds as if the piece
    knows too much about the game. I think I'd have a GameStrategy
    object, which detected things like hitting the bottom (using a
    function on the piece to obtain information concerning the
    squares it occupies), and creating a new one.

    > My code is actually more
    > like


    > mainloop {
    > tetrispiece->idle();
    > if(tetromino deleted itself) { // <--- this is the part i was asking
    > about (using a boolean right now since there's only one piece... but
    > might convert to if(tetromino->idle()) {}
    > create new tetris piece
    > do a bunch of other stuff
    > }
    > }


    One obvious solution would be to use the observer pattern.
    Regardless of who detects the event, it is an event which must
    be notified to several actors: the piece (so it can place itself
    in the table, the game strategy, so it can generate another
    piece, the table, so that it check if any lines are filled...).

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Oct 7, 2007
    #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. Robert Bauck Hamar
    Replies:
    1
    Views:
    322
    flekso
    Jul 2, 2003
  2. Ron Natalie
    Replies:
    25
    Views:
    655
    flekso
    Jul 8, 2003
  3. opistobranchia
    Replies:
    1
    Views:
    334
    Larry I Smith
    Aug 14, 2005
  4. Replies:
    10
    Views:
    777
    Rolf Magnus
    Apr 28, 2006
  5. Chumley the Walrus
    Replies:
    2
    Views:
    256
    Tom Gosselin
    Aug 10, 2004
Loading...

Share This Page