How to avoid game objects accidentally deleting themselves in C++

Question

Let's say my game has a monster that can kamikaze explode on the player. Let's pick a name for this monster at random: a Creeper. So, the Creeper class has a method that looks something like this:

void Creeper::kamikaze() {
    EventSystem::postEvent(ENTITY_DEATH, this);

    Explosion* e = new Explosion;
    e->setLocation(this->location());
    this->world->addEntity(e);
}

The events are not queued, they get dispatched immediately. This causes the Creeper object to get deleted somewhere inside the call to postEvent. Something like this:

void World::handleEvent(int type, void* context) {
    if(type == ENTITY_DEATH){
        Entity* ent = dynamic_cast<Entity*>(context);
        removeEntity(ent);
        delete ent;
    }
}

Because the Creeper object gets deleted while the kamikaze method is still running, it will crash when it tries to access this->location().

One solution is to queue the events into a buffer and dispatch them later. Is that the common solution in C++ games? It feels like a bit of a hack, but that might just be because of my experience with other languages with different memory management practices.

In C++, is there a better general solution to this problem where an object accidentally deletes itself from inside one of its methods?

Answer 1

Don't delete this

Even implicitly.

- Ever -

Deleting an object while one of its member functions is still on the stack is begging for trouble. Any code architecture which results in that happening ("accidentally" or not) is objectively bad, is dangerous, and should be refactored immediately. In this case, if your monster is going to be allowed to call 'World::handleEvent', do not, under any circumstances, delete the monster inside that function!

(In this specific situation, my usual approach is to have the monster set a 'dead' flag on itself, and have the World object -- or something like it -- test for that 'dead' flag once per frame, removing those objects from its list of objects in the world, and either deleting it or returning it to a monster pool or whatever is appropriate. At this time, the world also sends out notifications about the deletion, so other objects in the world know that the monster has stopped existing, and can drop any pointers to it that they might be holding. The world does this at a safe time, when it knows that no objects are currently processing, so you don't have to worry about the stack unwinding to a point where the 'this' pointer points at freed memory.)

Answer 2

Instead of queuing events in a buffer, queue up deletions in a buffer. Delayed-deletion has the potential to massively simplify the logic; you can actually free up memory at the end or beginning of a frame when you know nothing interesting is happening to your objects, and delete from absolutely anywhere.

Answer 3

Instead of letting the world to handle the deletion you could let another class's instance to serve as a bucket to store all deleted entities. This particular instance should listen to ENTITY_DEATH events and handle them such that it queues them up. The World can then iterate over these instances and perform post-death operations after the frame has been rendered and 'clear' this bucket, which in turn would perform the actual deletion of entities instances.

An example of such a class would be like this: http://ideone.com/7Upza

Answer 4

I would suggest implementing a factory that's used for all game object allocations in the game. So instead of calling new yourself, you would tell the factory to create something for you.

For example

Object* o = gFactory->Create("Explosion");

Whenever you want to delete an object, the factory pushes the object in a buffer that is cleared the next frame. Delayed destruction is very important in most scenarios.

Also consider sending all messages with a delay of one frame. There is only a couple of exceptions where you need to send immediately, that vast majority of cases however just

Answer 5

You can implement managed-memory in C++ yourself, so that when ENTITY_DEATH is called, all that happens is the number of its references is reduced by one.

Later as @John suggested at the begging of every frame you can check which entities are useless (those with zero references) and delete them. For example you can use boost::shared_ptr<T> (documented here) or if you are using C++11(VC2010) std::tr1::shared_ptr<T>

Answer 6

Use pooling and don't actually delete objects. Instead, change the data structure they are registered to. For example for rendering objects there is a scene object and all the entities somehow registered to it for rendering, collision detection etc. Instead of deleting the object, detach it from the scene and insert into a dead objects pool. This method will not only prevent memory problems (such as an object deleting itself) but also may speed up your game if you use the pool correctly.

Answer 7

What we did in a game was use placement new

SomeEvent* obj = new(eventPool.alloc()) new SomeEvent();

the eventPool was just a big array of memory which was carved up, and the pointer to each segment was stored. So alloc() would return the address of a free block of memory. In our eventPool the memory was treated as a stack, so after all the events had been sent we'd just reset the stack pointer back to the start of the array.

Because of the way our event system worked we didn't need to call the destructors on the evetns. So the pool would simply register the block of memory as free, and would allocate it.

This gave us a huge speed up.

Also ... We actually used memory pools for all dynamically allocated objected in development, as it was a great way of finding memory leaks, if there was any objects left in the pools when the game exited (normally) then it was likely there was a mem leak.