Should “delete this” be called from within a membe

Question

I was just reading this article and wanted SO folks advice:

Q: Should delete this; be called from within a member method?

Answer 1

Getting ready for the down votes.

Should it: No.
Can it Technically: Yes
Is it a good idea: Absolutely not.
Are there situation it is useful: Of course. If you are C++ foo is exceedingly strong. But most people are not that good. So only do this if you have a team of people working with you able to do decent code review.

Why:
There is no way for an object to know that it has been dynamically allocated (and thus needs deleting) or is a normal object (and thus must not be deleted) and thus how can it decidide weather it should be deleted. Thus if an object is deleting itself then in my opinion there is somthing terribly wrong with the design.

If you have an object that needs managing then you should write a seprate object to do the management (hence smart pointers). Let the object do what it is good at, then seporate the management of the object into another object.

Answer 2

Not without a very good reason to do so.

The problem is that when you call delete this in a member function, you're creating a nasty side effect - the caller still has a reference to your instance that is now completely invalid.

This is probably not an expected behavior, so it could easily lead to nasty bugs.

That being said, there are times when this is appropriate (I've seen some memory management schemes, with certain libraries, where you explicitly create methods in the classes that delete themselves - primarily for language interoperability). In general, I think it's bad practice, though.

Answer 3

I think there are really 2 questions here

Can delete this be validly called from a member method?

Yes. This is legal as long as you are very careful with the usage.

Should delete this be used within a member method?

In very specific cases this is necessary. Certain types of smart pointers for instance use the delete this pattern to kill the pointer. Examples: CComPtr<> style.

Other than smart pointers though, it should be avoided unless you have a very good reason for doing this. Even then, I would carefully reconsider my scenario and see if there was a way around it.

Answer 4

Yes. Like all the answers say, if you're 100% sure that the class's data will not be used after the delete this is called.

For example, in one project:

void Test()
MyClass * Someclass = new MyClass;
SomeClass->DoYourThing();
SomeClass->KillYourself();
return;

void MyClass::DoYourThing() { return; }
void MyClass::KillYourself() {delete this;}

Very simplistic explanation, the project used delete this; as part of the memory management for objects of that type; their constructor added them to a private list of classes of that type in use, and removed themselves from that list when they were destroyed and then deleted themselves (this was not in a destructor). Any objects of that class that hadn't deleted themselves when the program reached its endpoint then all had their KillYourself() equivalent called from a static member function CleanYourselves()

Answer 5

You can do it, provided its the last element in a member function, and that after return you forget that object ever existed.... but yeah, like that article asks ... Why would you want to do this ? I don't know what the standard says, but it does give me a funny feeling :P

I guess this is a bit like should you ever use a GOTO statement, and I personally use GOTO to clean up resources in C sometimes, especially under exceptional conditions.

I wonder what the shared state implications are (fuzzy statement I know):P

Answer 6

Some threading libraries use it when implementing an auto destroy on thread termination.

void Thread::threadFunc()
{
    doRun();

    if(this->destroyOnExit == true)
        delete this;
}