Re: Check If Object Deleted

From:

Mark <mnbayazit@gmail.com>

Newsgroups:

comp.lang.c++

Date:

Sat, 06 Oct 2007 14:15:30 -0700

Message-ID:

<1191705330.520059.120340@g4g2000hsf.googlegroups.com>

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 =

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=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, 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
}
}