When the camera needs to follow the entity, it checks if the entity pointer is NULL before proceeding. Well, the pointer is not NULL, |
Pointers don't become NULL when the object they point to is destroyed. That doesn't even happen for the pointer you call delete on, much less for some other pointer floating around in memory somewhere.
and it is not a bad pointer either because I can access it's data without a problem. It just has a bunch of uninitialized data in it. |
That doesn't say much. Dereferencing an invalid pointer doesn't always result in a crash. It'll only happen if the memory page the object was located in was already given back to the OS by the application. However, that won't happen if there are still other objects in that page, if the memory was already assigned to another object or if the application simply decides to keep the memory around for future use.
Do I need some system to tell the camera to make it's target entity (what it follows) NULL? |
Yes. Said system is called smart pointers. That brings us back to an earlier comment:
I destroy the entity by first calling delete on it, and then remove it from the std::list |
...this is trouble. If you find yourself using delete at all, it's usually an indicator that you did something seriously wrong. This system is fragile. It is very easy to forget a delete somewhere or perform it twice - and when an exception is thrown, everything will be in shambles anyway. There are some approaches to the problem:
1. use a list<shared_ptr<CEntity> >
2. use a boost::ptr_list<CEntity*> (or any other ptr_list implementation)
3. C++11 only: use a list<unique_ptr<CEntity>>
In this case it will be 1., because you need shared_ptr in order to use weak_ptr.
weak_ptrs are used when you need to "link" to an object, but you don't own it. This is true for the camera - it needs to follow an entity, but it doesn't own it - the entity manager does. The advantage of weak_ptr is that you can check whether the object it points to has already been destroyed.