"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.