entt: ECS visit issue. Members not defined?

I’m trying to copy all stuff from one registry to anther and in the documentation this example claims to do exactly this.

registry.visit([&](const auto info) { auto storage = registry.storage(info); other.storage(info)->insert(other, storage->data(), storage->raw(), storage->size()); });

Both other and registry are entt::registry&

When using visual studio. I get some errors saying. data, insert, raw, size and __this is not a member of entt::Storage<>

I’m including all the entt headers too so I shouldn’t be missing anything

I pulled the latest i can off of git here and entt::storage seems to be defined correctly. So I don’t know if I’m doing something wrong here or if there’s just a newer way to do it.

Edit: Solution for msvc Old: https://godbolt.org/z/h4q9o1ecj New: https://godbolt.org/z/8jccbE4vb

Thanks for @cmartel for posting a solution to this

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 21 (9 by maintainers)

Most upvoted comments

Ive used that to try getting it working, i cant figure out that the issue im having even is. When i translate that into msvc i get these compiler errors now.

This should be exactly the same as on that example but i still get compiler issues.

So im at a loss on how to even approach fixing that

Could you provide a full error message from the “Output” tab? It contains way more information than “Errors” tab output, namely information about the location of the problem.

Innokentiy-Alaytsev on Apr 28, 2021

The first post is just a usage issue, of having to make the type trait visible before the first registry instantiation. Otherwise the default poly_storage class is used, of which the functions called are indeed not a member.

The other problem isn’t with entt itself, but with the godbolt example you provide here. For some reason, the free floating copy_to compiles normally on clang but has a type deduction ambiguity in msvc. It’s a good, compact example of the functionality so fixing the example might avoid confused new users in the future. 😃

The workaround I used was to adopt the same “members” struct that is used in the other example (that is, the poly_storage unit test file). I don’t know if the free floating function could be disambiguated instead, but because having the template type moved outer struct and shared between members is actually very convenient, I personally ended up retaining that approach.

cmartel on May 8, 2021

I dare to say that this isn’t due to EnTT, it’s how C++ works.

Oh, you’re absolutely right! But as I mentioned, I’ve only dealt with basic usages of type traits (mainly overload resolution). That usage made it seem like having a type trait defined is sufficient, when it probably just wasn’t nearly as likely to be defined after its usage. Whereas this particular case happens as soon as a registry is defined so much more likely to trip. 😃

Are you suggesting that a dynamic model with which we can change how a type is copied at runtime would be useful?

Not currently, no–I was mainly trying to confirm my understanding of the poly storage. I wasn’t certain if the functionality thus added was “free floating” or tied to the registry. I’ve since confirmed it’s the latter, so I’ll centralise the different uses of visit/poly_storage instead of trying to organise them into separate files.

I don’t want to keep hijacking this thread, but hopefully this discussion might’ve helped anthofoxo figure out their problem.

cmartel on May 1, 2021