Fix some Compiling Errors

[abeimler]

Hi,
I was trying out gaia-ecs in my Project and encountered some Compiler- and Linking-Error(s):

Can not convert to std::span

Error:

build/_deps/gaia-src/include/gaia/ecs/query_info.h:725:68: Fehler: »gaia::cnt::sarr_ext<gaia::ecs::Entity, 8>« kann nicht nach »gaia::ecs::EntitySpanMut« {aka »std::span<gaia::ecs::Entity>«} umgewandelt werden
  725 |                                                                 e, ids_all, data.as_mask, data.as_mask_2);
      |                                                                    ^~~~~~~
      |                                                                    |
      |                                                                    gaia::cnt::sarr_ext<gaia::ecs::Entity, 8>

Linking Error for EntityBad

Error:

mold: error: duplicate symbol: gaia::ecs::EntityBad

[richardbiely]

Thank you for the merge request. This is the very first one ever :)

Would you mind sharing your setup so I can prevent this issue in the future?
I'm running various compilers on various platforms and did not catch it so there must be something missing in my methodology.

It was probably because of multiple source files that include gaia.h, right?

[abeimler]

Would you mind sharing your setup so I can prevent this issue in the future? I'm running various compilers on various platforms and did not catch it so there must be something missing in my methodology.

I'm sure there is something in the setup for more pedantic and stricter rules for explicit conversion, I will share more details later.

It was probably because of multiple source files that include gaia.h, right?

yes, I'm including <gaia.h> in multiple files.

[richardbiely]

From my experience, using these for Clang:
-O2 -std=c++17 -Wall -Wextra -pedantic -pedantic-errors -Werror -Wshadow -Wno-deprecated-declarations
behaves differently on different systems.

It catches different things on my Linux in Docker, on my native MacOS and also on Godbolt even though the same compiler version is used. I need to figure this out somehow.

For the time being, I managed to fix a bunch of other issues as well (hopefully all of them).

[abeimler]

For Context abeimler/ecs_benchmark#17

[richardbiely]

I see.

Nice to see the framework doesn't fare bad against the rest even in its early stages.
You probably won't like it that systems are going to change in the following weeks (they are currently undocumented for a reason). But I might come back to you with a PR later.

[RazielXYZ]

Thank you for the merge request. This is the very first one ever :)

Would you mind sharing your setup so I can prevent this issue in the future? I'm running various compilers on various platforms and did not catch it so there must be something missing in my methodology.

It was probably because of multiple source files that include gaia.h, right?

This specifically only happens (or rather, happened) when building with /std:c++20 or later.
And on that note, std::span is technically a C++20 feature. I see it used quite a lot across many places in gaia. To support it, compiler requirements should be bumped (gcc 10, msvc 16.6, apple clang 10, clang and icx can stay on 7 and 2021.1.2 respectively I believe).

[richardbiely]

No need to bump compiler requirements.

While std::span is a C++20 feature indeed, the project has a backwards-compatible version of span implemented. Thanks to that it can continue running on C++17.

When native support is detected the project makes use of it.

The issue is that the compatibility layer implementation differs slightly from the mainline. I'll look into it in the future. For the time being, I switched to building the project with later C++ versions as well to avoid similar issues missing my eye.

[RazielXYZ]

@richardbiely Right, I didn't see the namespace std {using TCB_SPAN_NAMESPACE_NAME::span;} in span.h 😅 cool if a little bit unexpected. Does make the transition cleaner though!

[richardbiely]

Exactly :)

Although later standards bring many interesting new features to the table, I am aiming for C++17 because it is well adopted and also reasonably nice feature-wise.

To me, std::span is the only obvious feature missing from 17. I could easily replace all occurrences of it with a pointer+size variables, but that makes the code way less readable (and spans are used a lot by the project).