Sign in to follow this  
lride

An object needs to commit suicide

Recommended Posts

lride    674
I have the following code in my project

[source lang="cpp"]Entity::handleMessage(Message* msg)
{
if(msg->type==DIE)
entityManager.destroy(this->ID);
...
}[/source]
I figured this is equivalent to

[source lang="cpp"]Entity::handleMessage(Message* msg)
{
if(msg->type==DIE)
delete this;
...
}[/source]

Is this safe?

Share this post


Link to post
Share on other sites
alvaro    21263
No, it isn't. Whoever owns this object will likely try to destroy it later on, and then you'll have a double deletion. The first version isn't safe either, because almost anything you do in the "..." section will be undefined behavior. The safe thing to do would be to schedule destruction of the object for the end of the frame, or something like that. entityManager would have a container of IDs to destroy and once per frame it would go through it and destroy everything in it.

Share this post


Link to post
Share on other sites
lride    674
[quote name='Álvaro' timestamp='1353211367' post='5001930']
No, it isn't. Whoever owns this object will likely try to destroy it later on, and then you'll have a double deletion. The first version isn't safe either, because almost anything you do in the "..." section will be undefined behavior. The safe thing to do would be to schedule destruction of the object for the end of the frame, or something like that. entityManager would have a container of IDs to destroy and once per frame it would go through it and destroy everything in it.
[/quote]

I am 100% sure that this object will get deleted only once. And will it be fine if I don't try to access the object after "delete this"?
[source lang="cpp"]Entity::handleMessage(Message* msg)
{
...//do all kind of stuff beforehand
if(msg->type==DIE)
entityManager.destroy(this->ID);//(delete this;) //nothing will happen after this
}[/source] Edited by lride

Share this post


Link to post
Share on other sites
It's "fine" if the object never gets accessed again, but it's bad practice.

Ask yourself, who manages the lifetime of that entity? All variables have someone managing their lifetime, whether they be dynamically allocated or on the stack. What class should [i]logically [/i]manage the lifetime of an entity? The next question is, why isn't that class managing it?

Share this post


Link to post
Share on other sites
alvaro    21263
You should read this from the [url="http://www.parashift.com/c++-faq-lite/delete-this.html"]C++ FAQ lite[/url] . If you still think that you are safe having the suicidal objects, go ahead.

Even so, I don't like to write classes that impose unreasonable constraints on the user (objects have to be allocated using new, or through an entityManager...). I like to be able to have local variables of this type, arrays of these things and what have you.

As an alternative solution, your objects could have a callback (or a signal, which is similar) that they will use when they want to die. Whoever creates the object will also provide the mechanism to get rid of it.

Share this post


Link to post
Share on other sites
lride    674
[quote name='alnite' timestamp='1353234015' post='5002003']
Wait, [font=courier new,courier,monospace]entityManager[/font] is the one that's doing the [font=courier new,courier,monospace]delete[/font]?
[/quote]
yes, but i found a better solutiom. Just keep a boolean variable "alive" and delete the dead object in the next frame

Share this post


Link to post
Share on other sites
Khatharr    8812
[quote name='lride' timestamp='1353248390' post='5002039']
[quote name='alnite' timestamp='1353234015' post='5002003']
Wait, [font=courier new,courier,monospace]entityManager[/font] is the one that's doing the [font=courier new,courier,monospace]delete[/font]?
[/quote]
yes, but i found a better solutiom. Just keep a boolean variable "alive" and delete the dead object in the next frame
[/quote]

Garbage collection - yes. This is what people were suggesting.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this