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?
0
An object needs to commit suicide
Started by lride, Nov 17 2012 09:43 PM
9 replies to this topic
Sponsor:
#2 Members - Reputation: 6171
Posted 17 November 2012 - 10:02 PM
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.
#3 Members - Reputation: 625
Posted 17 November 2012 - 10:12 PM
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.
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, 17 November 2012 - 10:14 PM.
An invisible text.
#4 Marketplace Seller - Reputation: 9277
Posted 17 November 2012 - 10:31 PM
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 logically manage the lifetime of an entity? The next question is, why isn't that class managing it?
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 logically manage the lifetime of an entity? The next question is, why isn't that class managing it?
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal
#5 Members - Reputation: 6171
Posted 17 November 2012 - 10:33 PM
You should read this from the C++ FAQ lite . 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.
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.
#9 Members - Reputation: 6171
Posted 18 November 2012 - 08:41 AM
yes, but i found a better solutiom. Just keep a boolean variable "alive" and delete the dead object in the next frame
Wait, entityManager is the one that's doing the delete?
What do you mean you "found"? I gave it to you.
Edited by Álvaro, 18 November 2012 - 08:41 AM.
#10 Members - Reputation: 1673
Posted 19 November 2012 - 06:25 PM
yes, but i found a better solutiom. Just keep a boolean variable "alive" and delete the dead object in the next frame
Wait, entityManager is the one that's doing the delete?
Garbage collection - yes. This is what people were suggesting.
void hurrrrrrrr() {__asm sub [ebp+4],5;}
There are ten kinds of people in this world: those who understand binary and those who don't.
There are ten kinds of people in this world: those who understand binary and those who don't.
