3

Having this:

class Foo
{
public:
    void destroy() { delete this; }
public:
    // Stuff here...
};

int main(int argc, char *argv[])
{
    Foo* foo = new Foo;

    // Option 1
    delete foo;

    // Option 2:
    foo->destroy();

    return 0;
}

Is Option 1 and Option 2 the same operation? Is it a 'correct' way for destroying objects? Why/Why not?

Thank you so much,

Didac Perez Parera
  • 3,734
  • 3
  • 52
  • 87
  • First, "If you have to ask if it's okay, you probably need to find a different way to do this". Secondly, "Delete this" is a very bad coding practice because it will only work if a single instance is defined on the heap; and there had better not be another delete statement, which is typically used by most developers to clean up the heap. Doing this also assumes that no maintenance programmer in the future will cure a falsely perceived memory leak by adding a delete statement.(http://stackoverflow.com/questions/3150942/c-delete-this) – SChepurin Apr 02 '14 at 12:04

4 Answers4

3

Yes, the two are equivalent in this case.

But you should definitely prefer Option 1. delete this is very easy to get wrong, violates various design principles, and in this instance is completely pointless.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
2

Option 1 is the recommended way to delete a class object.

class Foo
{
public:
    ~Foo()
    {
       //define destructor if you have any pointer in your class
    }
public:
    // Stuff here...
};


int main()
{
    Foo* foo = new Foo;

    // By deleting foo it will call its destructor 
    delete foo;
}

For Option 2

The C++ FAQ Lite has a entry specifically for this http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.15

As long as you're careful, it's OK for an object to commit suicide (delete this).

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
EmptyData
  • 2,386
  • 2
  • 26
  • 42
2

As others said, it's not common and discouraged. A usually reliable source says that you can technically do it if you strictly follow a few rules; in particular, do not access freed memory or class members after the delete: http://www.parashift.com/c++-faq/delete-this.html.

Peter - Reinstate Monica
  • 15,048
  • 4
  • 37
  • 62
  • Can you put the details of the rules that need to be followed in your answer and simply cite the link as a source? That way, if the site the link links to ever goes down, the relevant information is still part of the answer here on StackOverflow. – Eric Finn Apr 02 '14 at 11:42
  • @ Eric Finn It will likely not go down before SO does. Why duplicate? – Peter - Reinstate Monica Apr 02 '14 at 11:44
  • Because that's part of StackOverflow's [guidelines for referencing material written by others](http://stackoverflow.com/help/referencing). We like to have the content of the answer in the answer here. – Eric Finn Apr 02 '14 at 11:50
2

Such destruction schemes (a member function deleting the this pointer) are the common solution when implementing classes that allow instances only on the heap

class Foo
{
    ~Foo(); // private destructor - won't allow objects on the stack
public:
    void destroy() { delete this; }
public:
    // Stuff here...
};

In the above example, the destructor can't be called, so you can't say

delete FooInstance;

and your only option to avoid memory leaks is to have a destroy function:

FooInstance->destroy();

Apart from that I haven't found any real world cases where such a destruction function is/has to be used.

Nikos Athanasiou
  • 29,616
  • 15
  • 87
  • 153
  • @LightnessRacesinOrbit The technique or it's solution? That aside noone said it's the [best way to do create heap only classes](http://stackoverflow.com/a/3092212/2567683), I'm just presenting a case (that I come across in legacy code) where a destroy function would have meaning. If one is given a class with private destructor I'm eager to learn how would she (eventually) call it if not through a function with access to private methods. – Nikos Athanasiou Apr 02 '14 at 17:04