"delete this;" Is this safe?

[solosnake]

Whilst browsing Flipcode I noticed this code:


class CConsole: public I_TextOutput
{
public:
...
void Release() { delete this; }
...
};

The 'delete this;' caught my eye. Is such code safe?

The full article is here :
http://www.flipcode.com/articles/article_winplugins.shtml

Thanks,

solosnake

 

[Martijn Lievaart]

Whilst browsing Flipcode I noticed this code:


class CConsole: public I_TextOutput
{
public:
...
void Release() { delete this; }
...
};

The 'delete this;' caught my eye. Is such code safe?

Yes, it is. Just make sure you don't touch any member afterwards. Yhis
includes any use of a data member and calling any non static function.

Sometimes this technique is necessary. I used to use it pretty often. I
haven't used it for some time now, I like to think that my design skills
have gotten better. Still there are valid uses.

HTH,
M4

 

[Daniel T.]

Whilst browsing Flipcode I noticed this code:


class CConsole: public I_TextOutput
{
public:
...
void Release() { delete this; }
...
};

The 'delete this;' caught my eye. Is such code safe?

Can you guarantee that no CConsole object will ever be allocated on the
stack?

 

[Nick Hounsome]

Whilst browsing Flipcode I noticed this code:


class CConsole: public I_TextOutput
{
public:
...
void Release() { delete this; }
...
};

The 'delete this;' caught my eye. Is such code safe?

The full article is here :
http://www.flipcode.com/articles/article_winplugins.shtml

Thanks,

solosnake

Yes it is but I would call it poor design.
As a matter of principle it is desirable that only the class that created an
object should delete it (or should arrange for its deletion by putting it in
a handle class such as auto_ptr) - this allows scope for custom object
memory allocation without changing 'client' classes.

 

[Daniel T.]

Yes it is but I would call it poor design.
As a matter of principle it is desirable that only the class that created an
object should delete it (or should arrange for its deletion by putting it in
a handle class such as auto_ptr) - this allows scope for custom object
memory allocation without changing 'client' classes.

To put this another way, your code should make it explicit what object
is in charge of deleting what other objects. The code example muddies
the waters because it puts the 'delete' in CConsole, but CConsole isn't
really in charge of deleting itself, whatever object calling Release is
the one really in charge of the destruction...

 

[Unforgiven]

Whilst browsing Flipcode I noticed this code:


class CConsole: public I_TextOutput
{
public:
...
void Release() { delete this; }
...
};

The 'delete this;' caught my eye. Is such code safe?

Yup. The most common place you'll see this (at least, I haven't seen it
anywhere else much) is when programming with Microsoft COM. COM coclasses
use reference counting to manage their lifetime, which consists of two
functions, one called AddRef(), which increases the reference count, and
Release(), which decreases the reference count and when it reaches zero much
destroy the coclass. Implementations using C++ classes will usually
implement Release() using 'delete this;'. | As was pointed out this is only
not safe when the object is created on the stack, which is not possible with
COM objects.

 

[Gianni Mariani]

Daniel T. wrote:
....

To put this another way, your code should make it explicit what object
is in charge of deleting what other objects. The code example muddies
the waters because it puts the 'delete' in CConsole, but CConsole isn't
really in charge of deleting itself, whatever object calling Release is
the one really in charge of the destruction...

I thought that the whole purpose of reference counting was that you
removed the "explicit" nature of what deletes what.

It's much more flexible to design a system where an object is deleted
when it is no longer "referenced". Of course, you have the issue of
circular referencing but *that* is a design problem.

 

[Graham Dumpleton]

Can you guarantee that no CConsole object will ever be allocated on the
stack?

It also can't be an element in array, ie., can't have:

a = new CConsole()

and then use Release() on a member of the array. Ie.,
dangerous to say:

a[0].Release()

You also shouldn't use Release() on a CConsole instance where the
instance is a static variable, global, function or class scope. Finally,
can't use it where the CConsole was a member variable. Ie.,

class Foo
{
CConsole o;
};

Anyway, use of delete this is common with reference counting
schemes where the count is maintained with the actual object.
Use of auto_ptr is not always a replacement for reference
counting.

 

[Daniel T.]

Daniel T. wrote:
...

I thought that the whole purpose of reference counting was that you
removed the "explicit" nature of what deletes what.

It's much more flexible to design a system where an object is deleted
when it is no longer "referenced". Of course, you have the issue of
circular referencing but *that* is a design problem.

True but the code example shown wasn't a reference count, it was a
simple delete wrapped in a "release" member-function.

Even so, reference counting isn't much use IMO when a "release" function
must be explicitly called. One ends up having to rely on all possible
client classes doing the right thing. No the best example would be
something like boost::shared_ptr. Note how all the code that tracks when
an object should be deleted is burried within a single class.

 

[Graham Dumpleton]

Can you guarantee that no CConsole object will ever be allocated on the
stack?

It also can't be an element in array, ie., can't have:

a = new CConsole()

and then use Release() on a member of the array. Ie.,
dangerous to say:

a[0].Release()

Whoops, I obviously mean't:

a = new CConsole[n]

 

[Bret Pehrson]

No, it is not safe, but it is allowed.

It is used in certain situations where absolutely necessary, and the
implementor can guarantee certain conditions are met w/ the use of that
class/object, such as that the object cannot be allocated on the stack.