>>118
And yes, it does sound like a bad design. Your entities should probably not use reference counting... reference counting is more for like a group of entities or larger subsystems.
If I were implementing your game, I'd be using the structure of arrays approach, using homogeneous arrays for each entity field/component. Removing an entity would just involve setting a flag, and at a synchronization point during the update pipeline, I would remove the entity by copying the remainder of each array over the entity offset and decrement the entity count.
No reference counting. The entity system/scene graph has strong ownership of the entity arrays, which are generally allocated at load time and have a fixed upper bound.
If you need an object-oriented class to coalesce all of the fields from each array for a particular entity offset/id, just create a simple object-oriented view abstraction, similar to how you can create views in RDBMSes.
This is the data-oriented approach which is popular among professional game developers for modern games. It's fast as fuck, it's easier to parallelize, and doesn't thrash the cache or fragment your allocators. It also usually ends up being less code too than an more OO approach.
Fine-grained object-oriented factory systems for entities/game objects is the amateur design.