Can an Object Delete itself
Author
Hello, I would like to know whether a member function can call "delete this;" and if there any bad consequences from this, such as memory leaks etc
thanks
Yratelev
This question has already been addressed several times on Gamedev.
Yes, it can.
The downside is that you need to make sure this member function is NEVER called on objects that use stack or malloc memory, ONLY on objects created with new.
ToohrVyk
Yes, it can.
The downside is that you need to make sure this member function is NEVER called on objects that use stack or malloc memory, ONLY on objects created with new.
ToohrVyk
As far as I know, its possible to do so.
But you must be careful. It wil most certainly cause problems, when the object is created on the stack and you must be sure that nowhere in the program pointers to the object are still in use.
But you must be careful. It wil most certainly cause problems, when the object is created on the stack and you must be sure that nowhere in the program pointers to the object are still in use.
It''s okay, so long as it was allocated with new and you don''t try to access any member variables/functions afterwards.
An object can delete itself, but it is often a rule of thumb to have the scope that created an object also delete said object.
For example, if you have a class Car and it created 4 wheels, you would have Car handle the destruction of the 4 wheels, and whatever made an instance of a Car delete the Car.
Sometimes, in the example of counted reference pointer classes and the like, objects are responsible for deleting themselves. In these cases, the destructor is often declared with a private permission, so there is no confusion about who will do the deleting.
One thing to never do is have the destructor call "delete this;" It is never a good idea and if someone knows better, I would enjoy having them explain when calling delete this in the destructor is ever a good idea.
For example, if you have a class Car and it created 4 wheels, you would have Car handle the destruction of the 4 wheels, and whatever made an instance of a Car delete the Car.
Sometimes, in the example of counted reference pointer classes and the like, objects are responsible for deleting themselves. In these cases, the destructor is often declared with a private permission, so there is no confusion about who will do the deleting.
One thing to never do is have the destructor call "delete this;" It is never a good idea and if someone knows better, I would enjoy having them explain when calling delete this in the destructor is ever a good idea.
Killing yourself means suicide.
Having the object to kill itself means that object is commiting suicide.
Well... it ''solve'' the problem. But it isn''t a good solution. Try your luck on finding a solution that doesn''t commit suicide.
Having the object to kill itself means that object is commiting suicide.
Well... it ''solve'' the problem. But it isn''t a good solution. Try your luck on finding a solution that doesn''t commit suicide.
Wow, Derekwas, impressive use of associative reasoning. Suicide = bad, self deletion resembles suicide, self deletion = bad.
My answer: Self deleting requires you to be careful (objects can not be on the stack, must not access itself after deleting), but can be a useful tool in some situations. Where i use it myself is in objects that keep a reference count and automatically release their own memory when there are no references left.
Marijn
My answer: Self deleting requires you to be careful (objects can not be on the stack, must not access itself after deleting), but can be a useful tool in some situations. Where i use it myself is in objects that keep a reference count and automatically release their own memory when there are no references left.
Marijn
Have a look at COM: almost all COM objects are destroyed via delete this when the refcount reaches 0.
Typical COM-Pattern:
MfG VizOne
Typical COM-Pattern:
class XY : public IUnknown{public:unsigned long AddRef(){ return ++m_refCount;}unsigned long Release(){ if(--m_refCount == 0) { delete this; return 0; } return m_refCount;}//...}; MfG VizOne
**A problem:
Function creates object and returns it... what to do?
1°/ Create, add reference, return : the calling function will receive an already referenced object, so this sounds like a design error (it forces the user to release an object it never referenced to).
2°/ Create, add reference, release, return : this will usually destroy the object (if it has only one reference) so is not possible.
**Another problem : you can''t do something like this :
Owner.SetObject( Object::CreateObject( ) );
1°/CreateObject will return an object with (at least) one reference. It is then passed to SetObject, which DOES reference it. When Owner finally releases it, no one has a reference to the object, but it wasn''t destroyed because it has one reference left.
2°/Now suppose Owner.SetObject does NOT reference the object it receives. The above piece of code is correct. But this crashes as soon as one of the owners releases the object :
Object * obj = Object::CreateObject( );
Owner1.SetObject( obj );
Owner2.SetObject( obj );
**The (current) solution I am using:
Add a "freeze" function, that adds one reference to the object, and removes it after a little while. This allows objects to have virtually a 0 reference count. This solves both problems, and makes the design easier:
Catch( ) when you start using an object
Freeze( ) when the object is to be released, then returned
Release( ) when you don''t need the object anymore
Auto-freeze upon creation allows you to directly use any objects created with new as 0-reference objects.
ToohrVyk
Function creates object and returns it... what to do?
1°/ Create, add reference, return : the calling function will receive an already referenced object, so this sounds like a design error (it forces the user to release an object it never referenced to).
2°/ Create, add reference, release, return : this will usually destroy the object (if it has only one reference) so is not possible.
**Another problem : you can''t do something like this :
Owner.SetObject( Object::CreateObject( ) );
1°/CreateObject will return an object with (at least) one reference. It is then passed to SetObject, which DOES reference it. When Owner finally releases it, no one has a reference to the object, but it wasn''t destroyed because it has one reference left.
2°/Now suppose Owner.SetObject does NOT reference the object it receives. The above piece of code is correct. But this crashes as soon as one of the owners releases the object :
Object * obj = Object::CreateObject( );
Owner1.SetObject( obj );
Owner2.SetObject( obj );
**The (current) solution I am using:
Add a "freeze" function, that adds one reference to the object, and removes it after a little while. This allows objects to have virtually a 0 reference count. This solves both problems, and makes the design easier:
Catch( ) when you start using an object
Freeze( ) when the object is to be released, then returned
Release( ) when you don''t need the object anymore
Auto-freeze upon creation allows you to directly use any objects created with new as 0-reference objects.
ToohrVyk
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
