Return to Answer

EXPORT UnitHandle unit_insert(struct Units* units, ...);
EXPORT void unit_remove(struct Units* units, UnitHandle unit);

Just a quick mention but naturally this proposed solution couples and fuses your element with its central container (or if "container" seems too high-level for your needs, you can just think of it as a "memory pool"), making the two indivisible. But I'd say it's a practical thing to do that has a lot of benefits at little practical cost.

EXPORT UnitHandle units_insert(Units* units, ...);
EXPORT void units_remove(Units* units, UnitHandle unit);

Just a quick mention but naturally this proposed solution couples and fuses your element with its central container (or if "container" seems too high-level for your needs, you can just think of it as a "memory pool" or even "instance storage" or whatever), making the two indivisible. But I'd say it's a practical thing to do that has a lot of benefits at little practical cost.

Coupling

Just a quick mention but naturally this proposed solution couples and fuses your element with its central container (or if "container" seems too high-level for your needs, you can just think of it as a "memory pool"), making the two indivisible. But I'd say it's a practical thing to do that has a lot of benefits at little practical cost.

Because what sort of practical flexibility is there to, say, decouple a pixel from the image that owns it, and allows pixels to be allocated and destroyed individually? And similarly for particles of a particle system? Because I see little, if any, but there is almost certainly a tremendous cost to such decoupling in this particular context.

So I'd say don't worry about it. If your design conceptually calls for some central container, or at least has a strong enough performance-critical need that it could benefit from an organized memory allocation/pooling strategy, then tailor your design around this idea of "insertion/removal" over "creation/destruction" or "allocating/freeing", and reap the benefits -- of which first and foremost is the elimination of the need to worry about your designs encouraging too many malloc/free calls.

And sometimes you need this level of explicit memory control over an individual instance of an object. But often if you zoom out and look at the broader design requirements, especially in like a game, and for the most performance-critical parts of it (usually implying that you'll want to be creating a boatload of such instances), you'll often find these things want to belong to some central container/data structure, like a game Scene, or Map, or Board, and that it makes no sense for these Units to live anywhere else or be "owned" by anything else.

And sometimes you need this level of explicit memory control over an individual instance of an object. But often if you zoom out and look at the broader design requirements, especially in like a game, and for the most performance-critical parts of it (usually implying that you'll want to be creating a boatload of such instances), you'll often find these things want to belong to some central container/data structure, like a game Scene, or Map, or Board, and that it makes no sense for these Units to live anywhere else or be "owned" by anything else*.

• There might be some auxiliary data structures in-game which want to reference/index/point to such units, like a spatial index used to accelerate collision detection, but those structures don't "own" the elements. They refer to them, but there is still one central "owning" collection.