What you are doing is, you have weak_ptr without shared_ptr. You make all pointers weak, allowing anyone to delete the object at any time, which automatically invalidates all weak pointers. I'm a game programmer myself, and I've used similar solution in the past, but now I would use shared_ptr/weak_ptr instead. One advantage of the shared_ptr/weak_ptr combination is that it is thread-safe. You know how important this will be for nextgen console hardware. Another advantage is that you get to choose between weak and strong pointers; it is important to be able to express ownership. In other words, shared_ptr and weak_ptr compliment each other and allow you to pick the proper type of reference for each situation. Finally, in your solution, you *assume* that the only way to destroy an object is operator delete. With shared_ptr, the destruction procedure is abstracted and hidden from client code. This is a very valuable optimization tool: as soon as profiling indicates a problem with the allocation/deallocation strategy for some shared_ptr managed object(s), you can change it without any effect on client code. For example, an object representing a puff of smoke from a bullet hitting the wall can probably be optimized by not using new/delete. If you use shared_ptr to manage such objects, changing the allocation/deallocation strategy is trivial and will not break client code. The only way to achieve the same level of flexibility with your live_ptr design is to disallow new/delete and restrict everyone to using a pair of create/destroy functions. The problem is, this is not "built-in" and by the time you figure the allocations are slow you have so many new/delete calls that it is a major hassle to do something about it. Using shared_ptr gives you this extra peace of mind knowing you're in control even if you didn't know you need it. Also note that with your live_ptr, deleting an object needs linear time to the number of live live_ptrs. With shared_ptr/weak_ptr, the time it takes to destroy the managed object is independent of the number of live weak_ptrs (though I should say you can implement live_ptr semantics with const time delete as well.) Emil