Entt: Call for comments: push EnTT across boundaries

[skypjack]

Time for a new _call for comments_ of a few days so as to add a new note in the TODO file for future developments.
The topic popped out of some PRs and issues during the last weeks: EnTT and shared libraries.

So far, EnTT has proven to work somehow when both an executable and a shared library are involved. However, the way to go has some limitations and the solution doesn't scale easily to multiple shared libraries.
Because of this, I'm exploring other approaches to see if we can do more on this side or if it's an intrinsic limit of this library and the burden is all on user side. This means that users can still use EnTT in case of multiple shared libraries in future but with some troubles (@Milerius is currently our _explorer_ along the path, thanks for the help).

I'm not an expert in this field, so comments, feedback, suggestions and help in general is appreciated.

So far, it seems that the problems with shared libraries are mainly due to allocations across boundaries and the Family class template.
While the former should be mitigated by the possibility of setting custom allocators, I focused on a few alternatives to address the latter:

• Mixed compile-time/runtime registry. There was a time when EnTT was a fully compile-time ECS, then I switched to a fully runtime ECS. Well... This will solve the problem because identifiers for shared types are fixed at compile-time and users that aren't interested won't have any performance issue. The sole drawback is that compilation time increases when compile-time stuff is used. Ironically, types for which identifiers are set at compile-time will have probably better performance. Therefore users can also decide to develop in the current mode to reduce compilation time, then switch to compile-time registry before to release in order to gain a bit of performance.

• Allow users to set a custom family type to the registry. In other terms, the Registry class template will have an extra template parameter. The burden is moved completely user side and EnTT cannot guarantee anymore performance on some operations, that is when families are involved. On the other side, users can decide to use whatever fits with their requirements instead of being stuck with a built-in solution.

• Rewrite the Family class template so as to avoid static stuff. I created also a question on SO for that but so far nobody came up with a valid alternative that offers the same functionalities and doesn't ruin the performance at the same time.

• I've also another solution in mind that is based on sparse set and aims to review the way pools are stored within the Registry. It would introduce a minimal performance hit on some operations, something that is probably worth it. However, before to explore it, I'd like to stress the other approaches and see if I can find something that _works_ (for some definitions of _works_).

Affected classes are in fact Registry, Dispatcher and Emitter, even though the discussion focused only on the first one. The same solutions can obviously be applied to all of them, so let's concentrate only on one of them.

And that's all. Let's discuss it.

[ArnCarveris]

Allow users to set a custom family type to the registry. In other terms, the Registry class template will have an extra template parameter.

Well I vote for this, but keep in mind that you need change this friend class Registry<Entity>, because custom family type is unknown for other classes.

[Milerius]

All the solutions seem interesting, I would be more for a solution where we have the less possible static variable, an approach where we would have counters that are in-house member of EnTT and which increments as and when without passing through a Static class would be the top in my opinion.

[skypjack]

@Milerius The mixed registry goes along this way. The more components you use to define it, the less static stuff you have. Unfortunately, compilation time grows up, but I think we cannot have the cake and eat it in this case.

[skypjack]

It seems that inline variables work fine across boundaries to some extents, but it isn't guaranteed by the standard, so it's not something on which to rely as a solution. As expected, it doesn't exist a drop-in replacement for the family class template and we have to work around its limitations somehow differently.

[Milerius]

@skypjack as i say make a family class with a regular counter inside, and registry/dispatcher can have a family as member, no ?

[skypjack]

Ok, I got some information all around. Sooner or later I'll try to do something along this path.
It's not a requirement for me right now, so it will take a while, because I'll give precedence to other things probably.
Btw, I plan to make EnTT more _shared libraries friendly_. Stay tuned.

Thank you all for participating.