entt: Components references are invalidated upon call to registry.assign().

The problem is that this returned reference is brittle.

The actual error is that you shouldn’t retain references to components, the same way as you shouldn’t retain references to elements in a vector.
Moreover, if a vector offers you a position (index) as a safe way to access elements, the registry offers you the entity identifier.
The parallel can continue, but you got the idea.

If you wont change the underlying SparseSet type, then you shouldn’t return references to components from anywhere except while iterating views. That way, it’s clear from the API that such references are error prone.

Note that ie std::vector<T>::emplace_back returns a reference to the inserted element. I wouldn’t define not clear a behavior just copied over from the standard library.

It should be possible to keep the reference to components around as long as the instance is alive and the component hasn’t been removed.

Indeed, it shouldn’t. Put aside the fact that you shouldn’t do that in general in C++, references are not meant for that. Use entity identifiers instead. Moreover, pools won’t be able to rearrange elements when needed and offer you the best performance in all cases if we decided to give such a strong guarantee.

There are ways to deal with that:

Let me explain why these are all the ways wrong.

Change the underlying type in SparseSet to a non-memory-moving container, like std::list (Yes, there is a speed hit; it could be a template param to sparse-set, for trade-offs).

Non contiguous memory, it would defeat one of the purposes of using an ECS and ruin performance. Moreover, the parameter should be of the registry, then pushed down to sparse sets and so on. More code to maintain (for free, and I’m not willing to maintain code I dislike for free) for no benefits.
Just use the tool the way it’s meant.

Instead of storying the memory directly in the vector, store it in a std::unique_ptr, and return a ‘*it.get()’ from the unique_ptr.

This would defeat completely the effort spent to keep components tightly packed. You would jump in memory each and every time you access a component, with an indecent loss of performance.

Use a block allocator that doesn’t resize memory, but just fetches blocks when it runs out of memory.

No longer contiguous memory, the API would change (ie no more data member functions), you would miss some features (you cannot memcpy components at once) and performance would degrade, just to mention some drawbacks.
Moreover, a fully allocator-aware library is in my plans and the goal is quite different than this, therefore it would also force me to redesign it to match another allocator introduced for no benefits.

As a side note, none of the above proposals would solve the problem. A sparse set rearranges elements on destroy and references would still be invalidated in this case. So, they are just half a solution and cannot be applied this way.

Ironically, entity identifiers already manage to abstract everything and they offer even much more than what you would obtain with the approaches above mentioned (stable index, versioning, null value, and so on). So, we would also miss some other useful features.

---

EnTT already offers a way to keep track of components with stable identifiers, it sticks to the behavior and the API of the standard library and so far I haven’t read in this issue of an alternative approach that would represent an improvement.

For me, an invalid request. I’m sorry.
I’ll close this in a couple of days if no good reasons pop out in the meantime to convince me that this is a must have (extra) feature.

EnTT offers pointer stability upon addition by default nowadays and also a stable pointer mode for all operations on requests. It doesn’t use the handle mechanism that you described though, mostly for performance reasons. get-ting the component all the times would be a waste of cpu cycles in like 99% of cases. On the other hand, it’s easy to implement such a handle on top of EnTT if you want it.

Oh, ok, yeah, in this case the reference can get invalidated. Good point.

@gamagan You should shouldn’t be holding onto component references. This is not a bug. You should be using entity IDs. Entity IDs are stable. You can hold onto them for as long as you like and they won’t become invalidated.

All of your suggestions to “fix” this will slow down this very fast library. The following example is safe. foo will not be handed invalid references.

void fun(entt::registry<> &reg) {
  reg.assign<Comp>(id1);
  auto &comp2 = reg.assign<Comp>(id2);
  foo(reg.get<Comp>(id1), comp2);
}