Home » Coding » c++ » Check If Object Deleted
| Check If Object Deleted [message #16462] |
Fri, 28 September 2007 20:31  |
 Mark
Messages: 9
Registered: August 2007 |
Junior Member |
|
|
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
|
|
| | |
| Re: Check If Object Deleted [message #16769 is a reply to message #16462 ] |
Mon, 01 October 2007 20:09  |
Mark
Messages: 9
Registered: August 2007 |
Junior Member |
|
|
On Sep 29, 6:36 am, "Jim Langston" <tazmas...@rocketmail.com> wrote:
> "Mark" <mnbaya...@gmail.com> wrote in message
>
> news:1191025882.089561.274810@57g2000hsv.googlegroups.com...
>
> > 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.
|
|
|
| Re: Check If Object Deleted [message #16857 is a reply to message #16769 ] |
Tue, 02 October 2007 11:28 |
Bo Persson
Messages: 59
Registered: July 2007 |
Member |
|
|
Mark wrote:
:: On Sep 29, 6:36 am, "Jim Langston" <tazmas...@rocketmail.com>
:: wrote:
::: "Mark" <mnbaya...@gmail.com> wrote in message
:::
::: news:1191025882.089561.274810@57g2000hsv.googlegroups.com...
:::
:::: 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
|
|
| |
| Re: Check If Object Deleted [message #16916 is a reply to message #16871 ] |
Tue, 02 October 2007 16:51 |
Mark
Messages: 9
Registered: August 2007 |
Junior Member |
|
|
On Oct 2, 9:15 am, "Chris ( Val )" <chris...@gmail.com> wrote:
> On Oct 3, 1:35 am, "Jim Langston" <tazmas...@rocketmail.com> wrote:
>
> > "Mark" <mnbaya...@gmail.com> wrote in message
>
> >news:1191283774.823987.251920@g4g2000hsf.googlegroups.com...
>
> [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
|
|
|
| Re: Check If Object Deleted [message #16917 is a reply to message #16769 ] |
Tue, 02 October 2007 16:52 |
Mark
Messages: 9
Registered: August 2007 |
Junior Member |
|
|
On Oct 2, 8:35 am, "Jim Langston" <tazmas...@rocketmail.com> wrote:
> "Mark" <mnbaya...@gmail.com> wrote in message
>
> news:1191283774.823987.251920@g4g2000hsf.googlegroups.com...
>
>
>
> > On Sep 29, 6:36 am, "Jim Langston" <tazmas...@rocketmail.com> wrote:
> >> "Mark" <mnbaya...@gmail.com> wrote in message
>
> >>news:1191025882.089561.274810@57g2000hsv.googlegroups.com...
>
> >> > 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
|
|
|
| Re: Check If Object Deleted [message #16944 is a reply to message #16871 ] |
Wed, 03 October 2007 01:35 |
Mark
Messages: 9
Registered: August 2007 |
Junior Member |
|
|
On Oct 2, 6:07 pm, "Jim Langston" <tazmas...@rocketmail.com> wrote:
> "Chris ( Val )" <chris...@gmail.com> wrote in messagenews:1191341754.813610.175230@r29g2000hsg.googlegroups.com...
>
>
>
> > On Oct 3, 1:35 am, "Jim Langston" <tazmas...@rocketmail.com> wrote:
> >> "Mark" <mnbaya...@gmail.com> wrote in message
>
> >>news:1191283774.823987.251920@g4g2000hsf.googlegroups.com...
>
> > [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.
|
|
|
| Re: Check If Object Deleted [message #16981 is a reply to message #16916 ] |
Wed, 03 October 2007 08:58 |
James Kanze
Messages: 598
Registered: July 2007 |
Senior Member |
|
|
On Oct 2, 10:51 pm, Mark <mnbaya...@gmail.com> 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:james.kanze@gmail.com
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
|
|
|
| Re: Check If Object Deleted [message #16983 is a reply to message #16871 ] |
Wed, 03 October 2007 09:10 |
James Kanze
Messages: 598
Registered: July 2007 |
Senior Member |
|
|
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:james.kanze@gmail.com
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
|
|
|
| Re: Check If Object Deleted [message #17025 is a reply to message #16871 ] |
Wed, 03 October 2007 13:05 |
chrisval
Messages: 47
Registered: September 2007 |
Member |
|
|
On Oct 3, 11:07 am, "Jim Langston" <tazmas...@rocketmail.com> wrote:
> "Chris ( Val )" <chris...@gmail.com> wrote in messagenews:1191341754.813610.175230@r29g2000hsg.googlegroups.com...
>
>
>
>
>
> > On Oct 3, 1:35 am, "Jim Langston" <tazmas...@rocketmail.com> wrote:
> >> "Mark" <mnbaya...@gmail.com> wrote in message
>
> >>news:1191283774.823987.251920@g4g2000hsf.googlegroups.com...
>
> > [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
|
|
| |
| Re: Check If Object Deleted [message #17368 is a reply to message #16983 ] |
Sat, 06 October 2007 17:15 |
Mark
Messages: 9
Registered: August 2007 |
Junior Member |
|
|
On Oct 3, 6:10 am, James Kanze <james.ka...@gmail.com> 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:james.ka...@gmail.com
> 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
}
}
|
|
|
| Re: Check If Object Deleted [message #17387 is a reply to message #17368 ] |
Sun, 07 October 2007 06:02 |
James Kanze
Messages: 598
Registered: July 2007 |
Senior Member |
|
|
On Oct 6, 11:15 pm, Mark <mnbaya...@gmail.com> wrote:
> On Oct 3, 6:10 am, James Kanze <james.ka...@gmail.com> 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:james.kanze@gmail.com
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
|
|
|
Goto Forum:
Current Time: Fri May 16 02:23:33 EDT 2008
Total time taken to generate the page: 0.31708 seconds |
Members
Search
Help
Register
Login
Home
