delete this

[Allan Bruce]

Is it ok to delete a class from within one of is own methods? It works on
VC7 but I want to know if this is generally or portably ok.
Thanks
Allan

 

[Dave]

Is it ok to delete a class from within one of is own methods? It works on
VC7 but I want to know if this is generally or portably ok.
Thanks
Allan

Yes, but you must be careful not to access any member data or call any other
methods (since an implicit "this" pointer is passed and you just nuked
"this"). I'm sure there are other things to watch out for that others will
mention. Be careful; this is legal but tricky...

 

[Nick Hounsome]

Is it ok to delete a class from within one of is own methods? It works on
VC7 but I want to know if this is generally or portably ok.
Thanks
Allan

It is OK provided that you don't try to do anything to members after the
delete.

It is also bad design (unless the method is static).

 

[John Harrison]

Is it ok to delete a class from within one of is own methods? It works on
VC7 but I want to know if this is generally or portably ok.
Thanks
Allan

Provided you don't use the object after you have done a 'delete this' it's
OK.

john

 

[Christopher Benson-Manica]

It is also bad design (unless the method is static).

If the method is static, there is no this to delete...

 

[xerix]

Yes, but you must be careful not to access any member data or call any other
methods (since an implicit "this" pointer is passed and you just nuked
"this"). I'm sure there are other things to watch out for that others will
mention. Be careful; this is legal but tricky...

Is this valid?
Will i be set and pB be destroyed or are these variables nuked right after
delete this ?

Class A
{
private:
int i;
B* pB;

public:
A() : i(0) { pB = new B(); }

~A()
{
i = 1;
delete pB;
}

void deleteMe()
{
delete this;
}
};

 

[Dave]

Is this valid?
Will i be set and pB be destroyed or are these variables nuked right after
delete this ?

Class A
{
private:
int i;
B* pB;

public:
A() : i(0) { pB = new B(); }

~A()
{
i = 1;
delete pB;
}

void deleteMe()
{
delete this;
}
};

If your app. calls deleteMe(), the object must be on the heap, and you must
not otherwise try to deallocate the object.

void foo()
{
A *ptr = new A;
A var;

ptr->deleteMe();
delete ptr; // BANG!!! Double-dellocation; bad, bad program!

var.deleteMe(); // BANG!!! Deallocation of non-heap object; bad, bad
program!
}

 

[Allan Bruce]

It is OK provided that you don't try to do anything to members after the
delete.

It is also bad design (unless the method is static).

I use this in Win32 programming, there is one instance where I cant see
anywhere around it.
Thanks
Allan

 

[Ioannis Vranos]

Is it ok to delete a class from within one of is own methods? It works on
VC7 but I want to know if this is generally or portably ok.

No it is not. Always delete an object from the outside and place any cleanup
of resources you may use in the class at the destructor.






Ioannis Vranos

 

[Julie]

It is OK provided that you don't try to do anything to members after the
delete.

It is also bad design (unless the method is static).

Could you provide more details on why this is a bad design?

I'd consider this more likely to be a design that requires careful scrutiny and
understanding of the behavior and consequences.

Once place that I see this construct being appropriate is in a class that
implements (static-method) creation and reference counting (presuming that
auto_ptr and related template wrappers are not appropriate).

 

[Julie]

No it is not. Always delete an object from the outside and place any cleanup
of resources you may use in the class at the destructor.

Sorry, my friend, you are mistaken.

delete this;

is perfectly acceptable within a class method, provided that the instance
(this, non-static data or virtual methods) is not subsequently referenced.

 

[Claudio Puviani]

Could you provide more details on why this is a bad design?

I'd consider this more likely to be a design that requires careful scrutiny and
understanding of the behavior and consequences.

Once place that I see this construct being appropriate is in a class that
implements (static-method) creation and reference counting (presuming that
auto_ptr and related template wrappers are not appropriate).

If I might chime in on this, it's bad design in that it reduces the cohesion of
the class by making it moonlight as its own lifetime manager. A cleaner design
is to have an external entity to manage the lifetime of the object(s). A rare
exception to this is when dealing with objects that "morph" (i.e., change type
during their lifetime), but even there, the use is questionable and can be more
cleanly implemented using the Cheshire Cat (a.k.a. letter-envelope) idiom.

