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:
[email protected]
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
