|
EnTT 3.14.0
|
EnTT has become almost completely customizable over time, in many respects. These variables are just one of the many ways to customize how it works.
In the vast majority of cases, users will have no interest in changing the default parameters. For all other cases, the list of possible configurations with which it's possible to adjust the behavior of the library at runtime can be found below.
All options are intended as parameters to the compiler (or user-defined macros within the compilation units, if preferred).
Each parameter can result in internal library definitions. It's not recommended to try to also modify these definitions, since there is no guarantee that they will remain stable over time unlike the options below.
Define this variable without assigning any value to it to turn off exception handling in EnTT.
This is roughly equivalent to setting the compiler flag -fno-exceptions but is also limited to this library only.
In general, EnTT doesn't offer primitives to support multi-threading. Many of the features can be split over multiple threads without any explicit control and the user is the one who knows if a synchronization point is required.
However, some features aren't easily accessible to users and are made thread-safe by means of this definition.
entt::id_type is directly controlled by this definition and widely used within the library.
By default, its type is std::uint32_t. However, users can define a different default type if necessary.
It's known that the ECS module of EnTT is based on sparse sets. What is less known perhaps is that the sparse arrays are paged to reduce memory usage.
Default size of pages (that is, the number of elements they contain) is 4096 but users can adjust it if appropriate. In all case, the chosen value must be a power of 2.
As it happens with sparse arrays, packed arrays are also paginated. However, in this case the aim isn't to reduce memory usage but to have pointer stability upon component creation.
Default size of pages (that is, the number of elements they contain) is 1024 but users can adjust it if appropriate. In all case, the chosen value must be a power of 2.
For performance reasons, EnTT doesn't use exceptions or any other control structures. In fact, it offers many features that result in undefined behavior if not used correctly.
To get around this, the library relies on a lot of asserts for the purpose of detecting errors in debug builds. By default, it uses assert internally. Users are allowed to overwrite its behavior by setting this variable.
Usually, an assert within a constexpr function isn't a big deal. However, in case of extreme customizations, it might be useful to differentiate.
For this purpose, EnTT introduces an admittedly badly named variable to make the job easier in this regard. By default, this variable forwards its arguments to ENTT_ASSERT.
Assertions may in turn affect performance to an extent when enabled. Whether ENTT_ASSERT and ENTT_ASSERT_CONSTEXPR are redefined or not, all asserts can be disabled at once by means of this definition.
Note that ENTT_DISABLE_ASSERT takes precedence over the redefinition of the other variables and is therefore meant to disable all controls no matter what.
In order to reduce memory consumption and increase performance, empty types are never instantiated nor stored by the ECS module of EnTT.
Use this variable to treat these types like all others and therefore to create a dedicated storage for them.
EnTT mixes non-standard language features with others that are perfectly compliant to offer some of its functionalities.
This definition prevents the library from using non-standard techniques, that is, functionalities that aren't fully compliant with the standard C++.
While there are no known portability issues at the time of this writing, this should make the library fully portable anyway if needed.
1.10.0