Claudio Puviani

 

[Ioannis Vranos]

Sorry, my friend, you are mistaken.

delete this;

is perfectly acceptable within a class method, provided that the instance
(this, non-static data or virtual methods) is not subsequently referenced.

Yes in usual implementations you are right. But in theory since the member
function is still executed after the end of the delete this; expression,
isn't it undefined behaviour? An implementor can choose implement the
function in a way dependent to *this for example. Except of the member
function implementation, C++ code may run in a mixed environment, an example
is .NET which i have been studying lately.

So strictly speaking i believe it is undefined behaviour. Unless the
standard mentions something else... And programmmatically speaking it is
also very bad coding approach.






Ioannis Vranos

 

[Nick Hounsome]

If the method is static, there is no this to delete...

I was reading the post rather than the title.
In the post he just said "Is it ok to delete a class from within one of is
own methods? " with no
mention of this.

 

[Buster]

I was reading the post rather than the title.
In the post he just said "Is it ok to delete a class from within one of is
own methods? " with no mention of this.

Oh. Well, that makes it perfectly acceptable. (??)

 

[Allan Bruce]

If I might chime in on this, it's bad design in that it reduces the cohesion of
the class by making it moonlight as its own lifetime manager. A cleaner design
is to have an external entity to manage the lifetime of the object(s). A rare
exception to this is when dealing with objects that "morph" (i.e., change type
during their lifetime), but even there, the use is questionable and can be more
cleanly implemented using the Cheshire Cat (a.k.a. letter-envelope) idiom.

Claudio Puviani

The reason I use it is that I have a class called ChatWindow which I have
made. This creates a window and controls the message loop etc. of my win32
program. When a user clicks to close the window, I wish for the program to
still run - I have a roster window which I consider the main hub of the
program. So, I recieve a WM_CLOSE message within one of the methods of the
class which should then force the cleanup of the class etc. I currently use
"delete this" at the very end of this method and things seem to work. There
is a way I can get around this but it is quite messy in my opinion so I am
keen to keep it this way.
Allan

 

[Ahti Legonkov]

If your app. calls deleteMe(), the object must be on the heap, and you must
not otherwise try to deallocate the object.

void foo()
{
A *ptr = new A;
A var;

ptr->deleteMe();
delete ptr; // BANG!!! Double-dellocation; bad, bad program!

var.deleteMe(); // BANG!!! Deallocation of non-heap object; bad, bad
program!
}

To prevent these BANGs, make the destructor private or protected. Then
these statements would be illegal and you'd get compile time error:

A var; // destructor not accessible
delete ptr; // same here

 

[Claudio Puviani]

The reason I use it is that I have a class called ChatWindow
which I have made. This creates a window and controls the
message loop etc. of my win32 program. When a user clicks
to close the window, I wish for the program to still run - I have
a roster window which I consider the main hub of the program.
So, I recieve a WM_CLOSE message within one of the methods
of the class which should then force the cleanup of the class etc.
I currently use "delete this" at the very end of this method and
things seem to work. There is a way I can get around this but
it is quite messy in my opinion so I am keen to keep it this way.

In the long run -- and certainly on large projects -- you'll find that it's a
lot less messy to avoid giving a single class too many purposes. You might want
to look up the "Chain of Responsibility" patters that offers a clean solution
to what you're trying to do.

Claudio Puviani

 

[Mark Wright]

One joyful day (Wed, 14 Apr 2004 08:09:55 +0100 to be precise), "Nick

I was reading the post rather than the title.
In the post he just said "Is it ok to delete a class from within one of is
own methods? " with no
mention of this.

Just as an aside, is a static function a method? I thought "method" was
the general OO name given to a function which operates on an instance of
an object and which must be called from that object. That is, a function
may be called with no context but a method must always be invoked from
an instance.

I that is the case then in C++ there will always be a this pointer
available to a method. \

Mark Wright
- (e-mail address removed)

================Today's Thought====================
"In places where books are burned, one day,
people will be burned" - Heinrich Heine, Germany -
100 years later, Hitler proved him right
===================================================