Memory Management Design

Question

I am having some issues designing the memory management for an Entity-Component system and am having some issues coming up with the detail of the design. Here is what I am trying to do (note that all of these classes except Entity are actually virtual, so will have many different specific implementations):

The Program class will have a container of Entity's. The Program will loop through the Entity's and call update on each of them. It will also have a few SubSystem's, which it will also update on each loop through.

Each Entity will contain two types of Component's. All of them will be owned by a unique_ptr inside the Entity since their lifetime is directly tied to the entity. One type, UpdateableComponent, will be updated when the Entity.update() method is called. The second type SubSystemComponent will be updated from within their respective SubSystem.

Now here are my two problems. The first is that some of the Component's will control the lifetime of their parent Entity. My current idea for this is that Component will be able to call a function parent.die() which would change an internal flag inside Entity. Then after Program finishes looping through its updates, it loops through a second time and removes each Entity which was marked for deletion during the last update. I don't know if this is an efficient or smart way to go about it, although it should avoid the problem of an Entity dieing while its Component's are still updating.

The second issue is that I am not sure how to reference SubSystemComponent's from within SubSystem. Since they are refered to by a unique_ptr from inside Entity, I can't use a shared_ptr or a weak_ptr, and a standard pointer would end up dangling when the Entity owning a component dies. I could switch to a shared_ptr inside the Entity for these, then use a weak_ptr in the SubSystem's, however I would prefer to not do this because the whole point is that Entity completely owns its Component's.

So 2 things:

Can my first idea be improved upon in a meaningful way?
Is there an easy way to implement a weak_ptr sort of functionality with unique_ptr, or should I just switch to shared_ptr and just make sure to not create more than one shared_ptr to the SubSystemComponent's

I think you may want to do a little bit more research on memory management unless you are dead-set on this design; looping through your entire allocated memory space multiple times will not be scalable. Smart pointers are always a good and simple way to start initially. Additionally, there are already a few well-established C++ libraries that do [garbage collection](http://stackoverflow.com/questions/81062/garbage-collection-libraries-in-c). — Suedocode, Jul 02 '13 at 04:16
@Aggieboy I have already thought about the scaling issue, and have worked out loading only portions of the data into `Entity`'s limiting me to a few thousand (maybe 10-20 at most) at once. Would the second loop really be that inefficient if I simply call a bool getter, and optionally remove `Entity`'s from the container. This design is more to increase code reusability rather than performance, and I can easily optimize bottlenecks later. — Godric Seer, Jul 02 '13 at 04:25
You could simply check for the `hasToDie` flag before you try updating a component, that is not an issue. However, `unique_ptr`s are explicitly designed for singular, strict ownership. As long as more than one object needs a reference (which is guaranteed to be always valid or at least checkable), you won't get past `shared_ptr` and possibly `weak_ptr`, as you already pointed out. — arne, Jul 02 '13 at 05:16
@arne the one issue I have with checking during the update loop, is that imagine the update detects collisions. The first Entity will be able to collide with "dead" objects while the last Entity will not. Although, if I loop through the updates first, checking for death, then do the SubSystem updates, which would include interactions like collisions. . . maybe that would simplify it. — Godric Seer, Jul 02 '13 at 11:14

score 1 · Answer 1 · answered Jul 02 '13 at 05:34

Can my first idea be improved upon in a meaningful way?

Hard to say without knowing more about the nature of the work being undertaken. For example, you haven't said anything about your use of threads, but it seems your design gives equal priority to all the possible updates by cycling through things in a set sequence. For some things where low latency is important, or there's some useful prioritorisation that would ideally be done, a looping sequence like that isn't good, while other times it's ideal.

There are other ways to coordinate the Component-driven removal of Entities from the Program:

return codes could bubble up to the loop over entities, triggering an erase from the container of Entities,
an Observer pattern or lambda/std::function could allow the Program to specify cleanup behaviour.

Is there an easy way to implement a weak_ptr sort of functionality with unique_ptr,

No.

or should I just switch to shared_ptr and just make sure to not create more than one shared_ptr to the SubSystemComponent's

It sounds like a reasonable fit. You could even wrap a shared_ptr in a non-copyable class to avoid accidental mistakes.

Alternatively - as for Entity destruction above - you could coordinate the linkage between SubSystem and SubSystemComponent using events, so the SubSystemComponent destructor calls back to the SubSystem. An Observer pattern is one way to do this, a SubSystemComponent-side std::function fed a lambda is even more flexible. Either way, the Subsystem removes the SubSystemComponent from its records.

Memory Management Design

1 Answers1