I would recommend using a 'delete me' flag of some sort (or having the 'update' function return a Boolean value indicating whether the entity is still alive). I won't go into the details here, but having objects delete themselves can be problematic (for a few reasons).

Also, if this is C++ and you're using an RAII container such as shared_ptr, you don't actually need to delete the entity yourself; instead, just remove it from the container in which it resides, and (assuming that was the only remaining 'strong' reference to the entity) it will be destroyed automatically.

Quote:Although I don't have a lot of experience concerning this, I am using it at at this time and it is working perfectly!

In the constructor of a bullet for example, I add it to a global list of objects.

One the lifespan of the bullet is reached, or the bullet goes outside the screen
I simply delete it and remove it from the game object list, all from inside the class.

I'm going to make a guess here that you're using C++, and that there's a delete this involved somewhere. If so, the approach you're taking here is generally not recommended.

There are no hard and fast rules, and delete this can work in some cases, but here are some of the potential problems with the approach you're using:

1. Depending on where the deletion occurs, it may make it impossible (or at least dangerous) for objects of the type in question to be created on the stack. This is somewhat counter to the design principles of OOP and flexible software design. (In other words, ideally an object should not have to know whether it was created on the stack or on the heap/free-store. You may think you'll only ever need to create objects of type X on one or the other, but you also may end up being wrong.)

2. In a similar vein, it's usually not a good idea for objects to know that they reside in a container, or in what container they reside. (Again, this imposes unnecessary constraints on the function and behavior of the class, and limits flexibility and extensibility.)

3. I won't repeat all of the arguments for and against globals, but for a game of any complexity, a global object container may not be the best choice (just search the forum archives for 'global variables' for more information on the pros and cons of using global data).

4. When you use delete this, you have to be very careful about any code referencing the object that might get executed after the invocation of delete.

5. If your objects are dynamically allocated, you really should be using an RAII container such as shared_ptr anyway, which would render your delete this unnecessary. (Using delete this may also make it difficult to even store the object using a shared pointer, which is another way in which use of the delete this idiom can be limiting.)

[16.15] Is it legal (and moral) for a member function to say delete this?

COM objects use delete this. COM objects are reference counted (via the use of methods AddRef() and Release()). Each time you call Release(), it decrements the reference count. when it reaches 0, inside the Release() implementation there is a delete this. It's safe because you can never create your own instance of a com object, you have to request the COM runtime to do it for you, so it ensures that it can allocate it correctly.


The main thing to watch out for is that you can't use delete this if the object was allocated on the stack. You can prevent this happening in the first place by making the destructor private. If the destructor is private the compiler won't even let you declare one on the stack in the first place.

But still, 9 times out of 10, if you find yourself needing 'delete this' you're probably doing something wrong.