From 401b1db1a0aaadc645ec01cb8e0df2257d6cdbc9 Mon Sep 17 00:00:00 2001
From: Michele Caini This is a constantly updated section where I'll try to put the answers to the most frequently asked questions. First of all, there are two things to do in a Windows project: Moreover, the macro With these changes, debug performance should increase enough for most cases. If you want something more, you can can also switch to an optimization level This is one of the first questions that anyone makes when starting to work with the entity-component-system architectural pattern. I tried to describe some of the techniques that fit well with the model of Long story short, you can always define a tree where the nodes expose implicit lists of children by means of the following type: The sort functionalities of Custom entity identifiers are definitely a good idea in two cases at least: These identifiers are nothing more than enum classes with some salt. In fact, this is the definition of The use of this macro is highly recommended, so as not to run into problems if the requirements for the identifiers should change in the future. According to this issue, using a hashed string under VS could generate a warning. To suppress it and if you don't want to suppress all the other warnings as well, here is a workaround in the form of a macro: With an example of use included: Thanks to huwpascoe for the courtesy. On Windows, a header file defines two macros It's a pretty big problem but fortunately it's not a problem of Please refer to this issue for more details. This is a constantly updated section where I'll try to put the answers to the most frequently asked questions. Moreover, the macro With these changes, debug performance should increase enough for most cases. If you want something more, you can can also switch to an optimization level This is one of the first questions that anyone makes when starting to work with the entity-component-system architectural pattern. I tried to describe some of the techniques that fit well with the model of Long story short, you can always define a tree where the nodes expose implicit lists of children by means of the following type: The sort functionalities of Custom entity identifiers are definitely a good idea in two cases at least: In fact, this is the definition of The use of this macro is highly recommended, so as not to run into problems if the requirements for the identifiers should change in the future. According to this issue, using a hashed string under VS could generate a warning. To suppress it and if you don't want to suppress all the other warnings as well, here is a workaround in the form of a macro: With an example of use included: Thanks to huwpascoe for the courtesy. On Windows, a header file defines two macros It's a pretty big problem but fortunately it's not a problem of Please refer to this issue for more details. Please refer to this issue for more details. For example, When trying to assign an instance of this type to an entity in the ECS part, this may trigger a compilation error because we cannot really make a copy of it. Unfortunately, this will also disable aggregate initialization. To allow a type to work properly across boundaries when used by a class that requires to assign unique identifiers to types, users must specialize a class template to literally give a compile-time name to the type itself. As an example: Because of the rules of the language, the specialization must reside in the global namespace or in the The good aspect of this approach is that it's not intrusive at all. The other way around was in fact forcing users to inherit all their classes from a common base. Something to avoid, at least from my point of view. Someone might think that this trick is valid only for the types to push across boundaries. This isn't how things work. In fact, the problem is more complex than that. Indeed, this constraint can be relaxed in many cases. However, it is difficult to define a general rule to follow that is not the most stringent, unless users know exactly what they are doing. Therefore, I won't elaborate on giving further details on the topic. The library comes with a set of predefined macros to use to declare named types or export already existing ones. In particular: Nested namespaces are supported out of the box as well in all cases. As an example: These macros can be used to avoid specializing the When using macros, unique identifiers are 32/64 bit integers generated by hashing strings during compilation. Therefore, conflicts are rare but still possible. In case of conflicts, everything simply will get broken at runtime and the strangest things will probably take place. As long as To allow users to add types dynamically, the library makes extensive use of type erasure techniques and dynamic allocations for pools (whether they are for components, events or anything else). The problem occurs when, for example, a registry is created on one side of a boundary and a pool is dynamically created on the other side. In the best case, everything will crash at the exit, while at worst it will do so at runtime. Maybe one day some dedicated methods will be added that do nothing but create a pool for a given type. Until now it has been preferred to keep the API cleaner as they are not strictly necessary. To allow a type to work properly across boundaries when used by a class that requires to assign unique identifiers to types, users must specialize a class template to literally give a compile-time name to the type itself. Because of the rules of the language, the specialization must reside in the global namespace or in the The good aspect of this approach is that it's not intrusive at all. The other way around was in fact forcing users to inherit all their classes from a common base. Something to avoid, at least from my point of view. Someone might think that this trick is valid only for the types to push across boundaries. This isn't how things work. In fact, the problem is more complex than that. Indeed, this constraint can be relaxed in many cases. However, it is difficult to define a general rule to follow that is not the most stringent, unless users know exactly what they are doing. Therefore, I won't elaborate on giving further details on the topic. The library comes with a set of predefined macros to use to declare named types or export already existing ones. In particular: Nested namespaces are supported out of the box as well in all cases. As an example: These macros can be used to avoid specializing the When using macros, unique identifiers are 32/64 bit integers generated by hashing strings during compilation. Therefore, conflicts are rare but still possible. In case of conflicts, everything simply will get broken at runtime and the strangest things will probably take place. The runtime reflection system deserves a special mention when it comes to using it across boundaries. The runtime reflection system is linked to a static context to which the visible components are linked. A component is visible when it's given a name, so the named components are implicitly visible. Sharing a context is straightforward. First of all, the local one must be acquired: Then, it must be pushed across boundaries and the receiving space must set it as its global context, thus releasing the local one that remains available but is no longer referred to by the runtime reflection system: From now on, both spaces will refer to the same context and on it will be associated the new visible meta types, no matter where they are created. A context can also be reset and then associated again locally as: This is allowed because local and global contexts are separated. Therefore, it's always possible to make the local context the current one again. As long as To allow users to add types dynamically, the library makes extensive use of type erasure techniques and dynamic allocations for pools (whether they are for components, events or anything else). The problem occurs when, for example, a registry is created on one side of a boundary and a pool is dynamically created on the other side. In the best case, everything will crash at the exit, while at worst it will do so at runtime. Below an incomplete list of games, applications and articles that can be used as a reference. Where I put the word apparently means that the use of I hope this list can grow much more in the future: If you know of other resources out there that are about Below an incomplete list of games, applications and articles that can be used as a reference. Where I put the word apparently means that the use of I hope this list can grow much more in the future: If you know of other resources out there that are about Usually service locators are tightly bound to the services they expose and it's hard to define a general purpose solution. This template based implementation tries to fill the gap and to get rid of the burden of defining a different specific locator for each application. The API is straightforward. The basic idea is that services are implemented by means of interfaces and rely on polymorphism. The locator can also be queried to know if an active service is currently set and to retrieve it if necessary (either as a pointer or as a reference): A common use is to wrap the different locators in a container class, creating aliases for the various services: Reflection (or rather, its lack) is a trending topic in the C++ world and, in the specific case of The meta system doesn't force the user to use the tools provided by the library when it comes to working with names and identifiers. It does this by offering an API that works with opaque identifiers that may or may not be generated by means of a hashed string. However, the examples in the following sections are all based on the For what it's worth, this is likely completely equivalent to: Obviously, human-readable identifiers are more convenient to use and highly recommended. Reflection always starts from real types (users cannot reflect imaginary types and it would not make much sense, we wouldn't be talking about reflection anymore). It accepts the type to reflect as a template parameter and an optional identifier as an argument. Identifiers are important because users can retrieve meta types at runtime by searching for them by name. However, there are cases in which users can be interested in adding features to a reflected type so that the reflection system can use it correctly under the hood, but they don't want to allow searching the type by name. A factory is such that all its member functions returns the factory itself. It can be used to extend the reflected type and add the following: Below an incomplete list of games, applications and articles that can be used as a reference. Where I put the word apparently means that the use of I hope this list can grow much more in the future: A function should neither delete nor explicitly invoke the destructor of a given instance. This function requires as an argument the identifier to give to the meta data once created. Users can then access meta data at runtime by searching for them by name. This function requires as an argument the identifier to give to the meta function once created. Users can then access meta functions at runtime by searching for them by name. From now on, wherever a That's all, everything users need to create meta types and enjoy the reflection system. At first glance it may not seem that much, but users usually learn to appreciate it over time. The reflection system comes with its own meta any type. It may seem redundant since C++17 introduced A meta any object provides an API similar to that of its most famous counterpart and serves the same purpose of being an opaque container for any type of value. A meta any object can be created by any other object or as an empty container to initialize later: It takes the burden of destroying the contained instance when required. In this case, the contained instance is never destroyed and users must ensure that the lifetime of the object exceeds that of the container. A meta any object has a Once the web of reflected types has been constructed, it's a matter of using it at runtime where required. To search for a reflected type there are two options: by type or by name. In both cases, the search can be done by means of the There exits also a third overload of the In all cases, the returned value is an instance of The meta objects that compose a meta type are accessed in the following ways: The returned type is The returned type is The returned type is The returned type is The returned type is The returned type is All the objects thus obtained as well as the meta types can be explicitly converted to a boolean value to check if they are valid: Furthermore, all meta objects with the exception of meta destructors can be iterated through an overload that accepts a callback through which to return them. As an example: A meta type can also be used to Meta types and meta objects in general contain much more than what is said: a plethora of functions in addition to those listed whose purposes and uses go unfortunately beyond the scope of this document. Policies are a kind of compile-time directives that can be used when recording reflection information. There are a few alternatives available at the moment: The as-void policy, associated with the type As an example of use: The as-alias policy, associated with the type As an example of use: Some uses are rather trivial, but it's useful to note that there are some less obvious corner cases that can in turn be solved with the use of policies. A special mention should be made for constant values and enums. It wouldn't be necessary, but it will help distracted readers. As mentioned, the All the values thus exported will appear to users as if they were constant data members of the reflected types. Exporting constant values or elements from an enum is as simple as ever: It goes without saying that accessing them is trivial as well. It's a matter of doing the following, as with any other data member of a meta type: As a side note, remember that all this happens behind the scenes without any allocation because of the small object optimization performed by the meta any class. Sometimes (for example, when it comes to creating an editor) it might be useful to be able to attach properties to the meta objects created. Fortunately, this is possible for most of them. The meta objects that support properties offer then a couple of member functions named Meta properties are objects having a fairly poor interface, all in all. They only provide the A type registered with the reflection system can also be unregistered. This means unregistering all its data members, member functions, conversion functions and so on. However, the base classes won't be unregistered, since they don't necessarily depend on it. Similarly, implicitly generated types (as an example, the meta types implicitly generated for function parameters when needed) won't be unregistered. To unregister a type, users can use the This function returns a boolean value that is true if the type is actually registered with the reflection system, false otherwise. If you know of other resources out there that are about Reflection (or rather, its lack) is a trending topic in the C++ world and, in the specific case of Usually service locators are tightly bound to the services they expose and it's hard to define a general purpose solution. This template based implementation tries to fill the gap and to get rid of the burden of defining a different specific locator for each application. The meta system doesn't force the user to use the tools provided by the library when it comes to working with names and identifiers. It does this by offering an API that works with opaque identifiers that may or may not be generated by means of a hashed string. However, the examples in the following sections are all based on the For what it's worth, this is likely completely equivalent to: Obviously, human-readable identifiers are more convenient to use and highly recommended. Reflection always starts from real types (users cannot reflect imaginary types and it would not make much sense, we wouldn't be talking about reflection anymore). It accepts the type to reflect as a template parameter and an optional identifier as an argument. Identifiers are important because users can retrieve meta types at runtime by searching for them by name. However, there are cases in which users can be interested in adding features to a reflected type so that the reflection system can use it correctly under the hood, but they don't want to allow searching the type by name. A factory is such that all its member functions returns the factory itself. It can be used to extend the reflected type and add the following: A function should neither delete nor explicitly invoke the destructor of a given instance. This function requires as an argument the identifier to give to the meta data once created. Users can then access meta data at runtime by searching for them by name. This function requires as an argument the identifier to give to the meta function once created. Users can then access meta functions at runtime by searching for them by name. From now on, wherever a That's all, everything users need to create meta types and enjoy the reflection system. At first glance it may not seem that much, but users usually learn to appreciate it over time. The reflection system comes with its own meta any type. It may seem redundant since C++17 introduced A meta any object provides an API similar to that of its most famous counterpart and serves the same purpose of being an opaque container for any type of value. A meta any object can be created by any other object or as an empty container to initialize later: It takes the burden of destroying the contained instance when required. In this case, the contained instance is never destroyed and users must ensure that the lifetime of the object exceeds that of the container. A meta any object has a Once the web of reflected types has been constructed, it's a matter of using it at runtime where required. To search for a reflected type there are two options: by type or by name. In both cases, the search can be done by means of the There exits also a third overload of the In all cases, the returned value is an instance of The meta objects that compose a meta type are accessed in the following ways: The returned type is The returned type is The returned type is The returned type is The returned type is The returned type is All the objects thus obtained as well as the meta types can be explicitly converted to a boolean value to check if they are valid: Furthermore, all meta objects with the exception of meta destructors can be iterated through an overload that accepts a callback through which to return them. As an example: A meta type can also be used to Meta types and meta objects in general contain much more than what is said: a plethora of functions in addition to those listed whose purposes and uses go unfortunately beyond the scope of this document. Policies are a kind of compile-time directives that can be used when recording reflection information. There are a few alternatives available at the moment: The as-void policy, associated with the type As an example of use: The as-alias policy, associated with the type As an example of use: Some uses are rather trivial, but it's useful to note that there are some less obvious corner cases that can in turn be solved with the use of policies. A special mention should be made for constant values and enums. It wouldn't be necessary, but it will help distracted readers. As mentioned, the All the values thus exported will appear to users as if they were constant data members of the reflected types. Exporting constant values or elements from an enum is as simple as ever: It goes without saying that accessing them is trivial as well. It's a matter of doing the following, as with any other data member of a meta type: As a side note, remember that all this happens behind the scenes without any allocation because of the small object optimization performed by the meta any class. Sometimes (for example, when it comes to creating an editor) it might be useful to be able to attach properties to the meta objects created. Fortunately, this is possible for most of them. The meta objects that support properties offer then a couple of member functions named Meta properties are objects having a fairly poor interface, all in all. They only provide the A type registered with the reflection system can also be unregistered. This means unregistering all its data members, member functions, conversion functions and so on. However, the base classes won't be unregistered, since they don't necessarily depend on it. Similarly, implicitly generated types (as an example, the meta types implicitly generated for function parameters when needed) won't be unregistered. To unregister a type, users can use the This function returns a boolean value that is true if the type is actually registered with the reflection system, false otherwise. The API is straightforward. The basic idea is that services are implemented by means of interfaces and rely on polymorphism. The locator can also be queried to know if an active service is currently set and to retrieve it if necessary (either as a pointer or as a reference): A common use is to wrap the different locators in a container class, creating aliases for the various services: Reflection (or rather, its lack) is a trending topic in the C++ world and, in the specific case of The meta system doesn't force the user to use the tools provided by the library when it comes to working with names and identifiers. It does this by offering an API that works with opaque identifiers that may or may not be generated by means of a hashed string. However, the examples in the following sections are all based on the For what it's worth, this is likely completely equivalent to: Obviously, human-readable identifiers are more convenient to use and highly recommended. Reflection always starts from real types (users cannot reflect imaginary types and it would not make much sense, we wouldn't be talking about reflection anymore). This isn't enough to export the given type and make it visible though. When working with named types, it isn't even necessary to specify the identifier. In fact, it isn't allowed and it will trigger a compilation error. A factory is such that all its member functions returns the factory itself or a decorated version of it. This object can be used to add the following: A function should neither delete nor explicitly invoke the destructor of a given instance. This function requires as an argument the identifier to give to the meta data once created. Users can then access meta data at runtime by searching for them by name. This function requires as an argument the identifier to give to the meta function once created. Users can then access meta functions at runtime by searching for them by name. From now on, wherever a That's all, everything users need to create meta types and enjoy the reflection system. At first glance it may not seem that much, but users usually learn to appreciate it over time. The reflection system comes with its own The class Creating instances of The A particularly interesting feature of this class is that it can also be used as an opaque container for unmanaged objects: In other words, whenever The Once the web of reflected types has been constructed, it's a matter of using it at runtime where required. To search for a reflected type there are two options: by type or by name. In both cases, the search can be done by means of the There exits also a third overload of the In all cases, the returned value is an instance of The meta objects that compose a meta type are accessed in the following ways: The returned type is The returned type is The returned type is The returned type is The returned type is The returned type is All the objects thus obtained as well as the meta types can be explicitly converted to a boolean value to check if they are valid: Furthermore, all meta objects with the exception of meta destructors can be iterated through an overload that accepts a callback through which to return them. As an example: A meta type can also be used to Meta types and meta objects in general contain much more than what is said: a plethora of functions in addition to those listed whose purposes and uses go unfortunately beyond the scope of this document. Policies are a kind of compile-time directives that can be used when recording reflection information. There are a few alternatives available at the moment: The as-void policy, associated with the type As an example of use: The as-alias policy, associated with the type As an example of use: Some uses are rather trivial, but it's useful to note that there are some less obvious corner cases that can in turn be solved with the use of policies. A special mention should be made for constant values and enums. It wouldn't be necessary, but it will help distracted readers. As mentioned, the All the values thus exported will appear to users as if they were constant data members of the reflected types. Exporting constant values or elements from an enum is as simple as ever: It goes without saying that accessing them is trivial as well. It's a matter of doing the following, as with any other data member of a meta type: As a side note, remember that all this happens behind the scenes without any allocation because of the small object optimization performed by the Sometimes (for example, when it comes to creating an editor) it might be useful to attach properties to the meta objects created. Fortunately, this is possible for most of them. Properties are always in the key/value form. There are no restrictions on the type of the key or value, as long as they are copy constructible objects. A tuple contains one or more properties. All of them are treated individually. An annotation is an invocable object that returns one or more properties. All of them are treated individually. It's possible to invoke the Alternatively, the The meta objects for which properties are supported are currently the meta types, meta constructors, meta data and meta functions. It's not possible to attach properties to other types of meta objects and the factory returned as a result of their construction won't allow such an operation. These types offer a couple of member functions named Meta properties are objects having a fairly poor interface, all in all. They only provide the A type registered with the reflection system can also be unregistered. This means unregistering all its data members, member functions, conversion functions and so on. However, the base classes won't be unregistered, since they don't necessarily depend on it. Similarly, implicitly generated types (as an example, the meta types implicitly generated for function parameters when needed) won't be unregistered. The type can be re-registered later with a completely different name and form. Sometimes processes are a useful tool to work around the strict definition of a system and introduce logic in a different way, usually without resorting to the introduction of other components. A typical process must inherit from the A process should expose publicly the following member functions whether required (note that it isn't required to define a function unless the derived class wants to override the default behavior): It's invoked once per tick until a process is explicitly aborted or it terminates either with or without errors. Even though it's not mandatory to declare this member function, as a rule of thumb each process should at least define it to work properly. The It's invoked when the process joins the running queue of a scheduler. This happens as soon as it's attached to the scheduler if the process is a top level one, otherwise when it replaces its parent if the process is a continuation. It's invoked in case of success, immediately after an update and during the same tick. It's invoked in case of errors, immediately after an update and during the same tick. It's invoked only if a process is explicitly aborted. There is no guarantee that it executes in the same tick, this depends solely on whether the process is aborted immediately or not. Derived classes can also change the internal state of a process by invoking Here is a minimal example for the sake of curiosity: Lambdas and functors can't be used directly with a scheduler for they are not properly defined processes with managed life cycles. The function call operator has a signature similar to the one of the Parameters have the following meaning: Both Note that usually users shouldn't worry about creating adaptors at all. A scheduler creates them internally each and every time a lambda or a functor is used as a process. A cooperative scheduler runs different processes and helps managing their life cycles. Each process is invoked once per tick. If it terminates, it's removed automatically from the scheduler and it's never invoked again. Otherwise it's a good candidate to run one more time the next tick. Using a scheduler is straightforward. To create it, users must provide only the type for the elapsed times and no arguments at all: It has member functions to query its internal data structures, like To attach a process to a scheduler there are mainly two ways: In both cases, the return value is an opaque object that offers a To update a scheduler and therefore all its processes, the In addition to these functions, the scheduler offers an
@@ -63,7 +63,7 @@ $(function() {
Generated by
diff --git a/actor_8hpp_source.html b/actor_8hpp_source.html
index 1eee9cdaf..69de4c9e6 100644
--- a/actor_8hpp_source.html
+++ b/actor_8hpp_source.html
@@ -22,7 +22,7 @@
@@ -71,21 +71,21 @@ $(function() {
diff --git a/annotated.html b/annotated.html
index cf2e7ec87..57a497a75 100644
--- a/annotated.html
+++ b/annotated.html
@@ -22,7 +22,7 @@
@@ -73,83 +73,91 @@ $(function() {
Cas_void_t Empty class type used to request the as void policy Cbasic_actor Dedicated to those who aren't confident with the entity-component-system architecture
- Cbasic_collector Collector
+ Cbasic_collector< matcher< matcher< type_list< Reject... >, type_list< Require... > >, Rule... >, Other... > Collector Cbasic_collector< matcher< type_list< Reject... >, type_list< Require... >, Rule... >, Other... > Collector Cbasic_collector<> Collector Cbasic_continuous_loader Utility class for continuous loading
- Cbasic_group Group
- Cbasic_group< Entity, exclude_t< Exclude... >, get_t< Get, Other... > > Non-owning group
+ Cbasic_group< Entity, exclude_t< Exclude... >, get_t< Get... >, Owned, Other... > Owning group
+ Cbasic_group< Entity, exclude_t< Exclude... >, get_t< Get... > > Non-owning group Cbasic_group< Entity, exclude_t< Exclude... >, get_t< Get... >, Owned... > Owning group Cbasic_hashed_string Zero overhead unique identifier
- Cbasic_observer Observer
- Cbasic_prototype
- Cbasic_registry Fast and reliable entity-component system
- Cbasic_runtime_view Runtime view
- Cbasic_snapshot Utility class to create snapshots from a registry
- Cbasic_snapshot_loader Utility class to restore a snapshot as a whole
- Cbasic_storage Basic storage implementation
- Cbasic_storage< Entity, Type, std::enable_if_t< std::is_empty_v< Type > > > Basic storage implementation.
- Cbasic_view Multi component view
- Cbasic_view< Entity, Component > Single component view specialization
- Cconnect_arg_t Used to wrap a function or a member of a specified type
- Cconnection Connection class
- Cdelegate Basic delegate implementation
- Cdelegate< Ret(Args...)> Utility class to use to send around functions and members
- Cdispatcher Basic dispatcher implementation
- ▼Cemitter General purpose event emitter
- Cconnection Generic connection type for events
- Centt_traits Entity traits
- Centt_traits< std::uint16_t > Entity traits for a 16 bits entity identifier
- Centt_traits< std::uint32_t > Entity traits for a 32 bits entity identifier
- Centt_traits< std::uint64_t > Entity traits for a 64 bits entity identifier
- Cexclude_t Alias for exclusion lists
- Cfamily Dynamic identifier generator
- Cget_t Alias for lists of observed components
- Cidentifier Types identifiers
- Cidentity Identity function object (waiting for C++20)
- Cinsertion_sort Function object for performing insertion sort
- Cis_named_type Provides the member constant value to true if a given type has a name. In all other cases, value is false
- Cis_named_type< Type, std::void_t< named_type_traits_t< std::decay_t< Type > > > > Provides the member constant value to true if a given type has a name. In all other cases, value is false
- Cmatcher Grouping matcher
- Cmeta_any Meta any object
- Cmeta_base Meta base object
- Cmeta_conv Meta conversion function object
- Cmeta_ctor Meta constructor object
- Cmeta_data Meta data object
- Cmeta_dtor Meta destructor object
- Cmeta_factory A meta factory to be used for reflection purposes
- Cmeta_func Meta function object
- Cmeta_handle Meta handle object
- Cmeta_prop Meta property object
- Cmeta_type Meta type object
- Cmonostate Minimal implementation of the monostate pattern
- Cnamed_type_traits Traits class used mainly to push things across boundaries
- Cnamed_type_traits< const Type > Specialization used to get rid of constness
- Cprocess Base class for processes
- Cprocess_adaptor Adaptor for lambdas and functors to turn them into processes
- Cradix_sort Function object for performing LSD radix sort
- Cresource_cache Simple cache for resources of a given type
- Cresource_handle Shared resource handle
- Cresource_loader Base class for resource loaders
- Cscheduler Cooperative scheduler for processes
- Cscoped_connection Scoped connection class
- Cservice_locator Service locator, nothing more
- Csigh Unmanaged signal handler
- Csigh< Ret(Args...)> Unmanaged signal handler
- Csink Sink class
- Csink< Ret(Args...)> Sink class
- Csparse_set Basic sparse set implementation
- Cstd_sort Function object to wrap std::sort in a class type
- Cstorage Basic storage implementation.
- Ctype_list A class to use to push around lists of types, nothing more
- Ctype_list_cat Primary template isn't defined on purpose
- Ctype_list_cat< type_list< Type... > > Concatenates multiple type lists
- Ctype_list_cat< type_list< Type... >, type_list< Other... >, List... > Concatenates multiple type lists
- Ctype_list_cat<> Concatenates multiple type lists
- Ctype_list_size Primary template isn't defined on purpose
- Ctype_list_size< type_list< Type... > > Compile-time number of elements in a type list
- Ctype_list_unique Primary template isn't defined on purpose
- Ctype_list_unique< type_list< Type, Other... > > Removes duplicates types from a type list
+ Ctype_list_unique< type_list<> > Removes duplicates types from a type list
+ Cbasic_registry Fast and reliable entity-component system
+ Cbasic_runtime_view Runtime view
+ Cbasic_snapshot Utility class to create snapshots from a registry
+ Cbasic_snapshot_loader Utility class to restore a snapshot as a whole
+ Cbasic_storage Basic storage implementation
+ Cbasic_storage< Entity, Type, std::enable_if_t< ENTT_ENABLE_ETO(Type)> > Basic storage implementation.
+ Cbasic_view View
+ Cbasic_view< Entity, exclude_t< Exclude... >, Component... > Multi component view
+ Cbasic_view< Entity, exclude_t<>, Component > Single component view specialization
+ Ccache Simple cache for resources of a given type
+ Cchoice_t Utility class to disambiguate overloaded functions
+ Cchoice_t< 0 > Utility class to disambiguate overloaded functions.
+ Cconnect_arg_t Used to wrap a function or a member of a specified type
+ Cconnection Connection class
+ Cdelegate Basic delegate implementation
+ Cdelegate< Ret(Args...)> Utility class to use to send around functions and members
+ Cdispatcher Basic dispatcher implementation
+ ▼Cemitter General purpose event emitter
+ Cconnection Generic connection type for events
+ Centt_traits Entity traits
+ Centt_traits< std::uint16_t > Entity traits for a 16 bits entity identifier
+ Centt_traits< std::uint32_t > Entity traits for a 32 bits entity identifier
+ Centt_traits< std::uint64_t > Entity traits for a 64 bits entity identifier
+ Cexclude_t Alias for exclusion lists
+ Cextended_meta_factory Extended meta factory to be used for reflection purposes
+ Cfamily Dynamic identifier generator
+ Cget_t Alias for lists of observed components
+ Chandle Shared resource handle
+ Cidentifier Types identifiers
+ Cidentity Identity function object (waiting for C++20)
+ Cinsertion_sort Function object for performing insertion sort
+ Cis_equality_comparable Provides the member constant value to true if a given type is equality comparable, false otherwise
+ Cis_equality_comparable< Type, std::void_t< decltype(std::declval< Type >()==std::declval< Type >())> > Provides the member constant value to true if a given type is equality comparable, false otherwise.
+ Cis_named_type Provides the member constant value to true if a given type has a name. In all other cases, value is false
+ Cis_named_type< Type, std::void_t< named_type_traits_t< std::decay_t< Type > > > > Provides the member constant value to true if a given type has a name. In all other cases, value is false.
+ Cloader Base class for resource loaders
+ Cmatcher Grouping matcher
+ Cmeta_any Opaque container for values of any type
+ Cmeta_base Opaque container for meta base classes
+ Cmeta_conv Opaque container for meta conversion functions
+ Cmeta_ctor Opaque container for meta constructors
+ Cmeta_ctx Opaque container for a meta context
+ Cmeta_data Opaque container for meta data
+ Cmeta_dtor Opaque container for meta destructors
+ Cmeta_factory A meta factory to be used for reflection purposes
+ Cmeta_func Opaque container for meta functions
+ Cmeta_handle Opaque pointers to instances of any type
+ Cmeta_prop Opaque container for meta properties of any type
+ Cmeta_type Opaque container for meta types
+ Cmonostate Minimal implementation of the monostate pattern
+ Cnamed_type_traits Traits class used mainly to push things across boundaries
+ Cnamed_type_traits< const Type > Specialization used to get rid of constness
+ Coverloaded Helper type for visitors
+ Cprocess Base class for processes
+ Cprocess_adaptor Adaptor for lambdas and functors to turn them into processes
+ Cradix_sort Function object for performing LSD radix sort
+ Cscheduler Cooperative scheduler for processes
+ Cscoped_connection Scoped connection class
+ Cservice_locator Service locator, nothing more
+ Csigh Unmanaged signal handler
+ Csigh< Ret(Args...)> Unmanaged signal handler
+ Csink Sink class
+ Csink< Ret(Args...)> Sink class
+ Csparse_set Basic sparse set implementation
+ Cstd_sort Function object to wrap std::sort in a class type
+ Cstorage Basic storage implementation.
+ Ctype_list A class to use to push around lists of types, nothing more
+ Ctype_list_cat Primary template isn't defined on purpose
+ Ctype_list_cat< type_list< Type... > > Concatenates multiple type lists
+ Ctype_list_cat< type_list< Type... >, type_list< Other... >, List... > Concatenates multiple type lists
+ Ctype_list_cat<> Concatenates multiple type lists
+ Ctype_list_size Primary template isn't defined on purpose
+ Ctype_list_size< type_list< Type... > > Compile-time number of elements in a type list
+ Ctype_list_unique Primary template isn't defined on purpose
+ Ctype_list_unique< type_list< Type, Other... > > Removes duplicates types from a type list
+ Ctype_list_unique< type_list<> > Removes duplicates types from a type list
diff --git a/autotoc_md0.html b/autotoc_md0.html
index f4dc9708b..dc88e230c 100644
--- a/autotoc_md0.html
+++ b/autotoc_md0.html
@@ -22,7 +22,7 @@
Cy_combinator Basic implementation of a y-combinator
diff --git a/autotoc_md48.html b/autotoc_md48.html
deleted file mode 100644
index 3d7b00f7b..000000000
--- a/autotoc_md48.html
+++ /dev/null
@@ -1,126 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Introduction
-
- If you don't find your answer here, there are two cases: nobody has done it yet or this section needs updating. In both cases, try to open a new issue or enter the gitter channel and ask your question. Probably someone already has an answer for you and we can then integrate this part of the documentation.
-FAQ
-
-Why is my debug build on Windows so slow?
-EnTT is an experimental project that I also use to keep me up-to-date with the latest revision of the language and the standard library. For this reason, it's likely that some classes you're working with are using standard containers under the hood.
- Unfortunately, it's known that the standard containers aren't particularly performing in debugging (the reasons for this go beyond this document) and are even less so on Windows apparently. Fortunately this can also be mitigated a lot, achieving good results in many cases.
-
-/JMC option (Just My Code debugging), available starting in Visual Studio 2017 version 15.8._ITERATOR_DEBUG_LEVEL macro to 0. This will disable checked iterators and iterator debugging.ENTT_DISABLE_ASSERT should be defined to disable internal checks made by EnTT in debug. These are asserts introduced to help the users, but require to access to the underlying containers and therefore risk ruining the performance in some cases.O0 or preferably O1.
-How can I represent hierarchies with my components?
-
- There are several approaches to the problem and what’s the best one depends mainly on the real problem one is facing. In all cases, how to do it doesn't strictly depend on the library in use, but the latter can certainly allow or not different techniques depending on how the data are laid out.EnTT. Here is the first post of a series that tries to explore the problem. More will probably come in future.EnTT, the groups and all the other features of the library can help then to get the best in terms of data locality and therefore performance from this component.
-Custom entity identifiers: yay or nay?
-
-
-std::uint32_t isn't large enough as an underlying type.
- To simplify the creation of new identifiers, EnTT provides the macro ENTT_ENTITY_TYPE that accepts two arguments:
-
-std::uint16_t, std::uint32_t or std::uint64_t).entt::entity:
-Warning C4307: integral constant overflow
-
- First of all, I want to reassure you: it's expected and harmless. However, it can be annoying.
-Warning C4003: the min, the max and the macro
-min and max which may result in conflicts with their counterparts in the standard library and therefore in errors during compilation.EnTT and there is a fairly simple solution to it.
- It consists in defining the NOMINMAX macro before to include any other header so as to get rid of the extra definitions:
-Generated by
-
- 1.8.13
-
-
-
diff --git a/autotoc_md49.html b/autotoc_md50.html
similarity index 83%
rename from autotoc_md49.html
rename to autotoc_md50.html
index c242341db..98d6a3066 100644
--- a/autotoc_md49.html
+++ b/autotoc_md50.html
@@ -22,7 +22,7 @@
@@ -63,13 +63,13 @@ $(function() {
+
Introduction
If you don't find your answer here, there are two cases: nobody has done it yet or this section needs updating. In both cases, try to open a new issue or enter the gitter channel and ask your question. Probably someone already has an answer for you and we can then integrate this part of the documentation.
+
FAQ
-
+
Why is my debug build on Windows so slow?
EnTT is an experimental project that I also use to keep me up-to-date with the latest revision of the language and the standard library. For this reason, it's likely that some classes you're working with are using standard containers under the hood.
Unfortunately, it's known that the standard containers aren't particularly performing in debugging (the reasons for this go beyond this document) and are even less so on Windows apparently. Fortunately this can also be mitigated a lot, achieving good results in many cases.ENTT_DISABLE_ASSERT should be defined to disable internal checks made by EnTT in debug. These are asserts introduced to help the users, but require to access to the underlying containers and therefore risk ruining the performance in some cases.O0 or preferably O1.
+
How can I represent hierarchies with my components?
There are several approaches to the problem and what’s the best one depends mainly on the real problem one is facing. In all cases, how to do it doesn't strictly depend on the library in use, but the latter can certainly allow or not different techniques depending on how the data are laid out.EnTT. Here is the first post of a series that tries to explore the problem. More will probably come in future.EnTT, the groups and all the other features of the library can help then to get the best in terms of data locality and therefore performance from this component.
+
Custom entity identifiers: yay or nay?
@@ -102,19 +102,27 @@ Custom entity identifiers: yay or nay?
entt::entity:
+
Warning C4307: integral constant overflow
First of all, I want to reassure you: it's expected and harmless. However, it can be annoying.
+
Warning C4003: the min, the max and the macro
min and max which may result in conflicts with their counterparts in the standard library and therefore in errors during compilation.EnTT and there is a fairly simple solution to it.
It consists in defining the NOMINMAX macro before to include any other header so as to get rid of the extra definitions:
+The standard and the non-copyable types
+EnTT uses internally the trait std::is_copy_constructible_v to check if a component is actually copyable. This trait doesn't check if an object can actually be copied but only verifies if there is a copy constructor available.
+ This can lead to surprising results due to some idiosyncrasies of the standard mainly related to the need to guarantee backward compatibility.std::vector defines a copy constructor no matter if its value type is copyable or not. As a result, std::is_copy_constructible_v is true for the following specialization:
+ As a workaround, users can mark the type explicitly as non-copyable:
diff --git a/autotoc_md56.html b/autotoc_md56.html
deleted file mode 100644
index 4c636b7a7..000000000
--- a/autotoc_md56.html
+++ /dev/null
@@ -1,116 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Introduction
-EnTT has historically had a limit when used across boundaries on Windows in general and on GNU/Linux when default visibility was set to hidden. The limitation is due mainly to a custom utility used to assign unique, sequential identifiers to different types. Unfortunately, this tool is used by several core classes (the registry among the others) that are thus almost unusable across boundaries.
- The reasons for that are beyond the purposes of this document. However, the good news is that EnTT also offers now a way to overcome this limit and to push things across boundaries without problems when needed.
-Named types and traits class
-
- The name of the class template is name_type_traits and the specialization must be such that it exposes a static constexpr data member named value having type either ENTT_ID_TYPE or entt::hashed_string::hash_type. Its value is the user defined unique identifier assigned to the specific type.
- Identifiers are not to be sequentially generated in this case.entt namespace. There is no way to change this rule unfortunately, because it doesn't depend on the library itself.
- However, despite the fact that it's not intrusive, it would be great if it was also easier to use and a bit less error-prone. This is why a bunch of macros exist to ease defining named types.
-Do not mix types
-
- As a rule of thumb, users should never mix named and non-named types. Whenever a type is given a name, all the types must be given a name. As an example, consider the registry class template: in case it is pushed across boundaries, all the types of components should be assigned a name to avoid subtle bugs.
-Macros, macros everywhere
-
-
-ENTT_NAMED_TYPE can be used to assign a name to already existing types. This macro must be used in the global namespace even when the types to be named are not.
-
-ENTT_NAMED_STRUCT can be used to define and export a struct at the same time. It accepts also an optional namespace in which to define the given type. This macro must be used in the global namespace.
-
-ENTT_NAMED_CLASS can be used to define and export a class at the same time. It accepts also an optional namespace in which to define the given type. This macro must be used in the global namespace.named_type_traits class template. In all cases, the name of the class is used also as a seed to generate the compile-time unique identifier.
-Conflicts
-
- Unfortunately, there is no safe way to prevent it. If this happens, it will be enough to give a different value to one of the conflicting types to solve the problem. To do this, users can either assign a different name to the class or directly define a specialization for the named_type_traits class template.
-Allocations: the dark side of the force
-EnTT won't support custom allocators, another problem with allocations will remain alive instead. This is in fact easily solved, or at least it is if one knows it.
- To avoid problems, the pools must be generated from the same side of the boundary where the object that owns them is also created. As an example, when the registry is created in the main executable and used across boundaries for a given type of component, the pool for that type must be created before passing around the registry itself. To do this is fortunately quite easy, since it is sufficient to invoke any of the methods that involve the given type (continuing the example with the registry, a call to reserve or size is more than enough).
-Generated by
-
- 1.8.13
-
-
-
diff --git a/autotoc_md57.html b/autotoc_md59.html
similarity index 84%
rename from autotoc_md57.html
rename to autotoc_md59.html
index f9f2e3b4b..165e6a7cb 100644
--- a/autotoc_md57.html
+++ b/autotoc_md59.html
@@ -22,7 +22,7 @@
@@ -63,11 +63,11 @@ $(function() {
+
Introduction
EnTT has historically had a limit when used across boundaries on Windows in general and on GNU/Linux when default visibility was set to hidden. The limitation is due mainly to a custom utility used to assign unique, sequential identifiers to different types. Unfortunately, this tool is used by several core classes (the registry among the others) that are thus almost unusable across boundaries.
The reasons for that are beyond the purposes of this document. However, the good news is that EnTT also offers now a way to overcome this limit and to push things across boundaries without problems when needed.
+
Named types and traits class
The name of the class template is name_type_traits and the specialization must be such that it exposes a static constexpr data member named value having type either ENTT_ID_TYPE or entt::hashed_string::hash_type. Its value is the user defined unique identifier assigned to the specific type.
@@ -76,12 +76,12 @@ Named types and traits class
entt namespace. There is no way to change this rule unfortunately, because it doesn't depend on the library itself.
However, despite the fact that it's not intrusive, it would be great if it was also easier to use and a bit less error-prone. This is why a bunch of macros exist to ease defining named types.
+
Do not mix types
As a rule of thumb, users should never mix named and non-named types. Whenever a type is given a name, all the types must be given a name. As an example, consider the registry class template: in case it is pushed across boundaries, all the types of components should be assigned a name to avoid subtle bugs.
+
Macros, macros everywhere
@@ -95,11 +95,22 @@ Macros, macros everywhere
named_type_traits class template. In all cases, the name of the class is used also as a seed to generate the compile-time unique identifier.
+
Conflicts
Unfortunately, there is no safe way to prevent it. If this happens, it will be enough to give a different value to one of the conflicting types to solve the problem. To do this, users can either assign a different name to the class or directly define a specialization for the named_type_traits class template.
+
+Runtime reflection system
+
+ As in all other cases, it's necessary to give a name to the types. However, this time this isn't enough to get the job done.
+ Different contexts don't relate to each other. Therefore, to allow the use of named types across boundaries, a context must also be shared.
Allocations: the dark side of the force
EnTT won't support custom allocators, another problem with allocations will remain alive instead. This is in fact easily solved, or at least it is if one knows it.
diff --git a/autotoc_md63.html b/autotoc_md63.html
deleted file mode 100644
index 82cb744c0..000000000
--- a/autotoc_md63.html
+++ /dev/null
@@ -1,122 +0,0 @@
-
-
-
-
-
-
-
-
-
-
- EnTT is widely used in private and commercial applications. I cannot even mention most of them because of some signatures I put on some documents time ago. Fortunately, there are also people who took the time to implement open source projects based on EnTT and did not hold back when it came to documenting them.EnTT is documented but the authors didn't make explicit announcements or contacted me directly.
-
-
-
-EnTT.EnTT.SFML and EnTT playground.SDL and EnTT.SDL2 and EnTT libraries.SDL2 and EnTT libraries.
-
-Allegro, Lua and modern C++.
-
-
-
-EnTT, for those who want to know more on this project.UE4.UE4 and EnTT.SFML, EnTT, Conan and CMake.
-
-EnTT for the internal ECS and the cross platform C++ rendering engine. The SDKs are utilized by a lot of enterprise custom apps, as well as by Esri for its own public applications such as Explorer, Collector and Navigator.EnTT, at the time used for internal projects.Entitas-CSharp.EnTT from which to take inspiration if interested.EnTT, feel free to open an issue or a PR and I'll be glad to add them to this page.
-Generated by
-
- 1.8.13
-
-
-
diff --git a/autotoc_md64.html b/autotoc_md64.html
deleted file mode 100644
index 5404fc2ce..000000000
--- a/autotoc_md64.html
+++ /dev/null
@@ -1,121 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- EnTT is widely used in private and commercial applications. I cannot even mention most of them because of some signatures I put on some documents time ago. Fortunately, there are also people who took the time to implement open source projects based on EnTT and did not hold back when it came to documenting them.EnTT is documented but the authors didn't make explicit announcements or contacted me directly.
-
-
-
-EnTT.EnTT.SFML and EnTT playground.SDL and EnTT.SDL2 and EnTT libraries.SDL2 and EnTT libraries.
-
-Allegro, Lua and modern C++.EnTT that uses ImGui as graphical backend (with demo code).
-
-EnTT, for those who want to know more on this project.UE4.UE4 and EnTT.SFML, EnTT, Conan and CMake.
-
-EnTT for the internal ECS and the cross platform C++ rendering engine. The SDKs are utilized by a lot of enterprise custom apps, as well as by Esri for its own public applications such as Explorer, Collector and Navigator.EnTT, at the time used for internal projects.EnTT was listed on their software stack.Entitas-CSharp.EnTT from which to take inspiration if interested.EnTT, feel free to open an issue or a PR and I'll be glad to add them to this page.
-Generated by
-
- 1.8.13
-
-
-
diff --git a/autotoc_md65.html b/autotoc_md65.html
deleted file mode 100644
index 940f4bb37..000000000
--- a/autotoc_md65.html
+++ /dev/null
@@ -1,84 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Introduction
-
- This class is tiny, partially unsafe and thus risky to use. Moreover it doesn't fit probably most of the scenarios in which a service locator is required. Look at it as a small tool that can sometimes be useful if users know how to handle it.
-Service locator
-
- The locator is instantiated with the base type of the service if any and a concrete implementation is provided along with all the parameters required to initialize it. As an example:
-Generated by
-
- 1.8.13
-
-
-
diff --git a/autotoc_md67.html b/autotoc_md67.html
index e3fa717e9..a90f2c61e 100644
--- a/autotoc_md67.html
+++ b/autotoc_md67.html
@@ -5,7 +5,7 @@
-
@@ -60,161 +60,62 @@ $(function() {
-Introduction
-EnTT, a tool that can unlock a lot of other features. I looked for a third-party library that met my needs on the subject, but I always came across some details that I didn't like: macros, being intrusive, too many allocations. In one word: unsatisfactory.
- I finally decided to write a built-in, non-intrusive and macro-free runtime reflection system for EnTT. Maybe I didn't do better than others or maybe yes, time will tell me, but at least I can model this tool around the library to which it belongs and not vice versa.
-Names and identifiers
-
- This means that users can assign any type of identifier to the meta objects, as long as they are numeric. It doesn't matter if they are generated at runtime, at compile-time or with custom functions.hashed_string class as provided by this library. Therefore, where an identifier is required, it's likely that a user defined literal is used as follows:
-Reflection in a nutshell
-
- To reflect a type, the library provides the reflect function:
- In both cases, the returned value is a factory object to use to continue building the meta type.EnTT is widely used in private and commercial applications. I cannot even mention most of them because of some signatures I put on some documents time ago. Fortunately, there are also people who took the time to implement open source projects based on EnTT and did not hold back when it came to documenting them.EnTT is documented but the authors didn't make explicit announcements or contacted me directly.
-
- Use the ctor member function for this purpose:
+
-EnTT.EnTT.SFML and EnTT playground.SDL and EnTT.SDL2 and EnTT libraries.SDL2 and EnTT libraries.
-
- Use the dtor member function for this purpose:
+
-Allegro, Lua and modern C++.EnTT that uses ImGui as graphical backend (with demo code).
-
- Use the data member function for this purpose:
+
-EnTT, for those who want to know more on this project.UE4.UE4 and EnTT.SFML, EnTT, Conan and CMake.
- Data members can be set also by means of a couple of functions, namely a setter and a getter. Setters and getters can be either free functions, member functions or mixed ones, as long as they respect the required signatures.
- Refer to the inline documentation for all the details.
-
- Use the func member function for this purpose:
+
-EnTT for the internal ECS and the cross platform C++ rendering engine. The SDKs are utilized by a lot of enterprise custom apps, as well as by Esri for its own public applications such as Explorer, Collector and Navigator.EnTT, at the time used for internal projects.EnTT was listed on their software stack.EnTT within Godot.EnTT and GameNetworkingSockets within Godot.Entitas-CSharp.EnTT from which to take inspiration if interested.
-
-
- Use the base member function for this purpose:base_type is required, an instance of derived_type will also be accepted.
-
-double and an int to see it. Similar to bases, conversion functions allow users to define conversions that will be implicitly performed by the reflection system when required.
- Use the conv member function for this purpose:
- Also, do not forget what these few lines hide under the hood: a built-in, non-intrusive and macro-free system for reflection in C++. Features that are definitely worth the price, at least for me.
-Any as in any type
-std::any, but it is not.
- In fact, the type returned by an std::any is a const reference to an std::type_info, an implementation defined class that's not something everyone wants to see in a software. Furthermore, the class std::type_info suffers from some design flaws and there is even no way to convert an std::type_info into a meta type, thus linking the two worlds.
- It minimizes the allocations required, which are almost absent thanks to SBO techniques. In fact, unless users deal with fat types and create instances of them though the reflection system, allocations are at zero.
- Moreover, it can be used as an opaque container for unmanaged objects if needed:type member function that returns the meta type of the contained value, if any. The member functions try_cast, cast and convert are used to know if the underlying object has a given type as a base or if it can be converted implicitly to it.
-Enjoy the runtime
-
- All this has the great merit that, unlike the vast majority of the things present in this library and closely linked to the compile-time, the reflection system stands in fact as a non-intrusive tool for the runtime.resolve function:resolve function to use to iterate all the reflected types at once:meta_type. This type of objects offer an API to know the runtime identifier of the type, to iterate all the meta objects associated with them and even to build or destroy instances of the underlying type.
- Refer to the inline documentation for all the details.
-
-meta_ctor and may be invalid if there is no constructor that accepts the supplied arguments or at least some types from which they are derived or to which they can be converted.
- A meta constructor offers an API to know the number of arguments, the expected meta types and to invoke it, therefore to construct a new instance of the underlying type.
-
-meta_dtor and may be invalid if there is no custom destructor set for the given meta type.
- All what a meta destructor has to offer is a way to invoke it on a given instance. Be aware that the result may not be what is expected.
-
-meta_data and may be invalid if there is no meta data object associated with the given identifier.
- A meta data object offers an API to query the underlying type (ie to know if it's a const or a static one), to get the meta type of the variable and to set or get the contained value.
-
-meta_func and may be invalid if there is no meta function object associated with the given identifier.
- A meta function object offers an API to query the underlying type (ie to know if it's a const or a static function), to know the number of arguments, the meta return type and the meta types of the parameters. In addition, a meta function object can be used to invoke the underlying function and then get the return value in the form of meta any object.
-
-meta_base and may be invalid if there is no meta base object associated with the given identifier.
- Meta bases aren't meant to be used directly, even though they are freely accessible. They expose only a few methods to use to know the meta type of the base class and to convert a raw pointer between types.
-
-meta_conv and may be invalid if there is no meta conversion function associated with the given type.
- The meta conversion functions are as thin as the meta bases and with a very similar interface. The sole difference is that they return a newly created instance wrapped in a meta any object when they convert between different types.construct or destroy actual instances of the underlying type.
- In particular, the construct member function accepts a variable number of arguments and searches for a match. It returns a meta_any object that may or may not be initialized, depending on whether a suitable constructor has been found or not. On the other side, the destroy member function accepts instances of meta_any as well as actual objects by reference and invokes the registered destructor if any.
- Be aware that the result of a call to destroy may not be what is expected. The purpose is to give users the ability to free up resources that require special treatment and not to actually destroy instances.
- I invite anyone interested in the subject to look at the code, experiment and read the official documentation to get the best out of this powerful tool.
-Policies: the more, the less
-
- Their purpose is to require slightly different behavior than the default in some specific cases. For example, when reading a given data member, its value is returned wrapped in a meta_any object which, by default, makes a copy of it. For large objects or if the caller wants to access the original instance, this behavior isn't desirable. Policies are there to offer a solution to this and other problems.
-
-entt::as_is_t.
- This is the default policy. In general, it should never be used explicitly, since it's implicitly selected if no other policy is specified.
- In this case, the return values of the functions as well as the properties exposed as data members are always returned by copy in a dedicated wrapper and therefore associated with their original meta types.entt::as_void_t.
- Its purpose is to discard the return value of a meta object, whatever it is, thus making it appear as if its type were void.
- If the use with functions is obvious, it must be said that it's also possible to use this policy with constructors and data members. In the first case, the constructor will be invoked but the returned wrapper will actually be empty. In the second case, instead, the property will not be accessible for reading.
-
-entt::as_alias_t
- It allows to build wrappers that act as aliases for the objects used to initialize them. Modifying the object contained in the wrapper for which the aliasing was requested will make it possible to directly modify the instance used to initialize the wrapper itself.
- This policy works with constructors (for example, when objects are taken from an external container rather than created on demand), data members and functions in general (as long as their return types are lvalue references).
-Named constants and enums
-data member function can be used to reflect constants of any type among the other things.
- This allows users to create meta types for enums that will work exactly like any other meta type built from a class. Similarly, arithmetic types can be enriched with constants of special meaning where required.
- Personally, I find it very useful not to export what is the difference between enums and classes in C++ directly in the space of the reflected types.
-Properties and meta objects
-
- To attach a property to a meta object, no matter what as long as it supports properties, it is sufficient to provide an object at the time of construction such that std::get<0> and std::get<1> are valid for it. In other terms, the properties are nothing more than key/value pairs users can put in an std::pair. As an example:prop to iterate them at once and to search a specific property by key:key and the value member functions to be used to retrieve the key and the value contained in the form of meta any objects, respectively.
-Unregister types
-unregister function from the global namespace:
- The type can be re-registered later with a completely different name and form. EnTT, feel free to open an issue or a PR and I'll be glad to add them to this page.
diff --git a/autotoc_md68.html b/autotoc_md68.html
index f4b5b6f7c..87387004e 100644
--- a/autotoc_md68.html
+++ b/autotoc_md68.html
@@ -5,7 +5,7 @@
-
@@ -60,162 +60,20 @@ $(function() {
Introduction
-EnTT, a tool that can unlock a lot of other features. I looked for a third-party library that met my needs on the subject, but I always came across some details that I didn't like: macros, being intrusive, too many allocations. In one word: unsatisfactory.
- I finally decided to write a built-in, non-intrusive and macro-free runtime reflection system for EnTT. Maybe I didn't do better than others or maybe yes, time will tell me, but at least I can model this tool around the library to which it belongs and not vice versa.
+ This class is tiny, partially unsafe and thus risky to use. Moreover it doesn't fit probably most of the scenarios in which a service locator is required. Look at it as a small tool that can sometimes be useful if users know how to handle it.
-Names and identifiers
-
- This means that users can assign any type of identifier to the meta objects, as long as they are numeric. It doesn't matter if they are generated at runtime, at compile-time or with custom functions.hashed_string class as provided by this library. Therefore, where an identifier is required, it's likely that a user defined literal is used as follows:
-Reflection in a nutshell
-
- To reflect a type, the library provides the reflect function:
- In both cases, the returned value is a factory object to use to continue building the meta type.
-
-
- Use the ctor member function for this purpose:
-
-
- Use the dtor member function for this purpose:
-
-
- Use the data member function for this purpose:
- Data members can be set also by means of a couple of functions, namely a setter and a getter. Setters and getters can be either free functions, member functions or mixed ones, as long as they respect the required signatures.
- Refer to the inline documentation for all the details.
-
-
- Use the func member function for this purpose:
-
-
- Use the base member function for this purpose:base_type is required, an instance of derived_type will also be accepted.
-
-double and an int to see it. Similar to bases, conversion functions allow users to define conversions that will be implicitly performed by the reflection system when required.
- Use the conv member function for this purpose:
- Also, do not forget what these few lines hide under the hood: a built-in, non-intrusive and macro-free system for reflection in C++. Features that are definitely worth the price, at least for me.
-Any as in any type
-std::any, but it is not.
- In fact, the type returned by an std::any is a const reference to an std::type_info, an implementation defined class that's not something everyone wants to see in a software. Furthermore, the class std::type_info suffers from some design flaws and there is even no way to convert an std::type_info into a meta type, thus linking the two worlds.
- It minimizes the allocations required, which are almost absent thanks to SBO techniques. In fact, unless users deal with fat types and create instances of them though the reflection system, allocations are at zero.
- Moreover, it can be used as an opaque container for unmanaged objects if needed:type member function that returns the meta type of the contained value, if any. The member functions try_cast, cast and convert are used to know if the underlying object has a given type as a base or if it can be converted implicitly to it.
-Enjoy the runtime
-
- All this has the great merit that, unlike the vast majority of the things present in this library and closely linked to the compile-time, the reflection system stands in fact as a non-intrusive tool for the runtime.resolve function:resolve function to use to iterate all the reflected types at once:meta_type. This type of objects offer an API to know the runtime identifier of the type, to iterate all the meta objects associated with them and even to build or destroy instances of the underlying type.
- Refer to the inline documentation for all the details.
-
-meta_ctor and may be invalid if there is no constructor that accepts the supplied arguments or at least some types from which they are derived or to which they can be converted.
- A meta constructor offers an API to know the number of arguments, the expected meta types and to invoke it, therefore to construct a new instance of the underlying type.
-
-meta_dtor and may be invalid if there is no custom destructor set for the given meta type.
- All what a meta destructor has to offer is a way to invoke it on a given instance. Be aware that the result may not be what is expected.
-
-meta_data and may be invalid if there is no meta data object associated with the given identifier.
- A meta data object offers an API to query the underlying type (ie to know if it's a const or a static one), to get the meta type of the variable and to set or get the contained value.
-
-meta_func and may be invalid if there is no meta function object associated with the given identifier.
- A meta function object offers an API to query the underlying type (ie to know if it's a const or a static function), to know the number of arguments, the meta return type and the meta types of the parameters. In addition, a meta function object can be used to invoke the underlying function and then get the return value in the form of meta any object.
-
-meta_base and may be invalid if there is no meta base object associated with the given identifier.
- Meta bases aren't meant to be used directly, even though they are freely accessible. They expose only a few methods to use to know the meta type of the base class and to convert a raw pointer between types.
-
-meta_conv and may be invalid if there is no meta conversion function associated with the given type.
- The meta conversion functions are as thin as the meta bases and with a very similar interface. The sole difference is that they return a newly created instance wrapped in a meta any object when they convert between different types.construct or destroy actual instances of the underlying type.
- In particular, the construct member function accepts a variable number of arguments and searches for a match. It returns a meta_any object that may or may not be initialized, depending on whether a suitable constructor has been found or not. On the other side, the destroy member function accepts instances of meta_any as well as actual objects by reference and invokes the registered destructor if any.
- Be aware that the result of a call to destroy may not be what is expected. The purpose is to give users the ability to free up resources that require special treatment and not to actually destroy instances.
- I invite anyone interested in the subject to look at the code, experiment and read the official documentation to get the best out of this powerful tool.
-Policies: the more, the less
-
- Their purpose is to require slightly different behavior than the default in some specific cases. For example, when reading a given data member, its value is returned wrapped in a meta_any object which, by default, makes a copy of it. For large objects or if the caller wants to access the original instance, this behavior isn't desirable. Policies are there to offer a solution to this and other problems.
-
-entt::as_is_t.
- This is the default policy. In general, it should never be used explicitly, since it's implicitly selected if no other policy is specified.
- In this case, the return values of the functions as well as the properties exposed as data members are always returned by copy in a dedicated wrapper and therefore associated with their original meta types.entt::as_void_t.
- Its purpose is to discard the return value of a meta object, whatever it is, thus making it appear as if its type were void.
- If the use with functions is obvious, it must be said that it's also possible to use this policy with constructors and data members. In the first case, the constructor will be invoked but the returned wrapper will actually be empty. In the second case, instead, the property will not be accessible for reading.
-
-entt::as_alias_t.
- It allows to build wrappers that act as aliases for the objects used to initialize them. Modifying the object contained in the wrapper for which the aliasing was requested will make it possible to directly modify the instance used to initialize the wrapper itself.
- This policy works with constructors (for example, when objects are taken from an external container rather than created on demand), data members and functions in general (as long as their return types are lvalue references).
-Named constants and enums
-data member function can be used to reflect constants of any type among the other things.
- This allows users to create meta types for enums that will work exactly like any other meta type built from a class. Similarly, arithmetic types can be enriched with constants of special meaning where required.
- Personally, I find it very useful not to export what is the difference between enums and classes in C++ directly in the space of the reflected types.
-Properties and meta objects
-
- To attach a property to a meta object, no matter what as long as it supports properties, it is sufficient to provide an object at the time of construction such that std::get<0> and std::get<1> are valid for it. In other terms, the properties are nothing more than key/value pairs users can put in an std::pair. As an example:prop to iterate them at once and to search a specific property by key:key and the value member functions to be used to retrieve the key and the value contained in the form of meta any objects, respectively.
-Unregister types
-unregister function from the global namespace:
- The type can be re-registered later with a completely different name and form.
+ The locator is instantiated with the base type of the service if any and a concrete implementation is provided along with all the parameters required to initialize it. As an example:
Generated by
diff --git a/autotoc_md71.html b/autotoc_md71.html
new file mode 100644
index 000000000..6b2247c78
--- /dev/null
+++ b/autotoc_md71.html
@@ -0,0 +1,251 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Introduction
+EnTT, a tool that can unlock a lot of other features. I looked for a third-party library that met my needs on the subject, but I always came across some details that I didn't like: macros, being intrusive, too many allocations. In one word: unsatisfactory.
+ I finally decided to write a built-in, non-intrusive and macro-free runtime reflection system for EnTT. Maybe I didn't do better than others or maybe yes, time will tell me, but at least I can model this tool around the library to which it belongs and not vice versa.
+Names and identifiers
+
+ This means that users can assign any type of identifier to the meta objects, as long as they are numeric. It doesn't matter if they are generated at runtime, at compile-time or with custom functions.hashed_string class as provided by this library. Therefore, where an identifier is required, it's likely that a user defined literal is used as follows:
+Reflection in a nutshell
+
+ To create a meta node, the library provides the meta function that accepts a type to reflect as a template parameter:
+ The returned value is a factory object to use to continue building the meta type. In order to make the type visible, users can assign it an identifier:
+ Identifiers are important because users can retrieve meta types at runtime by searching for them by name other than by type. On the other hand, there are cases in which users can be interested in adding features to a reflected type so that the reflection system can use it correctly under the hood, but they don't want to allow searching the type by name. In this case, it's sufficient not to invoke type and the type will not be searchable by name.
+
+
+ Use the ctor member function for this purpose:
+
+
+ Use the dtor member function for this purpose:
+
+
+ Use the data member function for this purpose:
+ Data members can be set also by means of a couple of functions, namely a setter and a getter. Setters and getters can be either free functions, member functions or mixed ones, as long as they respect the required signatures.
+ Refer to the inline documentation for all the details.
+
+
+ Use the func member function for this purpose:
+
+
+ Use the base member function for this purpose:base_type is required, an instance of derived_type will also be accepted.
+
+double and an int to see it. Similar to bases, conversion functions allow users to define conversions that will be implicitly performed by the reflection system when required.
+ Use the conv member function for this purpose:
+ Also, do not forget what these few lines hide under the hood: a built-in, non-intrusive and macro-free system for reflection in C++. Features that are definitely worth the price, at least for me.
+Any as in any type
+meta_any type. It may seem redundant since C++17 introduced std::any, but it is not.
+ In fact, the type returned by an std::any is a const reference to an std::type_info, an implementation defined class that's not something everyone wants to see in a software. Furthermore, the class std::type_info suffers from some design flaws and there is even no way to convert an std::type_info into a meta type, thus linking the two worlds.meta_any offers an API similar to that of its most famous counterpart and serves the same purpose of being an opaque container for any type of value.
+ It minimizes the allocations required, which are almost absent thanks to SBO techniques. In fact, unless users deal with fat types and create instances of them through the reflection system, allocations are at zero.meta_any, whether empty or from existing objects, is trivial:meta_any class takes also the burden of destroying the contained object when required.
+ Furthermore, an instance of meta_any is not tied to a specific type. Therefore, the wrapper will be reconfigured by assigning it an object of a different type than the one contained, so as to be able to handle the new instance.meta_any intercepts a reference_wrapper, it acts as a reference to the original instance rather than making a copy of it. The contained object is never destroyed and users must ensure that its lifetime exceeds that of the container.meta_any class has also a type member function that returns the meta type of the contained value, if any. The member functions try_cast, cast and convert are used to know if the underlying object has a given type as a base or if it can be converted implicitly to it.
+Enjoy the runtime
+
+ All this has the great merit that, unlike the vast majority of the things present in this library and closely linked to the compile-time, the reflection system stands in fact as a non-intrusive tool for the runtime.resolve function:resolve function to use to iterate all the reflected types at once:meta_type. This kind of objects offer an API to know their runtime identifiers, to iterate all the meta objects associated with them and even to build or destroy instances of the underlying type.
+ Refer to the inline documentation for all the details.
+
+meta_ctor and may be invalid if there is no constructor that accepts the supplied arguments or at least some types from which they are derived or to which they can be converted.
+ A meta constructor offers an API to know the number of arguments, the expected meta types and to invoke it, therefore to construct a new instance of the underlying type.
+
+meta_dtor and may be invalid if there is no custom destructor set for the given meta type.
+ All what a meta destructor has to offer is a way to invoke it on a given instance. Be aware that the result may not be what is expected.
+
+meta_data and may be invalid if there is no meta data object associated with the given identifier.
+ A meta data object offers an API to query the underlying type (for example, to know if it's a const or a static one), to get the meta type of the variable and to set or get the contained value.
+
+meta_func and may be invalid if there is no meta function object associated with the given identifier.
+ A meta function object offers an API to query the underlying type (for example, to know if it's a const or a static function), to know the number of arguments, the meta return type and the meta types of the parameters. In addition, a meta function object can be used to invoke the underlying function and then get the return value in the form of a meta_any object.
+
+meta_base and may be invalid if there is no meta base object associated with the given identifier.
+ Meta bases aren't meant to be used directly, even though they are freely accessible. They expose only a few methods to use to know the meta type of the base class and to convert a raw pointer between types.
+
+meta_conv and may be invalid if there is no meta conversion function associated with the given type.
+ The meta conversion functions are as thin as the meta bases and with a very similar interface. The sole difference is that they return a newly created instance wrapped in a meta_any object when they convert between different types.construct or destroy actual instances of the underlying type.
+ In particular, the construct member function accepts a variable number of arguments and searches for a match. It returns a meta_any object that may or may not be initialized, depending on whether a suitable constructor has been found or not. On the other side, the destroy member function accepts instances of meta_any as well as actual objects by reference and invokes the registered destructor, if any.
+ Be aware that the result of a call to destroy may not be what is expected. The purpose is to give users the ability to free up resources that require special treatment and not to actually destroy instances.
+ I invite anyone interested in the subject to look at the code, experiment and read the inline documentation to get the best out of this powerful tool.
+Policies: the more, the less
+
+ Their purpose is to require slightly different behavior than the default in some specific cases. For example, when reading a given data member, its value is returned wrapped in a meta_any object which, by default, makes a copy of it. For large objects or if the caller wants to access the original instance, this behavior isn't desirable. Policies are there to offer a solution to this and other problems.
+
+entt::as_is_t.
+ This is the default policy. In general, it should never be used explicitly, since it's implicitly selected if no other policy is specified.
+ In this case, the return values of the functions as well as the properties exposed as data members are always returned by copy in a dedicated wrapper and therefore associated with their original meta types.entt::as_void_t.
+ Its purpose is to discard the return value of a meta object, whatever it is, thus making it appear as if its type were void.
+ If the use with functions is obvious, it must be said that it's also possible to use this policy with constructors and data members. In the first case, the constructor will be invoked but the returned wrapper will actually be empty. In the second case, instead, the property will not be accessible for reading.
+
+entt::as_alias_t.
+ It allows to build wrappers that act as aliases for the objects used to initialize them. Modifying the object contained in the wrapper for which the aliasing was requested will make it possible to directly modify the instance used to initialize the wrapper itself.
+ This policy works with constructors (for example, when objects are taken from an external container rather than created on demand), data members and functions in general (as long as their return types are lvalue references).
+Named constants and enums
+data member function can be used to reflect constants of any type among the other things.
+ This allows users to create meta types for enums that will work exactly like any other meta type built from a class. Similarly, arithmetic types can be enriched with constants of special meaning where required.
+ Personally, I find it very useful not to export what is the difference between enums and classes in C++ directly in the space of the reflected types.meta_any class.
+Properties and meta objects
+
+ For the meta objects that support properties, the member functions of the factory used for registering them will return a decorated version of the factory itself. The latter can be used to attach properties to the last created meta object.
+ Apparently, it's more difficult to say than to do:
+ Multiple formats are supported when it comes to defining a property:
+
+
+
+std::pairs:
+
+
+
+std::tuples:
+
+prop function several times if needed, one for each property to associate with the last meta object created:props function is available to associate several properties at a time. However, in this case properties in the key/value form aren't allowed, since they would be interpreted as two different properties rather than a single one.prop to iterate all properties at once or to search a specific property by key:key and the value member functions to be used to retrieve the key and the value contained in the form of meta_any objects, respectively.
+Unregister types
+
+ Roughly speaking, unregistering a type means disconnecting all associated meta objects from it and making its identifier no longer visible. The underlying node will remain available though, as if it were implicitly generated:
+Generated by
+
+ 1.8.13
+
+
+
diff --git a/autotoc_md77.html b/autotoc_md77.html
deleted file mode 100644
index e1d1cd87a..000000000
--- a/autotoc_md77.html
+++ /dev/null
@@ -1,133 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Introduction
-EnTT offers a minimal support to this paradigm by introducing a few classes that users can use to define and execute cooperative processes.
-The process
-process class template that stays true to the CRTP idiom. Moreover, derived classes must specify what's the intended type for elapsed times.
-
-void update(Delta, void *);void * parameter is an opaque pointer to user data (if any) forwarded directly to the process during an update.void init();void succeeded();void failed();void aborted();succeed and fail, as well as pause and unpause the process itself. All these are protected member functions made available to be able to manage the life cycle of a process from a derived class.
-Adaptor
-
- This class helps in filling the gap and turning lambdas and functors into full featured processes usable by a scheduler.update function of a process but for the fact that it receives two extra arguments to call whenever a process is terminated with success or with an error:
-
-delta is the elapsed time.data is an opaque pointer to user data if any, nullptr otherwise.succeed is a function to call when a process terminates with success.fail is a function to call when a process terminates with errors.succeed and fail accept no parameters at all.
-The scheduler
-
- A process can also have a child. In this case, the parent process is replaced with its child when it terminates and only if it returns with success. In case of errors, both the parent process and its child are discarded. This way, it's easy to create chain of processes to run sequentially.empty or size, as well as a clear utility to reset it to a clean state:
-
-process class template, it's enough to indicate its type and submit all the parameters required to construct it to the attach member function:
-
-attach member function:then member function to use to create chains of processes to run sequentially.
- As a minimal example of use:update member function is the way to go:abort member function that can be used to discard all the running processes at once:
-Generated by
-
- 1.8.13
-
-
-
diff --git a/autotoc_md8.html b/autotoc_md8.html
index 956dfe814..5227501f7 100644
--- a/autotoc_md8.html
+++ b/autotoc_md8.html
@@ -22,7 +22,7 @@
@@ -109,7 +109,7 @@ The Registry, the Entity and the Component
User defined identifiers can be introduced by means of the
ENTT_OPAQUE_TYPE macro if needed.
A registry is used both to construct and to destroy entities:
There exists also an overload of the create and destroy member functions that accepts two iterators, that is a range to assign or to destroy. It can be used to create or destroy multiple entities at once:
In both cases, the create member function accepts also a list of default constructible types of components to assign to the entities before to return. It's a faster alternative to the creation and subsequent assignment of components in separate steps.
In both cases, the create member function accepts also a list of default constructible component types to assign to the entities before to return. It's a faster alternative to the creation and subsequent assignment of components in separate steps.
When an entity is destroyed, the registry can freely reuse it internally with a slightly different identifier. In particular, the version of an entity is increased each and every time it's discarded.
In case entity identifiers are stored around, the registry offers all the functionalities required to test them and to get out of them the information they carry:
Components can be assigned to or removed from entities at any time with a few calls to member functions of the registry. As for the entities, the registry offers also a set of functionalities users can use to work with the components.
@@ -276,11 +276,11 @@ Snapshot: complete vs continuousThe component member function is a function template the aim of which is to store aside components. The presence of a template parameter list is a consequence of a couple of design choices from the past and in the present:
There exists also another version of the component member function that accepts a range of entities to serialize. This version is a bit slower than the other one, mainly because it iterates the range of entities more than once for internal purposes. However, it can be used to filter out those entities that shouldn't be serialized for some reasons.
As an example:
Note that component stores items along with entities. It means that it works properly without a call to the entities member function.
Note that component stores items along with entities. It means that it works properly without a call to the entities member function.
Once a snapshot is created, there exist mainly two ways to load it: as a whole and in a kind of continuous mode.
The following sections describe both loaders and archives in details.
Groups come in three different flavors: full-owning groups, partial-owning groups and non-owning groups. The main difference between them is in terms of performance.
- Groups can literally own one or more types of components. It means that they will be allowed to rearrange pools so as to speed up iterations. Roughly speaking: the more components a group owns, the faster it is to iterate them. On the other side, a given component can belong only to one group, so users have to define groups carefully to get the best out of them.
Continue reading for more details or refer to the inline documentation.
There is no need to store views around for they are extremely cheap to construct, even though they can be copied without problems and reused freely. Views also return newly created and correctly initialized iterators whenever begin or end are invoked.
Views share the way they are created by means of a registry:
-To iterate a view, either use it in a range-for loop:
-Or rely on the each member function to iterate entities and get all their components at once:
The each member function is highly optimized. Unless users want to iterate only entities or get only some of the components, this should be the preferred approach. Note that the entity can also be excluded from the parameter list if not required, but this won't improve performance for multi component views.
+
Filtering entities by components is also supported:
+To iterate a view, either use it in a range-for loop:
+Or rely on the each member function to iterate entities and get all their components at once:
The each member function is highly optimized. Unless users want to iterate only entities or get only some of the components, this should be the preferred approach. Note that the entity can also be excluded from the parameter list if not required, but this won't improve performance for multi component views.
There exists also an alternative version of each named less that works exactly as its counterpart but for the fact that it doesn't return empty components to the caller.
As a side note, when using a single component view, the most common error is to invoke get with the type of the component as a template parameter. This is probably due to the fact that it's required for multi component views:
However, in case of a single component view, get doesn't accept a template parameter, since it's implicitly defined by the view itself:
Note: prefer the get member function of a view instead of the get member function template of a registry during iterations, if possible. However, keep in mind that it works only with the components of the view itself.
As a side note, in the case of single component views, get accepts but doesn't strictly require a template parameter, since the type is implicitly defined:
Note: prefer the get member function of a view instead of the get member function template of a registry during iterations, if possible. However, keep in mind that it works only with the components of the view itself.
Runtime views iterate entities that have at least all the given components in their bags. During construction, these views look at the number of entities available for each component and pick up a reference to the smallest set of candidates in order to speed up iterations.
@@ -367,7 +367,7 @@ Runtime views
Note: runtime views are meant for all those cases where users don't know at compile-time what components to use to iterate entities. This is particularly well suited to plugin systems and mods in general. Where possible, don't use runtime views, as their performance are slightly inferior to those of the other views.
Groups are meant to iterate multiple components at once and offer a faster alternative to views. Roughly speaking, they just play in another league when compared to views.
+
Groups are meant to iterate multiple components at once and offer a (much) faster alternative to views. Roughly speaking, they just play in another league when compared to views.
Groups overcome the performance of the other tools available but require to get the ownership of components and this sets some constraints on pools. On the other side, groups aren't an automatism that increases memory consumption, affects functionalities and tries to optimize iterations for all the possible combinations of components. Users can decide when to pay for groups and to what extent.
The most interesting aspect of groups is that they fit usage patterns. Other solutions around usually try to optimize everything, because it is known that somewhere within the everything there are also our usage patterns. However this has a cost that isn't negligible, both in terms of performance and memory usage. Ironically, users pay the price also for things they don't want and this isn't something I like much. Even worse, one cannot easily disable such a behavior. Groups work differently instead and are designed to optimize only the real use cases when users find they need to.
Another nice-to-have feature of groups is that they have no impact on memory consumption, put aside full non-owning groups that are pretty rare and should be avoided as long as possible.
There is no need to store groups around for they are extremely cheap to construct, even though they can be copied without problems and reused freely. A group performs an initialization step the very first time it's requested and this could be quite costly. To avoid it, consider creating the group when no components have been assigned yet. If the registry is empty, preparation is extremely fast. Groups also return newly created and correctly initialized iterators whenever begin or end are invoked.
To iterate groups, either use them in a range-for loop:
-Or rely on the each member function to iterate entities and get all their components at once:
Or rely on the each member function to iterate entities and get all their components at once:
The each member function is highly optimized. Unless users want to iterate only entities, this should be the preferred approach. Note that the entity can also be excluded from the parameter list if not required and it can improve even further the performance during iterations.
Note: prefer the get member function of a group instead of the get member function template of a registry during iterations, if possible. However, keep in mind that it works only with the components of the group itself.
Let's go a bit deeper into the different types of groups made available by this library to know how they are constructed and what are the differences between them.
@@ -387,16 +387,14 @@ Full-owning groupsA full-owning group is created as:
Filtering entities by components is also supported:
Once created, the group gets the ownership of all the components specified in the template parameter list and arranges their pools so as to iterate all of them as fast as possible.
-Sorting owned components is no longer allowed once the group has been created. However, full-owning groups can be sorted by means of their sort member functions, if required. Sorting a full-owning group affects all the instances of the same group (it means that users don't have to call sort on each instance to sort all of them because they share the underlying data structure).
- The elements that aren't part of the group can still be sorted separately for each pool using the sort member function of the registry.
Sorting owned components is no longer allowed once the group has been created. However, full-owning groups can be sorted by means of their sort member functions, if required. Sorting a full-owning group affects all the instances of the same group (it means that users don't have to call sort on each instance to sort all of them because they share the underlying data structure).
A partial-owning group works similarly to a full-owning group for the components it owns, but relies on indirection to get components owned by other groups. This isn't as fast as a full-owning group, but it's already much faster than views when there are only one or two free components to retrieve (the most common cases likely). In the worst case, it's not slower than views anyway.
A partial-owning group is created as:
Filtering entities by components is also supported:
Once created, the group gets the ownership of all the components specified in the template parameter list and arranges their pools so as to iterate all of them as fast as possible. The ownership of the types provided via entt::get doesn't pass to the group instead.
Sorting owned components is no longer allowed once the group has been created. However, partial-owning groups can be sorted by means of their sort member functions, if required. Sorting a partial-owning group affects all the instances of the same group (it means that users don't have to call sort on each instance to sort all of them because they share the underlying data structure).
- Regarding the owned types, the elements that aren't part of the group can still be sorted separately for each pool using the sort member function of the registry.
Sorting owned components is no longer allowed once the group has been created. However, partial-owning groups can be sorted by means of their sort member functions, if required. Sorting a partial-owning group affects all the instances of the same group (it means that users don't have to call sort on each instance to sort all of them because they share the underlying data structure).
Non-owning groups are usually fast enough, for sure faster than views and well suited for most of the cases. However, they require custom data structures to work properly and they increase memory consumption. As a rule of thumb, users should avoid using non-owning groups, if possible.
@@ -404,18 +402,63 @@ Non-owning groupsFiltering entities by components is also supported:
The group doesn't receive the ownership of any type of component in this case. This type of groups is therefore the least performing in general, but also the only one that can be used in any situation to improve a performance where necessary.
Non-owning groups can be sorted by means of their sort member functions, if required. Sorting a non-owning group affects all the instance of the same group (it means that users don't have to call sort on each instance to sort all of them because they share the set of entities).
A type of component cannot be owned by two or more conflicting groups such as:
+registry.group<transform, sprite>().registry.group<transform, rotation>().However, the same type can be owned by groups belonging to the same family, also called nested groups, such as:
+registry.group<sprite, transform>().registry.group<sprite, transform, rotation>().Fortunately, these are also very common cases if not the most common ones.
+ This allows users to have the highest possible performance on a greater number of component combinations.
Two nested groups are such that they own at least one type of component and the list of component types involved by one of them is contained entirely in that of the other. More specifically, this applies independently to all component lists used to define a group.
+ Therefore, the rules for defining whether two or more groups are nested can be summarized as:
It means that more nested groups extend the their parents by adding more conditions in the form of new components.
+As mentioned, the components don't necessarily have to be all owned so that two groups can be considered nested. In other words, the following definitions are fully valid:
+registry.group<sprite>(entt::get<renderable>).registry.group<sprite, transform>(entt::get<renderable>).registry.group<sprite, transform>(entt::get<renderable, rotation>).Exclusion lists also play their part in this respect. When it comes to defining nested groups, an excluded type of component T is treated as being an observed type not_T. Therefore, these two definitions:
registry.group<sprite, transform>().registry.group<sprite, transform>(entt::exclude<rotation>).Are treated as if users were defining the following groups:
+group<sprite, transform>().group<sprite, transform>(entt::get<not_rotation>).Where not_rotation is an empty tag present only when rotation is not.
Because of this, to define a new group that is more restrictive than an existing one, it's enough to take the list of component types of the latter and extend it by adding new component types either owned, observed or excluded, without any precautions depending on the case.
+ The opposite is also true. To define a larger group, it will be enough to take an existing one and remove constraints from it, in whatever form they are expressed.
+ Note that the greater the number of component types involved by a group, the more restrictive it is.
Despite the extreme flexibility of nested groups, which allow to independently use component types either owned, observed or excluded, the real strength of this tool lies in the possibility of defining a greater number of groups that own the same components, thus offering the best performance in more cases.
+ In fact, given a list of component types involved by a group, the greater the number of those owned, the greater the performance of the group itself.
As a side note, it's no longer possible to sort all groups when defining nested ones. This is because the most restrictive groups share the elements with the less restrictive ones and ordering the latter would invalidate the former.
+ However, given a family of nested groups, it's still possible to sort the most restrictive of them. To prevent users from having to remember which of their groups is the most restrictive, they offer the sortable member function to know if their items can be sorted or not.
The registry class offers two overloads when it comes to constructing views and groups: a const version and a non-const one. The former accepts both const and non-const types as template parameters, the latter accepts only const types instead.
It means that views and groups can be constructed also from a const registry and they propagate the constness of the registry to the types involved. As an example:
Consider the following definition for a non-const view instead:
-In the example above, view can be used to access either read-only or writable position components while velocity components are read-only in all cases.
+
In the example above, view can be used to access either read-only or writable position components while velocity components are read-only in all cases.
In other terms, these statements are all valid:
It's not possible to get non-const references to velocity components from the same view instead and these will result in compilation errors:
Similarly, the each member functions will propagate constness to the type of the components returned during iterations:
Obviously, a caller can still refer to the position components through a const reference because of the rules of the language that fortunately already allow it.
Obviously, a caller can still refer to the position components through a const reference because of the rules of the language that fortunately already allow it.
The same concepts apply to groups as well.
-Views and groups are narrow windows on the entire list of entities. They work by filtering entities according to their components.
In some cases there may be the need to iterate all the entities still in use regardless of their components. The registry offers a specific member function to do that:
To test the orphanity of a single entity, use the member function orphan instead. It accepts a valid entity identifer as an argument and returns true in case the entity is an orphan, false otherwise.
In general, all these functions can result in poor performance.
each is fairly slow because of some checks it performs on each and every entity. For similar reasons, orphans can be even slower. Both functions should not be used frequently to avoid the risk of a performance hit.
Most of the ECS available out there don't allow to create and destroy entities and components during iterations.
EnTT partially solves the problem with a few limitations:
In these cases, iterators aren't invalidated. To be clear, it doesn't mean that also references will continue to be valid.
Consider the following example:
The each member function won't break (because iterators aren't invalidated) but there are no guarantees on references. Use a common range-for loop and get components directly from the view or move the creation of components at the end of the function to avoid dangling pointers.
The each member function won't break (because iterators aren't invalidated) but there are no guarantees on references. Use a common range-for loop and get components directly from the view or move the creation of components at the end of the function to avoid dangling pointers.
Iterators are invalidated instead and the behavior is undefined if an entity is modified or destroyed and it's not the one currently returned by the iterator nor a newly created one.
To work around it, possible approaches are:
A notable side effect of this feature is that the number of required allocations is further reduced in most of the cases.
-Groups are a (much) faster alternative to views. However, the higher the performance, the greater the constraints on what is allowed and what is not.
In particular, groups add in some rare cases a limitation on the creation of components during iterations. It happens in quite particular cases. Given the nature and the scope of the groups, it isn't something in which it will happen to come across probably, but it's good to know it anyway.
In other words, the limitation doesn't exist as long as a type is treated as a free type (as an example with multi component views and partial- or non-owning groups) or iterated with its own group, but it can occur if the type is used as a main type to rule on an iteration.
This happens because groups own the pools of their components and organize the data internally to maximize performance. Because of that, full consistency for owned components is guaranteed only when they are iterated as part of their groups or as free types with multi component views and groups in general.
An empty type T is such that std::is_empty_v<T> returns true. They are also the same types for which empty base optimization (EBO) is possibile.
EnTT handles these types in a special way, optimizing both in terms of performance and memory usage. However, this also has consequences that are worth mentioning.
When an empty type is detected, it's not instantiated in any case. Therefore, only the entities to which it's assigned are made available. All the iterators as well as the get member functions of the registry, the views and the groups will return temporary objects. Similarly, some functions such as try_get or the raw access to the list of components aren't available for this kind of types.
On the other hand, iterations are faster because only the entities to which the type is assigned are considered. Moreover, less memory is used, since there doesn't exist any instance of the component, no matter how many entities it is assigned to.
For similar reasons, wherever a function type of a listener accepts a component, it cannot be caught by a non-const reference. Capture it by copy or by const reference instead.
-More in general, none of the features offered by the library is affected, but for the ones that require to return actual instances.
-More in general, none of the features offered by the library is affected, but for the ones that require to return actual instances.
+ This optimization can be disabled by defining the ENTT_DISABLE_ETO macro. In this case, the empty types will be treated like all other types, no matter what.
In general, the entire registry isn't thread safe as it is. Thread safety isn't something that users should want out of the box for several reasons. Just to mention one of them: performance.
Views, groups and consequently the approach adopted by EnTT are the great exception to the rule. It's true that views, groups and iterators in general aren't thread safe by themselves. Because of this users shouldn't try to iterate a set of components and modify the same set concurrently. However:
This kind of entity-component systems can be used in single threaded applications as well as along with async stuff or multiple threads. Moreover, typical thread based models for ECS don't require a fully thread safe registry to work. Actually, users can reach the goal with the registry as it is while working with most of the common models.
Because of the few reasons mentioned above and many others not mentioned, users are completely responsible for synchronization whether required. On the other hand, they could get away with it without having to resort to particular expedients.
-A special mention is needed for the iterators returned by the views and the groups. Most of the time they meet the requirements of random access iterators, in all cases they meet at least the requirements of forward iterators.
In other terms, they are suitable for use with the parallel algorithms of the standard library. If it's not clear, this is a great thing.
As an example, this kind of iterators can be used in combination with std::for_each and std::execution::par to parallelize the visit and therefore the update of the components returned by a view or a group, as long as the constraints previously discussed are respected:
This can increase the throughput considerably, even without resorting to who knows what artifacts that are difficult to maintain over time.
+This can increase the throughput considerably, even without resorting to who knows what artifacts that are difficult to maintain over time.
Unfortunately, because of the limitations of the current revision of the standard, the parallel std::for_each accepts only forward iterators. This means that the iterators provided by the library cannot return proxy objects as references and must return actual reference types instead.
This may change in the future and the iterators will almost certainly return both the entities and a list of references to their components sooner or later. Multi-pass guarantee won't break in any case and the performance should even benefit from it further.
There are many other features and functions not listed in this document.
EnTT and in particular its ECS part is in continuous development and some things could be forgotten, others could have been omitted on purpose to reduce the size of this file. Unfortunately, some parts may even be outdated and still to be updated.
Sometimes processes are a useful tool to work around the strict definition of a system and introduce logic in a different way, usually without resorting to the introduction of other components.
EnTT offers a minimal support to this paradigm by introducing a few classes that users can use to define and execute cooperative processes.
A typical process must inherit from the process class template that stays true to the CRTP idiom. Moreover, derived classes must specify what's the intended type for elapsed times.
A process should expose publicly the following member functions whether required (note that it isn't required to define a function unless the derived class wants to override the default behavior):
@@ -90,7 +90,7 @@ The processDerived classes can also change the internal state of a process by invoking succeed and fail, as well as pause and unpause the process itself. All these are protected member functions made available to be able to manage the life cycle of a process from a derived class.
Here is a minimal example for the sake of curiosity:
-Lambdas and functors can't be used directly with a scheduler for they are not properly defined processes with managed life cycles.
This class helps in filling the gap and turning lambdas and functors into full featured processes usable by a scheduler.
Both succeed and fail accept no parameters at all.
Note that usually users shouldn't worry about creating adaptors at all. A scheduler creates them internally each and every time a lambda or a functor is used as a process.
-A cooperative scheduler runs different processes and helps managing their life cycles.
Each process is invoked once per tick. If it terminates, it's removed automatically from the scheduler and it's never invoked again. Otherwise it's a good candidate to run one more time the next tick.
A process can also have a child. In this case, the parent process is replaced with its child when it terminates and only if it returns with success. In case of errors, both the parent process and its child are discarded. This way, it's easy to create chain of processes to run sequentially.
Using a scheduler is straightforward. To create it, users must provide only the type for the elapsed times and no arguments at all:
It has member functions to query its internal data structures, like empty or size, as well as a clear utility to reset it to a clean state:
To attach a process to a scheduler there are mainly two ways:
+To attach a process to a scheduler there are mainly two ways:
process class template, it's enough to indicate its type and submit all the parameters required to construct it to the attach member function:|
- EnTT
- 3.1.0
-
- |
-
Resource management is usually one of the most critical part of a software like a game. Solutions are often tuned to the particular application. There exist several approaches and all of them are perfectly fine as long as they fit the requirements of the piece of software in which they are used.
- Examples are loading everything on start, loading on request, predictive loading, and so on.
EnTT doesn't pretend to offer a one-fits-all solution for the different cases. Instead, it offers a minimal and perhaps trivial cache that can be useful most of the time during prototyping and sometimes even in a production environment.
- For those interested in the subject, the plan is to improve it considerably over time in terms of performance, memory usage and functionalities. Hoping to make it, of course, one step at a time.
There are three main actors in the model: the resource, the loader and the cache.
-The resource is whatever users want it to be. An image, a video, an audio, whatever. There are no limits.
- As a minimal example:
A loader is a class the aim of which is to load a specific resource. It has to inherit directly from the dedicated base class as in the following example:
-Where my_resource is the type of resources it creates.
- A resource loader must also expose a public const member function named load that accepts a variable number of arguments and returns a shared pointer to a resource.
- As an example:
In general, resource loaders should not have a state or retain data of any type. They should let the cache manage their resources instead.
- As a side note, base class and CRTP idiom aren't strictly required with the current implementation. One could argue that a cache can easily work with loaders of any type. However, future changes won't be breaking ones by forcing the use of a base class today and that's why the model is already in its place.
Finally, a cache is a specialization of a class template tailored to a specific resource:
-The idea is to create different caches for different types of resources and to manage each one independently in the most appropriate way.
- As a (very) trivial example, audio tracks can survive in most of the scenes of an application while meshes can be associated with a single scene and then discarded when users leave it.
A cache offers a set of basic functionalities to query its internal state and to organize it:
-Besides these member functions, a cache contains what is needed to load, use and discard resources of the given type.
- Before to explore this part of the interface, it makes sense to mention how resources are identified. The type of the identifiers to use is defined as:
Where resource_type is an alias for entt::hashed_string::hash_type. Therefore, resource identifiers are created explicitly as in the following example:
The class hashed_string is described in a dedicated section, so I won't go in details here.
Resources are loaded and thus stored in a cache through the load member function. It accepts the loader to use as a template parameter, the resource identifier and the parameters used to construct the resource as arguments:
The function returns a handle to the resource, whether it already exists or is loaded. In case the loader returns an invalid pointer, the handle is invalid as well and therefore it can be easily used with an if statement:
Before trying to load a resource, the contains member function can be used to know if a cache already contains a specific resource:
There exists also a member function to use to force a reload of an already existing resource if needed:
-As above, the function returns a handle to the resource that is invalid in case of errors. The reload member function is a kind of alias of the following snippet:
Where the discard member function is used to get rid of a resource if loaded. In case the cache doesn't contain a resource for the given identifier, discard does nothing and returns immediately.
So far, so good. Resources are finally loaded and stored within the cache.
- They are returned to users in the form of handles. To get one of them later on:
The idea behind a handle is the same of the flyweight pattern. In other terms, resources aren't copied around. Instead, instances are shared between handles. Users of a resource own a handle that guarantees that a resource isn't destroyed until all the handles are destroyed, even if the resource itself is removed from the cache.
- Handles are tiny objects both movable and copyable. They return the contained resource as a const reference on request:
get member function:The resource can also be accessed directly using the arrow operator if required:
-To test if a handle is still valid, the cast operator to bool allows users to use it in a guard:
Finally, in case there is the need to load a resource and thus to get a handle without storing the resource itself in the cache, users can rely on the temp member function template.
- The declaration is similar to that of load, a (possibly invalid) handle for the resource is returned also in this case:
Do not forget to test the handle for validity. Otherwise, getting a reference to the resource it points may result in undefined behavior.
-
- 1.8.13
-
-
-
diff --git a/autotoc_md83.html b/autotoc_md83.html
deleted file mode 100644
index fc88b68d4..000000000
--- a/autotoc_md83.html
+++ /dev/null
@@ -1,123 +0,0 @@
-
-
-
-
-
-
-
-|
- EnTT
- 3.1.1
-
- |
-
Resource management is usually one of the most critical part of a software like a game. Solutions are often tuned to the particular application. There exist several approaches and all of them are perfectly fine as long as they fit the requirements of the piece of software in which they are used.
- Examples are loading everything on start, loading on request, predictive loading, and so on.
EnTT doesn't pretend to offer a one-fits-all solution for the different cases. Instead, it offers a minimal and perhaps trivial cache that can be useful most of the time during prototyping and sometimes even in a production environment.
- For those interested in the subject, the plan is to improve it considerably over time in terms of performance, memory usage and functionalities. Hoping to make it, of course, one step at a time.
There are three main actors in the model: the resource, the loader and the cache.
-The resource is whatever users want it to be. An image, a video, an audio, whatever. There are no limits.
- As a minimal example:
A loader is a class the aim of which is to load a specific resource. It has to inherit directly from the dedicated base class as in the following example:
-Where my_resource is the type of resources it creates.
- A resource loader must also expose a public const member function named load that accepts a variable number of arguments and returns a shared pointer to a resource.
- As an example:
In general, resource loaders should not have a state or retain data of any type. They should let the cache manage their resources instead.
- As a side note, base class and CRTP idiom aren't strictly required with the current implementation. One could argue that a cache can easily work with loaders of any type. However, future changes won't be breaking ones by forcing the use of a base class today and that's why the model is already in its place.
Finally, a cache is a specialization of a class template tailored to a specific resource:
-The idea is to create different caches for different types of resources and to manage each one independently in the most appropriate way.
- As a (very) trivial example, audio tracks can survive in most of the scenes of an application while meshes can be associated with a single scene and then discarded when users leave it.
A cache offers a set of basic functionalities to query its internal state and to organize it:
-Besides these member functions, a cache contains what is needed to load, use and discard resources of the given type.
- Before to explore this part of the interface, it makes sense to mention how resources are identified. The type of the identifiers to use is defined as:
Where resource_type is an alias for entt::hashed_string::hash_type. Therefore, resource identifiers are created explicitly as in the following example:
The class hashed_string is described in a dedicated section, so I won't go in details here.
Resources are loaded and thus stored in a cache through the load member function. It accepts the loader to use as a template parameter, the resource identifier and the parameters used to construct the resource as arguments:
The function returns a handle to the resource, whether it already exists or is loaded. In case the loader returns an invalid pointer, the handle is invalid as well and therefore it can be easily used with an if statement:
Before trying to load a resource, the contains member function can be used to know if a cache already contains a specific resource:
There exists also a member function to use to force a reload of an already existing resource if needed:
-As above, the function returns a handle to the resource that is invalid in case of errors. The reload member function is a kind of alias of the following snippet:
Where the discard member function is used to get rid of a resource if loaded. In case the cache doesn't contain a resource for the given identifier, discard does nothing and returns immediately.
So far, so good. Resources are finally loaded and stored within the cache.
- They are returned to users in the form of handles. To get one of them later on:
The idea behind a handle is the same of the flyweight pattern. In other terms, resources aren't copied around. Instead, instances are shared between handles. Users of a resource own a handle that guarantees that a resource isn't destroyed until all the handles are destroyed, even if the resource itself is removed from the cache.
- Handles are tiny objects both movable and copyable. They return the contained resource as a const reference on request:
get member function:The resource can also be accessed directly using the arrow operator if required:
-To test if a handle is still valid, the cast operator to bool allows users to use it in a guard:
Finally, in case there is the need to load a resource and thus to get a handle without storing the resource itself in the cache, users can rely on the temp member function template.
- The declaration is similar to that of load, a (possibly invalid) handle for the resource is returned also in this case:
Do not forget to test the handle for validity. Otherwise, getting a reference to the resource it points may result in undefined behavior.
-
- 1.8.13
-
-
-
diff --git a/autotoc_md86.html b/autotoc_md86.html
index 6f02beec2..0032bbd0e 100644
--- a/autotoc_md86.html
+++ b/autotoc_md86.html
@@ -5,7 +5,7 @@
-Signals are usually a core part of games and software architectures in general.
- Roughly speaking, they help to decouple the various parts of a system while allowing them to communicate with each other somehow.
The so called _modern C++_ comes with a tool that can be useful in these terms, the std::function. As an example, it can be used to create delegates.
- However, there is no guarantee that an std::function does not perform allocations under the hood and this could be problematic sometimes. Furthermore, it solves a problem but may not adapt well to other requirements that may arise from time to time.
In case that the flexibility and power of an std::function isn't required or if the price to pay for them is too high,EnTT offers a complete set of lightweight classes to solve the same and many other problems.
Resource management is usually one of the most critical part of a software like a game. Solutions are often tuned to the particular application. There exist several approaches and all of them are perfectly fine as long as they fit the requirements of the piece of software in which they are used.
+ Examples are loading everything on start, loading on request, predictive loading, and so on.
EnTT doesn't pretend to offer a one-fits-all solution for the different cases. Instead, it offers a minimal and perhaps trivial cache that can be useful most of the time during prototyping and sometimes even in a production environment.
+ For those interested in the subject, the plan is to improve it considerably over time in terms of performance, memory usage and functionalities. Hoping to make it, of course, one step at a time.
A delegate can be used as a general purpose invoker with no memory overhead for free functions and members provided along with an instance on which to invoke them.
- It does not claim to be a drop-in replacement for an std::function, so do not expect to use it whenever an std::function fits well. That said, it's most likely even a better fit than an std::function in a lot of cases, so expect to use it quite a lot anyway.
The interface is trivial. It offers a default constructor to create empty delegates:
-All what is needed to create an instance is to specify the type of the function the delegate will contain, that is the signature of the free function or the member one wants to assign to it.
-Attempting to use an empty delegate by invoking its function call operator results in undefined behavior or most likely a crash. Before to use a delegate, it must be initialized.
- There exists a bunch of overloads of the connect member function to do that. As an example of use:
The delegate class accepts also data members, if needed. In this case, the function type of the delegate is such that the parameter list is empty and the value of the data member is at least convertible to the return type.
-Free functions having type equivalent to void(T &, args...) are accepted as well. In this case, T & is considered a payload and the function will receive it back every time it's invoked. In other terms, this works just fine with the above definition:
The function g will be invoked with a reference to c and 42. However, the function type of the delegate is still void(int). This is also the signature of its function call operator.
Another interesting aspect of the delegate class is that it accepts also functions with a list of parameters that is shorter than that of the function type used to specialize the delegate itself.
- The following code is therefore perfectly valid:
Where the function type of the delegate is void(int) as above. It goes without saying that the extra arguments are silently discarded internally.
-v This is a nice-to-have feature in a lot of cases, as an example when the delegate class is used as a building block of a signal-slot system.
To create and initialize a delegate at once, there are a few specialized constructors. Because of the rules of the language, the listener is provided by means of the entt::connect_arg variable template:
Aside connect, a disconnect counterpart isn't provided. Instead, there exists a reset member function to use to clear a delegate.
- To know if a delegate is empty, it can be used explicitly in every conditional statement:
Finally, to invoke a delegate, the function call operator is the way to go as already shown in the examples above:
-In all cases, the listeners don't have to strictly follow the signature of the delegate. As long as a listener can be invoked with the given arguments to yield a result that is convertible to the given result type, everything works just fine.
-Signal handlers work with references to classes, function pointers and pointers to members. Listeners can be any kind of objects and users are in charge of connecting and disconnecting them from a signal to avoid crashes due to different lifetimes. On the other side, performance shouldn't be affected that much by the presence of such a signal handler.
- Signals make use of delegates internally and therefore they undergo the same rules and offer similar functionalities. It may be a good idea to consult the documentation of the delegate class for further information.
A signal handler can be used as a private data member without exposing any publish functionality to the clients of a class. The basic idea is to impose a clear separation between the signal itself and the sink class, that is a tool to be used to connect and disconnect listeners on the fly.
The API of a signal handler is straightforward. The most important thing is that it comes in two forms: with and without a collector. In case a signal is provided with a collector, all the values returned by the listeners can be literally collected and used later by the caller. Otherwise it works just like a plain signal that emits events from time to time.
- To create instances of signal handlers it is sufficient to provide the type of function to which they refer:
Signals offer all the basic functionalities required to know how many listeners they contain (size) or if they contain at least a listener (empty), as well as a function to use to swap handlers (swap).
Besides them, there are member functions to use both to connect and disconnect listeners in all their forms by means of a sink:
-As shown above, the listeners don't have to strictly follow the signature of the signal. As long as a listener can be invoked with the given arguments to yield a result that is convertible to the given return type, everything works just fine.
- The connect member function returns by default a connection object to be used as an alternative to break a connection by means of its release member function. A scoped_connection can also be created from a connection. In this case, the link is broken automatically as soon as the object goes out of scope.
Once listeners are attached (or even if there are no listeners at all), events and data in general can be published through a signal by means of the publish member function:
To collect data, the collect member function should be used instead. Below is a minimal example to show how to use it:
A collector must expose a function operator that accepts as an argument a type to which the return type of the listeners can be converted. Moreover, it can optionally return a boolean value that is true to stop collecting data, false otherwise. This way one can avoid calling all the listeners in case it isn't necessary.
- Functors can also be used in place of a lambda. Since the collector is copied when invoking the collect member function, std::ref is the way to go in this case:
The event dispatcher class is designed so as to be used in a loop. It allows users both to trigger immediate events or to queue events to be published all together once per tick.
- This class shares part of its API with the one of the signal handler, but it doesn't require that all the types of events are specified when declared:
In order to register an instance of a class to a dispatcher, its type must expose one or more member functions the arguments of which are such that const E & can be converted to them for each type of event E, no matter what the return value is.
- The name of the member function aimed to receive the event must be provided to the connect member function of the sink in charge for the specific event:
The disconnect member function follows the same pattern and can be used to remove one listener at a time or all of them at once:
The trigger member function serves the purpose of sending an immediate event to all the listeners registered so far. It offers a convenient approach that relieves users from having to create the event itself. Instead, it's enough to specify the type of event and provide all the parameters required to construct it.
+The resource, the loader and the cache
+
There are three main actors in the model: the resource, the loader and the cache.
+The resource is whatever users want it to be. An image, a video, an audio, whatever. There are no limits.
+ As a minimal example:
A loader is a class the aim of which is to load a specific resource. It has to inherit directly from the dedicated base class as in the following example:
+Where my_resource is the type of resources it creates.
+ A resource loader must also expose a public const member function named load that accepts a variable number of arguments and returns a shared pointer to a resource.
As an example:
Listeners are invoked immediately, order of execution isn't guaranteed. This method can be used to push around urgent messages like an is terminating notification on a mobile app.
-On the other hand, the enqueue member function queues messages together and allows to maintain control over the moment they are sent to listeners. The signature of this method is more or less the same of trigger:
Events are stored aside until the update member function is invoked, then all the messages that are still pending are sent to the listeners at once:
This way users can embed the dispatcher in a loop and literally dispatch events once per tick to their systems.
-A general purpose event emitter thought mainly for those cases where it comes to working with asynchronous stuff.
- Originally designed to fit the requirements of uvw (a wrapper for libuv written in modern C++), it was adapted later to be included in this library.
To create a custom emitter type, derived classes must inherit directly from the base class as:
-The full list of accepted types of events isn't required. Handlers are created internally on the fly and thus each type of event is accepted by default.
-Whenever an event is published, an emitter provides the listeners with a reference to itself along with a const reference to the event. Therefore listeners have an handy way to work with it without incurring in the need of capturing a reference to the emitter itself.
- In addition, an opaque object is returned each time a connection is established between an emitter and a listener, allowing the caller to disconnect them at a later time.
- The opaque object used to handle connections is both movable and copyable. On the other side, an event emitter is movable but not copyable by default.
To create new instances of an emitter, no arguments are required:
-Listeners must be movable and callable objects (free functions, lambdas, functors, std::functions, whatever) whose function type is:
Where Event is the type of event they want to listen.
- There are two ways to attach a listener to an event emitter that differ slightly from each other:
In general, resource loaders should not have a state or retain data of any type. They should let the cache manage their resources instead.
+ As a side note, base class and CRTP idiom aren't strictly required with the current implementation. One could argue that a cache can easily work with loaders of any type. However, future changes won't be breaking ones by forcing the use of a base class today and that's why the model is already in its place.
Finally, a cache is a specialization of a class template tailored to a specific resource:
+The idea is to create different caches for different types of resources and to manage each one independently in the most appropriate way.
+ As a (very) trivial example, audio tracks can survive in most of the scenes of an application while meshes can be associated with a single scene and then discarded when users leave it.
A cache offers a set of basic functionalities to query its internal state and to organize it:
+Besides these member functions, a cache contains what is needed to load, use and discard resources of the given type.
+ Before to explore this part of the interface, it makes sense to mention how resources are identified. The type of the identifiers to use is defined as:
Where id_type is an alias for entt::hashed_string::hash_type. Therefore, resource identifiers are created explicitly as in the following example:
The class hashed_string is described in a dedicated section, so I won't go in details here.
Resources are loaded and thus stored in a cache through the load member function. It accepts the loader to use as a template parameter, the resource identifier and the parameters used to construct the resource as arguments:
The function returns a handle to the resource, whether it already exists or is loaded. In case the loader returns an invalid pointer, the handle is invalid as well and therefore it can be easily used with an if statement:
Before trying to load a resource, the contains member function can be used to know if a cache already contains a specific resource:
There exists also a member function to use to force a reload of an already existing resource if needed:
+As above, the function returns a handle to the resource that is invalid in case of errors. The reload member function is a kind of alias of the following snippet:
Where the discard member function is used to get rid of a resource if loaded. In case the cache doesn't contain a resource for the given identifier, discard does nothing and returns immediately.
So far, so good. Resources are finally loaded and stored within the cache.
+ They are returned to users in the form of handles. To get one of them later on:
The idea behind a handle is the same of the flyweight pattern. In other terms, resources aren't copied around. Instead, instances are shared between handles. Users of a resource own a handle that guarantees that a resource isn't destroyed until all the handles are destroyed, even if the resource itself is removed from the cache.
+ Handles are tiny objects both movable and copyable. They return the contained resource as a const reference on request:
on member function. It is meant to register a listener designed to be invoked more than once for the given event type.get member function:The connection object can be freely discarded. Otherwise, it can be used later to disconnect the listener if required.
-once member function. It is meant to register a listener designed to be invoked only once for the given event type. The listener is automatically disconnected after the first invocation.The connection object can be freely discarded. Otherwise, it can be used later to disconnect the listener if required.
-In both cases, the connection object can be used with the erase member function:
There are also two member functions to use either to disconnect all the listeners for a given type of event or to clear the emitter:
-To send an event to all the listeners that are interested in it, the publish member function offers a convenient approach that relieves users from having to create the event:
Finally, the empty member function tests if there exists at least either a listener registered with the event emitter or to a given type of event:
In general, the event emitter is a handy tool when the derived classes wrap asynchronous operations, because it introduces a nice-to-have model based on events and listeners that kindly hides the complexity behind the scenes. However it is not limited to such uses.
+The resource can also be accessed directly using the arrow operator if required:
+To test if a handle is still valid, the cast operator to bool allows users to use it in a guard:
Finally, in case there is the need to load a resource and thus to get a handle without storing the resource itself in the cache, users can rely on the temp member function template.
+ The declaration is similar to that of load, a (possibly invalid) handle for the resource is returned also in this case:
Do not forget to test the handle for validity. Otherwise, getting a reference to the resource it points may result in undefined behavior.
Signals are usually a core part of games and software architectures in general.
Roughly speaking, they help to decouple the various parts of a system while allowing them to communicate with each other somehow.
The so called _modern C++_ comes with a tool that can be useful in these terms, the std::function. As an example, it can be used to create delegates.
However, there is no guarantee that an std::function does not perform allocations under the hood and this could be problematic sometimes. Furthermore, it solves a problem but may not adapt well to other requirements that may arise from time to time.
In case that the flexibility and power of an std::function isn't required or if the price to pay for them is too high,EnTT offers a complete set of lightweight classes to solve the same and many other problems.
A delegate can be used as a general purpose invoker with no memory overhead for free functions and members provided along with an instance on which to invoke them.
It does not claim to be a drop-in replacement for an std::function, so do not expect to use it whenever an std::function fits well. That said, it's most likely even a better fit than an std::function in a lot of cases, so expect to use it quite a lot anyway.
The interface is trivial. It offers a default constructor to create empty delegates:
-All what is needed to create an instance is to specify the type of the function the delegate will contain, that is the signature of the free function or the member one wants to assign to it.
+All what is needed to create an instance is to specify the type of the function the delegate will contain, that is the signature of the free function or the member one wants to assign to it.
Attempting to use an empty delegate by invoking its function call operator results in undefined behavior or most likely a crash. Before to use a delegate, it must be initialized.
There exists a bunch of overloads of the connect member function to do that. As an example of use:
The delegate class accepts also data members, if needed. In this case, the function type of the delegate is such that the parameter list is empty and the value of the data member is at least convertible to the return type.
-Free functions having type equivalent to void(T *, args...) are accepted as well. In this case, T * is considered a payload and the function will receive it back every time it's invoked. In other terms, this works just fine with the above definition:
The function g will be invoked with a pointer to c and 42. However, the function type of the delegate is still void(int). This is also the signature of its function call operator.
The delegate class accepts also data members, if needed. In this case, the function type of the delegate is such that the parameter list is empty and the value of the data member is at least convertible to the return type.
+Free functions having type equivalent to void(T &, args...) are accepted as well. In this case, T & is considered a payload and the function will receive it back every time it's invoked. In other terms, this works just fine with the above definition:
The function g will be invoked with a reference to c and 42. However, the function type of the delegate is still void(int). This is also the signature of its function call operator.
Another interesting aspect of the delegate class is that it accepts also functions with a list of parameters that is shorter than that of the function type used to specialize the delegate itself.
The following code is therefore perfectly valid:
Where the function type of the delegate is void(int) as above. It goes without saying that the extra arguments are silently discarded internally.
+
Where the function type of the delegate is void(int) as above. It goes without saying that the extra arguments are silently discarded internally.
v This is a nice-to-have feature in a lot of cases, as an example when the delegate class is used as a building block of a signal-slot system.
To create and initialize a delegate at once, there are a few specialized constructors. Because of the rules of the language, the listener is provided by means of the entt::connect_arg variable template:
Aside connect, a disconnect counterpart isn't provided. Instead, there exists a reset member function to use to clear a delegate.
To know if a delegate is empty, it can be used explicitly in every conditional statement:
Finally, to invoke a delegate, the function call operator is the way to go as already shown in the examples above:
-In all cases, the listeners don't have to strictly follow the signature of the delegate. As long as a listener can be invoked with the given arguments to yield a result that is convertible to the given result type, everything works just fine.
-In all cases, the listeners don't have to strictly follow the signature of the delegate. As long as a listener can be invoked with the given arguments to yield a result that is convertible to the given result type, everything works just fine.
+Signal handlers work with naked pointers, function pointers and pointers to members. Listeners can be any kind of objects and users are in charge of connecting and disconnecting them from a signal to avoid crashes due to different lifetimes. On the other side, performance shouldn't be affected that much by the presence of such a signal handler.
+
Signal handlers work with references to classes, function pointers and pointers to members. Listeners can be any kind of objects and users are in charge of connecting and disconnecting them from a signal to avoid crashes due to different lifetimes. On the other side, performance shouldn't be affected that much by the presence of such a signal handler.
Signals make use of delegates internally and therefore they undergo the same rules and offer similar functionalities. It may be a good idea to consult the documentation of the delegate class for further information.
A signal handler can be used as a private data member without exposing any publish functionality to the clients of a class. The basic idea is to impose a clear separation between the signal itself and the sink class, that is a tool to be used to connect and disconnect listeners on the fly.
The API of a signal handler is straightforward. The most important thing is that it comes in two forms: with and without a collector. In case a signal is provided with a collector, all the values returned by the listeners can be literally collected and used later by the caller. Otherwise it works just like a plain signal that emits events from time to time.
+
The API of a signal handler is straightforward. If a collector is supplied to the signal when something is published, all the values returned by the listeners can be literally collected and used later by the caller. Otherwise, the class works just like a plain signal that emits events from time to time.
To create instances of signal handlers it is sufficient to provide the type of function to which they refer:
Signals offer all the basic functionalities required to know how many listeners they contain (size) or if they contain at least a listener (empty), as well as a function to use to swap handlers (swap).
Besides them, there are member functions to use both to connect and disconnect listeners in all their forms by means of a sink:
-As shown above, the listeners don't have to strictly follow the signature of the signal. As long as a listener can be invoked with the given arguments to yield a result that is convertible to the given return type, everything works just fine.
- The connect member function returns by default a connection object to be used as an alternative to break a connection by means of its release member function. A scoped_connection can also be created from a connection. In this case, the link is broken automatically as soon as the object goes out of scope.
As shown above, the listeners don't have to strictly follow the signature of the signal. As long as a listener can be invoked with the given arguments to yield a result that is convertible to the given return type, everything works just fine.
+ It's also possible to connect a listener before other listeners already contained by the signal. The before function returns a sink object correctly initialized for the purpose that can be used to connect one or more listeners in order and in the desired position:
In all cases, the connect member function returns by default a connection object to be used as an alternative to break a connection by means of its release member function. A scoped_connection can also be created from a connection. In this case, the link is broken automatically as soon as the object goes out of scope.
Once listeners are attached (or even if there are no listeners at all), events and data in general can be published through a signal by means of the publish member function:
To collect data, the collect member function should be used instead. Below is a minimal example to show how to use it:
A collector must expose a function operator that accepts as an argument a type to which the return type of the listeners can be converted. Moreover, it can optionally return a boolean value that is true to stop collecting data, false otherwise. This way one can avoid calling all the listeners in case it isn't necessary.
Functors can also be used in place of a lambda. Since the collector is copied when invoking the collect member function, std::ref is the way to go in this case:
The event dispatcher class is designed so as to be used in a loop. It allows users both to trigger immediate events or to queue events to be published all together once per tick.
This class shares part of its API with the one of the signal handler, but it doesn't require that all the types of events are specified when declared:
In order to register an instance of a class to a dispatcher, its type must expose one or more member functions the arguments of which are such that const E & can be converted to them for each type of event E, no matter what the return value is.
+
In order to register an instance of a class to a dispatcher, its type must expose one or more member functions the arguments of which are such that const E & can be converted to them for each type of event E, no matter what the return value is.
The name of the member function aimed to receive the event must be provided to the connect member function of the sink in charge for the specific event:
The disconnect member function follows the same pattern and can be used to remove one listener at a time or all of them at once:
The trigger member function serves the purpose of sending an immediate event to all the listeners registered so far. It offers a convenient approach that relieves users from having to create the event itself. Instead, it's enough to specify the type of event and provide all the parameters required to construct it.
+
The disconnect member function follows the same pattern and can be used to remove one listener at a time or all of them at once:
The trigger member function serves the purpose of sending an immediate event to all the listeners registered so far. It offers a convenient approach that relieves users from having to create the event itself. Instead, it's enough to specify the type of event and provide all the parameters required to construct it.
As an example:
Listeners are invoked immediately, order of execution isn't guaranteed. This method can be used to push around urgent messages like an is terminating notification on a mobile app.
On the other hand, the enqueue member function queues messages together and allows to maintain control over the moment they are sent to listeners. The signature of this method is more or less the same of trigger:
Events are stored aside until the update member function is invoked, then all the messages that are still pending are sent to the listeners at once:
This way users can embed the dispatcher in a loop and literally dispatch events once per tick to their systems.
-A general purpose event emitter thought mainly for those cases where it comes to working with asynchronous stuff.
Originally designed to fit the requirements of uvw (a wrapper for libuv written in modern C++), it was adapted later to be included in this library.
Definition at line 441 of file snapshot.hpp.
+Definition at line 455 of file snapshot.hpp.
@@ -236,7 +236,7 @@ template<typename... Component, typename Archive , typename... Type, typenameDefinition at line 503 of file snapshot.hpp.
+Definition at line 517 of file snapshot.hpp.
@@ -284,7 +284,7 @@ template<typename Archive >Definition at line 478 of file snapshot.hpp.
+Definition at line 492 of file snapshot.hpp.
@@ -332,7 +332,7 @@ template<typename Archive >Definition at line 462 of file snapshot.hpp.
+Definition at line 476 of file snapshot.hpp.
@@ -371,7 +371,7 @@ template<typename Entity >entity is managed by the loader, false otherwise. Definition at line 562 of file snapshot.hpp.
+Definition at line 576 of file snapshot.hpp.
@@ -410,7 +410,7 @@ template<typename Entity >Definition at line 571 of file snapshot.hpp.
+Definition at line 585 of file snapshot.hpp.
@@ -475,7 +475,7 @@ template<typename Entity > This functions helps to identify and destroy those entities.Definition at line 549 of file snapshot.hpp.
+Definition at line 563 of file snapshot.hpp.
@@ -508,7 +508,7 @@ template<typename Entity >Users should invoke this member function after restoring each snapshot, unless they know exactly what they are doing.
Definition at line 517 of file snapshot.hpp.
+Definition at line 531 of file snapshot.hpp.
diff --git a/classentt_1_1basic__group.html b/classentt_1_1basic__group.html index d5f46bdf1..3419dbb41 100644 --- a/classentt_1_1basic__group.html +++ b/classentt_1_1basic__group.html @@ -22,7 +22,7 @@Group.
Primary template isn't defined on purpose. All the specializations give a compile-time error, but for a few reasonable cases.
-Definition at line 26 of file fwd.hpp.
+Definition at line 25 of file fwd.hpp.
|
- EnTT
- 3.1.1
-
- |
-
Non-owning group. - More...
- -#include <group.hpp>
-Public Types | |
| -using | entity_type = typename sparse_set< Entity >::entity_type |
| Underlying entity identifier. | |
| -using | size_type = typename sparse_set< Entity >::size_type |
| Unsigned integer type. | |
| -using | iterator_type = typename sparse_set< Entity >::iterator_type |
| Input iterator type. | |
-Public Member Functions | |
| template<typename Component > | |
| size_type | size () const ENTT_NOEXCEPT |
| Returns the number of existing components of the given type. More... | |
| size_type | size () const ENTT_NOEXCEPT |
| Returns the number of entities that have the given components. More... | |
| size_type | capacity () const ENTT_NOEXCEPT |
| Returns the number of elements that a group has currently allocated space for. More... | |
| -void | shrink_to_fit () |
| Requests the removal of unused capacity. | |
| template<typename Component > | |
| bool | empty () const ENTT_NOEXCEPT |
| Checks whether the pool of a given component is empty. More... | |
| bool | empty () const ENTT_NOEXCEPT |
| Checks whether the group is empty. More... | |
| template<typename Component > | |
| Component * | raw () const ENTT_NOEXCEPT |
| Direct access to the list of components of a given pool. More... | |
| template<typename Component > | |
| const entity_type * | data () const ENTT_NOEXCEPT |
| Direct access to the list of entities of a given pool. More... | |
| const entity_type * | data () const ENTT_NOEXCEPT |
| Direct access to the list of entities. More... | |
| iterator_type | begin () const ENTT_NOEXCEPT |
| Returns an iterator to the first entity that has the given components. More... | |
| iterator_type | end () const ENTT_NOEXCEPT |
| Returns an iterator that is past the last entity that has the given components. More... | |
| iterator_type | find (const entity_type entt) const ENTT_NOEXCEPT |
| Finds an entity. More... | |
| entity_type | operator[] (const size_type pos) const ENTT_NOEXCEPT |
| Returns the identifier that occupies the given position. More... | |
| bool | contains (const entity_type entt) const ENTT_NOEXCEPT |
| Checks if a group contains an entity. More... | |
| template<typename... Component> | |
| decltype(auto) | get ([[maybe_unused]] const entity_type entt) const ENTT_NOEXCEPT |
| Returns the components assigned to the given entity. More... | |
| template<typename Func > | |
| void | each (Func func) const |
| Iterates entities and components and applies the given function object to them. More... | |
| template<typename Func > | |
| void | less (Func func) const |
| Iterates entities and components and applies the given function object to them. More... | |
| template<typename... Component, typename Compare , typename Sort = std_sort, typename... Args> | |
| void | sort (Compare compare, Sort algo=Sort{}, Args &&... args) |
| Sort a group according to the given comparison function. More... | |
| template<typename Component > | |
| void | sort () const |
| Sort the shared pool of entities according to the given component. More... | |
-Friends | |
| -class | basic_registry< Entity > |
| A registry is allowed to create groups. | |
Non-owning group.
-A non-owning group returns all the entities and only the entities that have at least the given components. Moreover, it's guaranteed that the entity list is tightly packed in memory for fast iterations.
- In general, non-owning groups don't stay true to the order of any set of components unless users explicitly sort them.
Important
-Iterators aren't invalidated if:
-In all the other cases, modifying the pools of the given components in any way invalidates all the iterators and using them results in undefined behavior.
-sort on each instance to sort all of them because they share the set of entities).| Entity | A valid entity type (see entt_traits for more details). |
| Exclude | Types of components used to filter the group. |
| Get | Type of component observed by the group. |
| Other | Other types of components observed by the group. |
-
|
- -inline | -
Returns an iterator to the first entity that has the given components.
-The returned iterator points to the first entity that has the given components. If the group is empty, the returned iterator will be equal to end().
-
|
- -inline | -
-
|
- -inline | -
-
|
- -inline | -
Direct access to the list of entities of a given pool.
-The returned pointer is such that range [data<Component>(), data<Component>() + size<Component>()] is always a valid range, even if the container is empty.
begin and end if you want to iterate the group in the expected order.| Component | Type of component in which one is interested. |
-
|
- -inline | -
Direct access to the list of entities.
-The returned pointer is such that range [data(), data() + size()] is always a valid range, even if the container is empty.
begin and end if you want to iterate the group in the expected order.
-
|
- -inline | -
Iterates entities and components and applies the given function object to them.
-The function object is invoked for each entity. It is provided with the entity itself and a set of references to all its components. The constness of the components is as requested.
- The signature of the function must be equivalent to one of the following forms:
| Func | Type of the function object to invoke. |
| func | A valid function object. |
-
|
- -inline | -
-
|
- -inline | -
-
|
- -inline | -
Returns an iterator that is past the last entity that has the given components.
-The returned iterator points to the entity following the last entity that has the given components. Attempting to dereference the returned iterator results in undefined behavior.
-
-
|
- -inline | -
-
|
- -inline | -
Returns the components assigned to the given entity.
-Prefer this function instead of registry::get during iterations. It has far better performance than its companion function.
| Component | Types of components to get. |
| entt | A valid entity identifier. |
-
|
- -inline | -
Iterates entities and components and applies the given function object to them.
-The function object is invoked for each entity. It is provided with the entity itself and a set of references to non-empty components. The constness of the components is as requested.
- The signature of the function must be equivalent to one of the following forms:
| Func | Type of the function object to invoke. |
| func | A valid function object. |
-
|
- -inline | -
-
|
- -inline | -
Direct access to the list of components of a given pool.
-The returned pointer is such that range [raw<Component>(), raw<Component>() + size<Component>()] is always a valid range, even if the container is empty.
begin and end if you want to iterate the group in the expected order.| Component | Type of component in which one is interested. |
-
|
- -inline | -
-
|
- -inline | -
-
|
- -inline | -
Sort a group according to the given comparison function.
-Sort the group so that iterating it with a couple of iterators returns entities and components in the expected order. See begin and end for more details.
The comparison function object must return true if the first element is less than the second one, false otherwise. The signature of the comparison function should be equivalent to one of the following:
Where Component are such that they are iterated by the group.
- Moreover, the comparison function object shall induce a strict weak ordering on the values.
The sort function oject must offer a member function template operator() that accepts three arguments:
The comparison function object received by the sort function object hasn't necessarily the type of the one passed along with the other parameters to this member function.
-data or raw gives no guarantees on the order, even though sort has been invoked.| Component | Optional types of components to compare. |
| Compare | Type of comparison function object. |
| Sort | Type of sort function object. |
| Args | Types of arguments to forward to the sort function object. |
| compare | A valid comparison function object. |
| algo | A valid sort function object. |
| args | Arguments to forward to the sort function object, if any. |
-
|
- -inline | -
Sort the shared pool of entities according to the given component.
-Non-owning groups of the same type share with the registry a pool of entities with its own order that doesn't depend on the order of any pool of components. Users can order the underlying data structure so that it respects the order of the pool of the given component.
-| Component | Type of component to use to impose the order. |
- 1.8.13
-
-
-
diff --git a/classentt_1_1basic__group_3_01Entity_00_01exclude__t_3_01Exclude_8_8_8_01_4_00_01get__t_3_01Get_0b1abda5dc7d1ded50c881833d0ec6d4.html b/classentt_1_1basic__group_3_01Entity_00_01exclude__t_3_01Exclude_8_8_8_01_4_00_01get__t_3_01Get_0b1abda5dc7d1ded50c881833d0ec6d4.html
deleted file mode 100644
index 7c9ce823a..000000000
--- a/classentt_1_1basic__group_3_01Entity_00_01exclude__t_3_01Exclude_8_8_8_01_4_00_01get__t_3_01Get_0b1abda5dc7d1ded50c881833d0ec6d4.html
+++ /dev/null
@@ -1,101 +0,0 @@
-
-
-
-
-
-
-
-|
- EnTT
- 3.1.1
-
- |
-
This is the complete list of members for entt::basic_group< Entity, exclude_t< Exclude... >, get_t< Get... >, Owned, Other... >, including all inherited members.
-
- 1.8.13
-
-
-
diff --git a/classentt_1_1basic__group_3_01Entity_00_01exclude__t_3_01Exclude_8_8_8_01_4_00_01get__t_3_01Get_1aada3a14110654dc27700c17c9c2396.html b/classentt_1_1basic__group_3_01Entity_00_01exclude__t_3_01Exclude_8_8_8_01_4_00_01get__t_3_01Get_1aada3a14110654dc27700c17c9c2396.html
index eecac0d7b..b0166d90c 100644
--- a/classentt_1_1basic__group_3_01Entity_00_01exclude__t_3_01Exclude_8_8_8_01_4_00_01get__t_3_01Get_1aada3a14110654dc27700c17c9c2396.html
+++ b/classentt_1_1basic__group_3_01Entity_00_01exclude__t_3_01Exclude_8_8_8_01_4_00_01get__t_3_01Get_1aada3a14110654dc27700c17c9c2396.html
@@ -102,13 +102,10 @@ Public Member Functions
Definition at line 487 of file group.hpp.
+Definition at line 483 of file group.hpp.
Definition at line 643 of file group.hpp.
+Definition at line 636 of file group.hpp.
@@ -265,7 +262,7 @@ template<typename Entity , typename... Exclude, typename... Get, typename...Definition at line 691 of file group.hpp.
+Definition at line 684 of file group.hpp.
@@ -308,7 +305,7 @@ template<typename Component >Definition at line 609 of file group.hpp.
+Definition at line 602 of file group.hpp.
@@ -342,7 +339,7 @@ template<typename Entity , typename... Exclude, typename... Get, typename...begin and end if you want to iterate the group in the expected order.Definition at line 625 of file group.hpp.
+Definition at line 618 of file group.hpp.
@@ -391,19 +388,19 @@ template<typename Func > -Definition at line 747 of file group.hpp.
+Definition at line 740 of file group.hpp.
-| @@ -422,48 +419,16 @@ template<typename Component > |
Checks whether the pool of a given component is empty.
+Checks whether the group or the pools of the given components are empty.
| Component | Type of component in which one is interested. |
| Component | Types of components in which one is interested. |
-
|
- -inline | -
Definition at line 662 of file group.hpp.
+Definition at line 655 of file group.hpp.
@@ -536,7 +501,7 @@ template<typename Entity , typename... Exclude, typename... Get, typename...Definition at line 672 of file group.hpp.
+Definition at line 665 of file group.hpp.
@@ -586,7 +551,7 @@ template<typename... Component>Definition at line 713 of file group.hpp.
+Definition at line 706 of file group.hpp.
@@ -635,7 +600,7 @@ template<typename Func > -Definition at line 772 of file group.hpp.
+Definition at line 765 of file group.hpp.
@@ -674,7 +639,7 @@ template<typename Entity , typename... Exclude, typename... Get, typename...Definition at line 682 of file group.hpp.
+Definition at line 675 of file group.hpp.
@@ -717,7 +682,7 @@ template<typename Component >Definition at line 587 of file group.hpp.
+Definition at line 580 of file group.hpp.
@@ -757,7 +722,7 @@ template<typename Component >Definition at line 538 of file group.hpp.
+Definition at line 534 of file group.hpp.
@@ -789,7 +754,7 @@ template<typename Entity , typename... Exclude, typename... Get, typename...Returns the number of entities that have the given components.
Definition at line 546 of file group.hpp.
+Definition at line 542 of file group.hpp.
@@ -848,7 +813,6 @@ template<typename... Component, typename Compare , typename Sort = std_sort,The comparison function object received by the sort function object hasn't necessarily the type of the one passed along with the other parameters to this member function.
data or raw gives no guarantees on the order, even though sort has been invoked.|
- EnTT
- 3.1.1
-
- |
-
Owning group. - More...
- -#include <group.hpp>
-Public Types | |
| -using | entity_type = typename sparse_set< Entity >::entity_type |
| Underlying entity identifier. | |
| -using | size_type = typename sparse_set< Entity >::size_type |
| Unsigned integer type. | |
| -using | iterator_type = typename sparse_set< Entity >::iterator_type |
| Input iterator type. | |
-Public Member Functions | |
| template<typename Component > | |
| size_type | size () const ENTT_NOEXCEPT |
| Returns the number of existing components of the given type. More... | |
| size_type | size () const ENTT_NOEXCEPT |
| Returns the number of entities that have the given components. More... | |
| template<typename Component > | |
| bool | empty () const ENTT_NOEXCEPT |
| Checks whether the pool of a given component is empty. More... | |
| bool | empty () const ENTT_NOEXCEPT |
| Checks whether the group is empty. More... | |
| template<typename Component > | |
| Component * | raw () const ENTT_NOEXCEPT |
| Direct access to the list of components of a given pool. More... | |
| template<typename Component > | |
| const entity_type * | data () const ENTT_NOEXCEPT |
| Direct access to the list of entities of a given pool. More... | |
| const entity_type * | data () const ENTT_NOEXCEPT |
| Direct access to the list of entities. More... | |
| iterator_type | begin () const ENTT_NOEXCEPT |
| Returns an iterator to the first entity that has the given components. More... | |
| iterator_type | end () const ENTT_NOEXCEPT |
| Returns an iterator that is past the last entity that has the given components. More... | |
| iterator_type | find (const entity_type entt) const ENTT_NOEXCEPT |
| Finds an entity. More... | |
| entity_type | operator[] (const size_type pos) const ENTT_NOEXCEPT |
| Returns the identifier that occupies the given position. More... | |
| bool | contains (const entity_type entt) const ENTT_NOEXCEPT |
| Checks if a group contains an entity. More... | |
| template<typename... Component> | |
| decltype(auto) | get ([[maybe_unused]] const entity_type entt) const ENTT_NOEXCEPT |
| Returns the components assigned to the given entity. More... | |
| template<typename Func > | |
| void | each (Func func) const |
| Iterates entities and components and applies the given function object to them. More... | |
| template<typename Func > | |
| void | less (Func func) const |
| Iterates entities and components and applies the given function object to them. More... | |
| template<typename... Component, typename Compare , typename Sort = std_sort, typename... Args> | |
| void | sort (Compare compare, Sort algo=Sort{}, Args &&... args) |
| Sort a group according to the given comparison function. More... | |
-Friends | |
| -class | basic_registry< Entity > |
| A registry is allowed to create groups. | |
Owning group.
-Owning groups return all the entities and only the entities that have at least the given components. Moreover:
-The more types of components are owned by a group, the faster it is to iterate them.
-Important
-Iterators aren't invalidated if:
-In all the other cases, modifying the pools of the given components in any way invalidates all the iterators and using them results in undefined behavior.
-sort on each instance to sort all of them because they share the underlying data structure).| Entity | A valid entity type (see entt_traits for more details). |
| Exclude | Types of components used to filter the group. |
| Get | Types of components observed by the group. |
| Owned | Type of component owned by the group. |
| Other | Other types of components owned by the group. |
-
|
- -inline | -
Returns an iterator to the first entity that has the given components.
-The returned iterator points to the first entity that has the given components. If the group is empty, the returned iterator will be equal to end().
-
|
- -inline | -
-
|
- -inline | -
Direct access to the list of entities of a given pool.
-The returned pointer is such that range [data<Component>(), data<Component>() + size<Component>()] is always a valid range, even if the container is empty.
- Moreover, in case the group owns the given component, the range [data<Component>(), data<Component>() + size()] is such that it contains the entities that are part of the group itself.
begin and end if you want to iterate the group in the expected order.| Component | Type of component in which one is interested. |
-
|
- -inline | -
Direct access to the list of entities.
-The returned pointer is such that range [data(), data() + size()] is always a valid range, even if the container is empty.
begin and end if you want to iterate the group in the expected order.
-
|
- -inline | -
Iterates entities and components and applies the given function object to them.
-The function object is invoked for each entity. It is provided with the entity itself and a set of references to all its components. The constness of the components is as requested.
- The signature of the function must be equivalent to one of the following forms:
| Func | Type of the function object to invoke. |
| func | A valid function object. |
-
|
- -inline | -
-
|
- -inline | -
-
|
- -inline | -
Returns an iterator that is past the last entity that has the given components.
-The returned iterator points to the entity following the last entity that has the given components. Attempting to dereference the returned iterator results in undefined behavior.
-
-
|
- -inline | -
-
|
- -inline | -
Returns the components assigned to the given entity.
-Prefer this function instead of registry::get during iterations. It has far better performance than its companion function.
| Component | Types of components to get. |
| entt | A valid entity identifier. |
-
|
- -inline | -
Iterates entities and components and applies the given function object to them.
-The function object is invoked for each entity. It is provided with the entity itself and a set of references to non-empty components. The constness of the components is as requested.
- The signature of the function must be equivalent to one of the following forms:
| Func | Type of the function object to invoke. |
| func | A valid function object. |
-
|
- -inline | -
-
|
- -inline | -
Direct access to the list of components of a given pool.
-The returned pointer is such that range [raw<Component>(), raw<Component>() + size<Component>()] is always a valid range, even if the container is empty.
- Moreover, in case the group owns the given component, the range [raw<Component>(), raw<Component>() + size()] is such that it contains the instances that are part of the group itself.
begin and end if you want to iterate the group in the expected order.| Component | Type of component in which one is interested. |
-
|
- -inline | -
-
|
- -inline | -
-
|
- -inline | -
Sort a group according to the given comparison function.
-Sort the group so that iterating it with a couple of iterators returns entities and components in the expected order. See begin and end for more details.
The comparison function object must return true if the first element is less than the second one, false otherwise. The signature of the comparison function should be equivalent to one of the following:
Where Component are either owned types or not but still such that they are iterated by the group.
- Moreover, the comparison function object shall induce a strict weak ordering on the values.
The sort function oject must offer a member function template operator() that accepts three arguments:
The comparison function object received by the sort function object hasn't necessarily the type of the one passed along with the other parameters to this member function.
-data or raw gives no guarantees on the order, even though sort has been invoked.| Component | Optional types of components to compare. |
| Compare | Type of comparison function object. |
| Sort | Type of sort function object. |
| Args | Types of arguments to forward to the sort function object. |
| compare | A valid comparison function object. |
| algo | A valid sort function object. |
| args | Arguments to forward to the sort function object, if any. |
- 1.8.13
-
-
-
diff --git a/classentt_1_1basic__group_3_01Entity_00_01exclude__t_3_01Exclude_8_8_8_01_4_00_01get__t_3_01Get_86b01ab83965ad65f5c8dea9ea3cb0b2.html b/classentt_1_1basic__group_3_01Entity_00_01exclude__t_3_01Exclude_8_8_8_01_4_00_01get__t_3_01Get_86b01ab83965ad65f5c8dea9ea3cb0b2.html
deleted file mode 100644
index 0ca6ad505..000000000
--- a/classentt_1_1basic__group_3_01Entity_00_01exclude__t_3_01Exclude_8_8_8_01_4_00_01get__t_3_01Get_86b01ab83965ad65f5c8dea9ea3cb0b2.html
+++ /dev/null
@@ -1,104 +0,0 @@
-
-
-
-
-
-
-
-|
- EnTT
- 3.1.1
-
- |
-
This is the complete list of members for entt::basic_group< Entity, exclude_t< Exclude... >, get_t< Get, Other... > >, including all inherited members.
-
- 1.8.13
-
-
-
diff --git a/classentt_1_1basic__group_3_01Entity_00_01exclude__t_3_01Exclude_8_8_8_01_4_00_01get__t_3_01Get_8_8_8_01_4_01_4-members.html b/classentt_1_1basic__group_3_01Entity_00_01exclude__t_3_01Exclude_8_8_8_01_4_00_01get__t_3_01Get_8_8_8_01_4_01_4-members.html
index b98bd8c4e..bf0f808f2 100644
--- a/classentt_1_1basic__group_3_01Entity_00_01exclude__t_3_01Exclude_8_8_8_01_4_00_01get__t_3_01Get_8_8_8_01_4_01_4-members.html
+++ b/classentt_1_1basic__group_3_01Entity_00_01exclude__t_3_01Exclude_8_8_8_01_4_00_01get__t_3_01Get_8_8_8_01_4_01_4-members.html
@@ -78,21 +78,20 @@ $(function() {
Definition at line 268 of file group.hpp.
+Definition at line 265 of file group.hpp.
@@ -342,7 +339,7 @@ template<typename Component >Definition at line 186 of file group.hpp.
+Definition at line 183 of file group.hpp.
@@ -376,7 +373,7 @@ template<typename Entity , typename... Exclude, typename... Get>begin and end if you want to iterate the group in the expected order.Definition at line 202 of file group.hpp.
+Definition at line 199 of file group.hpp.
@@ -425,19 +422,19 @@ template<typename Func > -Definition at line 324 of file group.hpp.
+Definition at line 321 of file group.hpp.
-| @@ -456,48 +453,16 @@ template<typename Component > |
Checks whether the pool of a given component is empty.
+Checks whether the group or the pools of the given components are empty.
| Component | Type of component in which one is interested. |
| Component | Types of components in which one is interested. |
-
|
- -inline | -
Definition at line 239 of file group.hpp.
+Definition at line 236 of file group.hpp.
@@ -570,7 +535,7 @@ template<typename Entity , typename... Exclude, typename... Get>Definition at line 249 of file group.hpp.
+Definition at line 246 of file group.hpp.
@@ -620,7 +585,7 @@ template<typename... Component>Definition at line 290 of file group.hpp.
+Definition at line 287 of file group.hpp.
@@ -669,7 +634,7 @@ template<typename Func > -Definition at line 349 of file group.hpp.
+Definition at line 346 of file group.hpp.
@@ -708,7 +673,7 @@ template<typename Entity , typename... Exclude, typename... Get>Definition at line 259 of file group.hpp.
+Definition at line 256 of file group.hpp.
@@ -750,7 +715,7 @@ template<typename Component >Definition at line 167 of file group.hpp.
+Definition at line 164 of file group.hpp.
@@ -881,7 +846,6 @@ template<typename... Component, typename Compare , typename Sort = std_sort,The comparison function object received by the sort function object hasn't necessarily the type of the one passed along with the other parameters to this member function.
data or raw gives no guarantees on the order, even though sort has been invoked.Definition at line 30 of file fwd.hpp.
+Definition at line 29 of file fwd.hpp.
Definition at line 281 of file observer.hpp.
+Definition at line 285 of file observer.hpp.
@@ -276,7 +276,7 @@ template<typename Entity >The returned iterator points to the first entity of the observer. If the container is empty, the returned iterator will be equal to end().
Definition at line 365 of file observer.hpp.
+Definition at line 369 of file observer.hpp.
@@ -332,7 +332,7 @@ template<typename... Matcher> -Definition at line 310 of file observer.hpp.
+Definition at line 314 of file observer.hpp.
@@ -366,7 +366,7 @@ template<typename Entity >begin and end if you want to iterate the observer in the expected order.Definition at line 353 of file observer.hpp.
+Definition at line 357 of file observer.hpp.
@@ -414,7 +414,7 @@ template<typename Func > -Definition at line 403 of file observer.hpp.
+Definition at line 407 of file observer.hpp.
@@ -462,7 +462,7 @@ template<typename Func > -Definition at line 423 of file observer.hpp.
+Definition at line 427 of file observer.hpp.
@@ -494,7 +494,7 @@ template<typename Entity >Checks whether an observer is empty.
Definition at line 337 of file observer.hpp.
+Definition at line 341 of file observer.hpp.
@@ -527,7 +527,7 @@ template<typename Entity >The returned iterator points to the entity following the last entity of the observer. Attempting to dereference the returned iterator results in undefined behavior.
Definition at line 379 of file observer.hpp.
+Definition at line 383 of file observer.hpp.
@@ -621,7 +621,7 @@ template<typename Entity >Returns the number of elements in an observer.
Definition at line 329 of file observer.hpp.
+Definition at line 333 of file observer.hpp.
diff --git a/classentt_1_1basic__prototype-members.html b/classentt_1_1basic__prototype-members.html deleted file mode 100644 index 87ed2c67b..000000000 --- a/classentt_1_1basic__prototype-members.html +++ /dev/null @@ -1,107 +0,0 @@ - - - - - - - -|
- EnTT
- 3.1.0
-
- |
-
This is the complete list of members for entt::basic_prototype< Entity >, including all inherited members.
-
- 1.8.13
-
-
-
diff --git a/classentt_1_1basic__registry-members.html b/classentt_1_1basic__registry-members.html
index b1fb500ef..893166aa2 100644
--- a/classentt_1_1basic__registry-members.html
+++ b/classentt_1_1basic__registry-members.html
@@ -22,7 +22,7 @@
Public Member Functions | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| basic_registry & | operator= (basic_registry &&)=default | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Default move assignment operator. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Component> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| void | prepare () | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Prepares pools for the given types if required. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename Component > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| size_type | size () const ENTT_NOEXCEPT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| size_type | size () const ENTT_NOEXCEPT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Returns the number of existing components of the given type. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| size_type | size () const ENTT_NOEXCEPT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| size_type | size () const ENTT_NOEXCEPT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Returns the number of entities created so far. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| size_type | alive () const ENTT_NOEXCEPT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| size_type | alive () const ENTT_NOEXCEPT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Returns the number of entities still in use. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename Component > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| void | reserve (const size_type cap) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Increases the capacity of the pool for the given component. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Component> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| void | reserve (const size_type cap) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Increases the capacity of the registry or of the pools for the given components. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| void | reserve (const size_type cap) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Increases the capacity of a registry in terms of entities. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename Component > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| size_type | capacity () const ENTT_NOEXCEPT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| size_type | capacity () const ENTT_NOEXCEPT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Returns the capacity of the pool for the given component. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| size_type | capacity () const ENTT_NOEXCEPT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| size_type | capacity () const ENTT_NOEXCEPT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Returns the number of entities that a registry has currently allocated space for. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename Component > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Component> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| void | shrink_to_fit () | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Requests the removal of unused capacity for a given component. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Requests the removal of unused capacity for the given components. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename Component > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Component> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| bool | empty () const ENTT_NOEXCEPT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Checks whether the pool of a given component is empty. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Checks whether the registry or the pools of the given components are empty. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| bool | empty () const ENTT_NOEXCEPT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Checks if there exists at least an entity still in use. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename Component > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| const Component * | raw () const ENTT_NOEXCEPT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Direct access to the list of components of a given pool. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| auto | create (It first, It last) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Assigns each element in a range an entity. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Component, typename... Exclude> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| auto | create (entity_type src, basic_registry &other, exclude_t< Exclude... >={}) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Creates a new entity from a prototype entity. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Component, typename It , typename... Exclude> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| void | create (It first, It last, entity_type src, basic_registry &other, exclude_t< Exclude... >={}) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Assigns each element in a range an entity from a prototype entity. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Component, typename... Exclude> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| entity_type | create (entity_type src, const basic_registry &other, exclude_t< Exclude... >={}) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Creates a new entity from a prototype entity. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Component, typename It , typename... Exclude> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| void | create (It first, It last, entity_type src, const basic_registry &other, exclude_t< Exclude... >={}) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Assigns each element in a range an entity from a prototype entity. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| void | destroy (const entity_type entity) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Destroys an entity and lets the registry recycle the identifier. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| void | orphans (Func func) const | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Iterates orphans and applies them the given function object. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Component> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| entt::basic_view< Entity, Component... > | view () | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Returns a view for the given components. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Component> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| entt::basic_view< Entity, Component... > | view () const | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Returns a view for the given components. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename Component > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| bool | owned () const ENTT_NOEXCEPT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Checks whether a given component belongs to a group. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Component, typename... Exclude> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| entt::basic_view< Entity, exclude_t< Exclude... >, Component... > | view (exclude_t< Exclude... >={}) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Returns a view for the given components. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Component, typename... Exclude> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| entt::basic_view< Entity, exclude_t< Exclude... >, Component... > | view (exclude_t< Exclude... >={}) const | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Returns a view for the given components. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Component> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| bool | sortable () const ENTT_NOEXCEPT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Checks whether the given components belong to any group. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Owned, typename... Get, typename... Exclude> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| entt::basic_group< Entity, exclude_t< Exclude... >, get_t< Get... >, Owned... > | group (get_t< Get... >, exclude_t< Exclude... >={}) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Returns a group for the given components. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| basic_registry | clone (exclude_t< Exclude... >={}) const | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Returns a full or partial copy of a registry. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Component, typename... Exclude> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| void | stomp (const entity_type dst, const entity_type src, basic_registry &other, exclude_t< Exclude... >={}) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Stomps an entity and its components. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Component, typename It , typename... Exclude> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| void | stomp (It first, It last, const entity_type src, basic_registry &other, exclude_t< Exclude... >={}) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Stomps the entities in a range and their components. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Component, typename... Exclude> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| void | stomp (const entity_type dst, const entity_type src, const basic_registry &other, exclude_t< Exclude... >={}) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Stomps an entity and its components. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| template<typename... Component, typename It , typename... Exclude> | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| void | stomp (It first, It last, const entity_type src, const basic_registry &other, exclude_t< Exclude... >={}) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Stomps the entities in a range and their components. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| entt::basic_snapshot< Entity > | snapshot () const ENTT_NOEXCEPT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Returns a temporary object to use to create snapshots. More... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||