Abuse entt::internal::type_index::next()

[BossFeratu]

Hello!

I (think I) need to create unique type ids for storages at runtime, in order for have some private storage to use in dynamically created objects in my program. I could use arrays of hashed strings as a workaround, but that would not really match the requirement.

Then I found entt::internal::type_index::next(), which would do the job, if calling it doesn't break anything, e.g. the need for sequential IDs for real types. But since no new type will appear at runtime, I guess that would still be guaranteed.
I am aware that using internal implementation details from client code is a no-go, I was just trying if it would work.

Are there any suggestions how I could achieve this less criminal?

[skypjack]

The core family class is what you're looking for probably?

[BossFeratu]

Wouldn't that interfere with the actual type ids in the registry?
The intended usage of the ID is as a key to a storage, not an entity.

[skypjack]

The registry doesn't use the family class 🤔 I mean family.hpp under core, just to be clear.
Why do you think that using it can affect the registry?
Anyway, if you want a different approach, you can compile-time or runtime hash a random or user provided string with the hashed string class and use the returned value for your purposes.

[BossFeratu]

I agree that hashed strings without collision resolution is a valid option at compile time, but for my system it is not really an option to respond with something like "collision detected, please choose another name", no matter how unlikely.
Maybe this illustrates what I wish to achieve:

// inside the constructor of some observing class
auto reg = registry();
auto const privateStorageID = nextUniqueStorageID(); // the magic function
reg.storage<void>(privateStorageID).push(someEntity);

// iterate entities that are dirty and owned by me
entt::basic_view
{
    reg.storage<Data>(),
    reg.storage<Dirty>(),
    reg.storage<void>(privateStorageID)
}.each([this](entt::entity e, auto&& data)
{ /* ... */});

Maybe I should mention that this is not a game, instead I'm evaluating if EnTT is an option as data storage for a control system of some technical devices.
As I understand it, the ID for an additional storage must not be equal to any type id used inside the registry. If that assumption is wrong, I have no trouble and my original question voids.

[skypjack]

Yeah, exactly. You can still check if a storage exists for a given id though. Not a big deal.
Out of curiosity, is there a particular reason for which you cannot use a plain integer that you ++ as needed?
If you register all known storage types from the beginning, the generator only need to check if the id is already in use in the registry and ++ again eventually until it finds the next free one.

[BossFeratu]

Out of curiosity, is there a particular reason for which you cannot use a plain integer that you ++ as needed?

That's exactly what I would do, and what type_index::next() does. I just want to avoid collisions between them.

If you register all known storage types from the beginning, the generator only need to check if the id is already in use in the registry and ++ again eventually until it finds the next free one.

Maybe this is a solution, but it really requires all software modules to register all used types before the first ID is being created. Sounds like a plan B to me.
I think I'd rather start at a reasonable huge ID, maybe max/2, and prohibit hashed strings in my program.

Thank you very much for you replies, I find your library extremely elegant, hope I can convince our team to go that way.

[BossFeratu]

But wait, is it really possible that a default storage is registered after the program started? Aren't all these type IDs generated at compile time, whenever registry::storage() is mentioned, directly or indirectly? If I can take this for granted (ignoring dlopen()), I think I would prefer your proposed try/error method.

[skypjack]

is it really possible that a default storage is registered after the program started?

The registry performs a lazy initialization of the storage objects. This is also the reason for which it can support runtime pools.
So, yeah, a default storage is registered with the registry the first time you pass the component type to it. Otherwise, the registry doesn't know about this type.

Something you can do is this: if you use internal types for your software, you can assign fixed and known values to them (yes, this is possible). Then you know what the ceil is and start from there with the user counter. Maybe with a reasonable margin for new internal types that can pop up in future.
The fact is that you can customize almost everything in EnTT. So, well, cast your idea if you don't like this one and let's see if we can manage to do that eventually. 🙂

[BossFeratu]

So, yeah, a default storage is registered with the registry the first time you pass the component type to it

Sorry that I am a bit confused with this, but does that mean at the time the program runs over an access to the storage, or at the time the compiler encounters the access? I thought (and hope) the latter, and then I would be a safe bet that no new default storages can appear during runtime.