3 [](https://travis-ci.org/skypjack/entt)
4 [](https://ci.appveyor.com/project/skypjack/entt)
5 [](https://coveralls.io/github/skypjack/entt?branch=master)
6 [](https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=W2HF9FESD5LJY&lc=IT&item_name=Michele%20Caini¤cy_code=EUR&bn=PP%2dDonationsBF%3abtn_donateCC_LG%2egif%3aNonHosted)
10 `EnTT` is a header-only, tiny and easy to use framework written in modern
12 It was originally designed entirely around an architectural pattern called _ECS_
13 that is used mostly in game development. For further details:
15 * [Entity Systems Wiki](http://entity-systems.wikidot.com/)
16 * [Evolve Your Hierarchy](http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/)
17 * [ECS on Wikipedia](https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system)
19 A long time ago, the sole entity-component system was part of the project. After
20 a while the codebase has grown and more and more classes have become part
21 of the repository.<br/>
22 That's why today it's called _the EnTT Framework_.
24 Currently, `EnTT` is tested on Linux, Microsoft Windows and OS X. It has proven
25 to work also on both Android and iOS.<br/>
26 Most likely it will not be problematic on other systems as well, but has not
27 been sufficiently tested so far.
31 `EnTT` was written initially as a faster alternative to other well known and
32 open source entity-component systems. Nowadays the `EnTT` framework is moving
33 its first steps. Much more will come in the future and hopefully I'm going to
34 work on it for a long time.<br/>
35 Requests for feature, PR, suggestions ad feedback are highly appreciated.
37 If you find you can help me and want to contribute to the `EnTT` framework with
38 your experience or you do want to get part of the project for some other
39 reason, feel free to contact me directly (you can find the mail in the
40 [profile](https://github.com/skypjack)).<br/>
41 I can't promise that each and every contribution will be accepted, but I can
42 assure that I'll do my best to take them all seriously.
46 Here is a brief list of what it offers today:
48 * Statically generated integer identifiers for types (assigned either at
49 compile-time or at runtime).
50 * A constexpr utility for human readable resource identifiers.
51 * An incredibly fast entity-component system based on sparse sets, with its own
52 views and a _pay for what you use_ policy to adjust performance and memory
53 pressure according to the users' requirements.
54 * Actor class for those who aren't confident with entity-component systems.
55 * The smallest and most basic implementation of a service locator ever seen.
56 * A cooperative scheduler for processes of any type.
57 * All what is needed for resource management (cache, loaders, handles).
58 * Signal handlers of any type, delegates and an event bus.
59 * A general purpose event emitter, that is a CRTP idiom based class template.
60 * An event dispatcher for immediate and delayed events to integrate in loops.
64 Consider it a work in progress. For more details and an updated list, please
65 refer to the [online documentation](https://skypjack.github.io/entt/).
67 ### A note about the README
69 The README file stays true to the original project and it describes only the
70 entity-component system. However, the whole API is fully documented in-code and
71 the [online documentation](https://skypjack.github.io/entt/) contains much
73 Continue reading to know how the core part of the project works or follow the
74 link above to take a look at the API reference for all other available classes.
79 #include <entt/entt.hpp>
92 void update(entt::DefaultRegistry ®istry) {
93 auto view = registry.view<Position, Velocity>();
95 for(auto entity: view) {
96 // gets only the components that are going to be used ...
98 auto &velocity = view.get<Velocity>(entity);
107 void update(std::uint64_t dt, entt::DefaultRegistry ®istry) {
108 registry.view<Position, Velocity>().each([dt](auto entity, auto &position, auto &velocity) {
109 // gets all the components of the view at once ...
111 position.x += velocity.dx * dt;
112 position.y += velocity.dy * dt;
119 entt::DefaultRegistry registry;
120 std::uint64_t dt = 16;
122 for(auto i = 0; i < 10; ++i) {
123 auto entity = registry.create(Position{i * 1.f, i * 1.f});
124 if(i % 2 == 0) { registry.assign<Velocity>(entity, i * .1f, i * .1f); }
127 update(dt, registry);
136 I started working on `EnTT` because of the wrong reason: my goal was to design
137 an entity-component system that beated another well known open source solution
138 in terms of performance.<br/>
139 In the end, I did it, but it wasn't much satisfying. Actually it wasn't
140 satisfying at all. The fastest and nothing more, fairly little indeed. When I
141 realized it, I tried hard to keep intact the great performance of `EnTT` and to
142 add all the features I wanted to see in *my* entity-component system at the same
145 Today `EnTT` is finally what I was looking for: still faster than its
146 _competitors_, a really good API and an amazing set of features. And even more,
151 As it stands right now, `EnTT` is just fast enough for my requirements if
152 compared to my first choice (it was already amazingly fast actually).<br/>
153 Here is a comparision between the two (both of them compiled with GCC 7.2.0 on a
154 Dell XPS 13 out of the mid 2014):
156 | Benchmark | EntityX (compile-time) | EnTT |
157 |-----------|-------------|-------------|
158 | Create 10M entities | 0.1289s | **0.0409s** |
159 | Destroy 10M entities | **0.0531s** | 0.0546s |
160 | Standard view, 10M entities, one component | 0.0107s | **1.6e-07s** |
161 | Standard view, 10M entities, two components | **0.0113s** | 0.0295s |
162 | Standard view, 10M entities, two components<br/>Half of the entities have all the components | **0.0078s** | 0.0150s |
163 | Standard view, 10M entities, two components<br/>One of the entities has all the components | 0.0071s | **8.8e-07s** |
164 | Persistent view, 10M entities, two components | 0.0113s | **5.7e-07s** |
165 | Standard view, 10M entities, five components | **0.0091s** | 0.0688s |
166 | Persistent view, 10M entities, five components | 0.0091s | **2.9e-07s** |
167 | Standard view, 10M entities, ten components | **0.0105s** | 0.1403s |
168 | Standard view, 10M entities, ten components<br/>Half of the entities have all the components | **0.0090s** | 0.0620s |
169 | Standard view, 10M entities, ten components<br/>One of the entities has all the components | 0.0070s | **1.3e-06s** |
170 | Persistent view, 10M entities, ten components | 0.0105s | **6.2e-07s** |
171 | Sort 150k entities, one component<br/>Arrays are in reverse order | - | **0.0043s** |
172 | Sort 150k entities, enforce permutation<br/>Arrays are in reverse order | - | **0.0006s** |
174 `EnTT` includes its own tests and benchmarks. See
175 [benchmark.cpp](https://github.com/skypjack/entt/blob/master/test/benchmark.cpp)
176 for further details.<br/>
177 On Github users can find also a
178 [benchmark suite](https://github.com/abeimler/ecs_benchmark) that compares a
179 bunch of different projects, one of which is `EnTT`.
181 Probably I'll try to get out of `EnTT` more features and better performance in
182 the future, mainly for fun.<br/>
183 If you want to contribute and/or have any suggestion, feel free to make a PR or
184 open an issue to discuss your idea.
190 To be able to use `EnTT`, users must provide a full-featured compiler that
191 supports at least C++14.<br/>
192 The requirements below are mandatory to compile the tests and to extract the
195 * CMake version 3.2 or later.
196 * Doxygen version 1.8 or later.
200 `EnTT` is a header-only library. This means that including the `entt.hpp`
201 header is enough to include the whole framework and use it. For those who are
202 interested only in the entity-component system, consider to include the sole
203 `entity/registry.hpp` header instead.<br/>
204 It's a matter of adding the following line to the top of a file:
207 #include <entt/entt.hpp>
210 Use the line below to include only the entity-component system instead:
213 #include <entt/entity/registry.hpp>
216 Then pass the proper `-I` argument to the compiler to add the `src` directory to
221 The documentation is based on [doxygen](http://www.stack.nl/~dimitri/doxygen/).
228 The API reference will be created in HTML format within the directory
229 `build/docs/html`. To navigate it with your favorite browser:
232 $ your_favorite_browser docs/html/index.html
234 The API reference is also available [online](https://skypjack.github.io/entt/)
235 for the latest version.
239 To compile and run the tests, `EnTT` requires *googletest*.<br/>
240 `cmake` will download and compile the library before to compile anything else.
249 To build the benchmarks, use the following line instead:
251 * `$ cmake -DCMAKE_BUILD_TYPE=Release ..`
253 Benchmarks are compiled only in release mode currently.
259 ### A bitset-free entity-component system
261 `EnTT` is a _bitset-free_ entity-component system that doesn't require users to
262 specify the component set at compile-time.<br/>
263 This is why users can instantiate the core class simply like:
266 entt::DefaultRegistry registry;
269 In place of its more annoying and error-prone counterpart:
272 entt::DefaultRegistry<Comp0, Comp1, ..., CompN> registry;
277 `EnTT` is entirely designed around the principle that users have to pay only for
280 When it comes to using an entity-componet system, the tradeoff is usually
281 between performance and memory usage. The faster it is, the more memory it uses.
282 However, slightly worse performance along non-critical paths are the right price
283 to pay to reduce memory usage and I've always wondered why this kind of tools do
284 not leave me the choice.<br/>
285 `EnTT` follows a completely different approach. It squezees the best from the
286 basic data structures and gives users the possibility to pay more for higher
287 performance where needed.<br/>
288 The disadvantage of this approach is that users need to know the systems they
289 are working on and the tools they are using. Otherwise, the risk to ruin the
290 performance along critical paths is high.
292 So far, this choice has proven to be a good one and I really hope it can be for
293 many others besides me.
297 The `Registry` to store, the `View`s to iterate. That's all.
299 An entity (the _E_ of an _ECS_) is an opaque identifier that users should just
300 use as-is and store around if needed. Do not try to inspect an entity
301 identifier, its type can change in future and a registry offers all the
302 functionalities to query them out-of-the-box. The underlying type of an entity
303 (either `std::uint16_t`, `std::uint32_t` or `std::uint64_t`) can be specified
304 when defining a registry (actually the DefaultRegistry is nothing more than a
305 Registry where the type of the entities is `std::uint32_t`).<br/>
306 Components (the _C_ of an _ECS_) should be plain old data structures or more
307 complex and moveable data structures with a proper constructor. Actually, the
308 sole requirement of a component type is that it must be both move constructible
309 and move assignable. They are list initialized by using the parameters provided
310 to construct the component itself. No need to register components or their types
311 neither with the registry nor with the entity-component system at all.<br/>
312 Systems (the _S_ of an _ECS_) are just plain functions, functors, lambdas or
313 whatever the users want. They can accept a Registry, a View or a PersistentView
314 and use them the way they prefer. No need to register systems or their types
315 neither with the registry nor with the entity-component system at all.
317 The following sections will explain in short how to use the entity-component
318 system, the core part of the whole framework.<br/>
319 In fact, the framework is composed of many other classes in addition to those
320 describe below. For more details, please refer to the
321 [online documentation](https://skypjack.github.io/entt/).
323 ## The Registry, the Entity and the Component
325 A registry is used to store and manage entities as well as to create views to
326 iterate the underlying data structures.<br/>
327 Registry is a class template that lets the users decide what's the preferred
328 type to represent an entity. Because `std::uint32_t` is large enough for almost
329 all the cases, there exists also an alias named DefaultRegistry for
330 `Registry<std::uint32_t>`.
332 Entities are represented by _entitiy identifiers_. An entity identifier is an
333 opaque type that users should not inspect or modify in any way. It carries
334 information about the entity itself and its version.
336 A registry can be used both to construct and to destroy entities:
339 // constructs a naked entity with no components ad returns its identifier
340 auto entity = registry.create();
342 // constructs an entity and assigns it default-initialized components
343 auto another = registry.create<Position, Velocity>();
345 // destroys an entity and all its components
346 registry.destroy(entity);
349 Once an entity is deleted, the registry can freely reuse it internally with a
350 slightly different identifier. In particular, the version of an entity is
351 increased each and every time it's destroyed.<br/>
352 In case entity identifiers are stored around, the registry offers all the
353 functionalities required to test them and get out of the them all the
354 information they carry:
357 // returns true if the entity is still valid, false otherwise
358 bool b = registry.valid(entity);
360 // gets the version contained in the entity identifier
361 auto version = registry.version(entity);
363 // gets the actual version for the given entity
364 auto curr = registry.current(entity);
367 Components can be assigned to or removed from entities at any time with a few
368 calls to member functions of the registry. As for the entities, the registry
369 offers also a set of functionalities users can use to work with the components.
371 The `assign` member function template creates, initializes and assigns to an
372 entity the given component. It accepts a variable number of arguments that are
373 used to construct the component itself if present:
376 registry.assign<Position>(entity, 0., 0.);
380 auto &velocity = registry.assign<Velocity>(entity);
385 If the entity already has the given component, the `replace` member function
386 template can be used to replace it:
389 registry.replace<Position>(entity, 0., 0.);
393 auto &velocity = registry.replace<Velocity>(entity);
398 In case users want to assign a component to an entity, but it's unknown whether
399 the entity already has it or not, `accomodate` does the work in a single call
400 (there is a performance penalty to pay for this mainly due to the fact that it
401 has to check if `entity` already has the given component or not):
404 registry.accomodate<Position>(entity, 0., 0.);
408 auto &velocity = registry.accomodate<Velocity>(entity);
413 Note that `accomodate` is a sliglhty faster alternative for the following
414 `if`/`else` statement and nothing more:
417 if(registry.has<Comp>(entity)) {
418 registry.replace<Comp>(entity, arg1, argN);
420 registry.assign<Comp>(entity, arg1, argN);
424 As already shown, if in doubt about whether or not an entity has one or more
425 components, the `has` member function template may be useful:
428 bool b = registry.has<Position, Velocity>(entity);
431 On the other side, if the goal is to delete a single component, the `remove`
432 member function template is the way to go when it's certain that the entity owns
433 a copy of the component:
436 registry.remove<Position>(entity);
439 Otherwise consider to use the `reset` member function. It behaves similarly to
440 `remove` but with a strictly defined behaviour (and a performance penalty is the
441 price to pay for this). In particular it removes the component if and only if it
442 exists, otherwise it returns safely to the caller:
445 registry.reset<Position>(entity);
448 There exist also two other _versions_ of the `reset` member function:
450 * If no entity is passed to it, `reset` will remove the given component from
451 each entity that has it:
454 registry.reset<Position>();
457 * If neither the entity nor the component are specified, all the entities and
458 their components are destroyed:
464 Finally, references to components can be retrieved simply by doing this:
467 // either a non-const reference ...
468 entt::DefaultRegistry registry;
469 auto &position = registry.get<Position>(entity);
471 // ... or a const one
472 const auto &cregistry = registry;
473 const auto &position = cregistry.get<Position>(entity);
476 The `get` member function template gives direct access to the component of an
477 entity stored in the underlying data structures of the registry.
479 ### Single instance components
481 In those cases where all what is needed is a single instance component, tags are
482 the right tool to achieve the purpose.<br/>
483 Tags undergo the same requirements of components. They can be either plain old
484 data structures or more complex and moveable data structures with a proper
486 Actually, the same type can be used both as a tag and as a component and the
487 registry will not complain about it. It is up to the users to properly manage
490 Attaching tags to entities and removing them is trivial:
493 auto player = registry.create();
494 auto camera = registry.create();
496 // attaches a default-initialized tag to an entity
497 registry.attach<PlayingCharacter>(player);
499 // attaches a tag to an entity and initializes it
500 registry.attach<Camera>(camera, player);
502 // removes tags from their owners
503 registry.remove<PlayingCharacter>();
504 registry.remove<Camera>();
507 If in doubt about whether or not a tag has already an owner, the `has` member
508 function template may be useful:
511 bool b = registry.has<PlayingCharacter>();
514 References to tags can be retrieved simply by doing this:
517 // either a non-const reference ...
518 entt::DefaultRegistry registry;
519 auto &player = registry.get<PlayingCharacter>();
521 // ... or a const one
522 const auto &cregistry = registry;
523 const auto &camera = cregistry.get<Camera>();
526 The `get` member function template gives direct access to the tag as stored in
527 the underlying data structures of the registry.
529 As shown above, in almost all the cases the entity identifier isn't required,
530 since a single instance component can have only one associated entity and
531 therefore it doesn't make much sense to mention it explicitly.<br/>
532 To find out who the owner is, just do the following:
535 auto player = registry.attachee<PlayingCharacter>();
538 Note that iterating tags isn't possible for obvious reasons. Tags give direct
539 access to single entities and nothing more.
541 ### Runtime components
543 Defining components at runtime is useful to support plugins and mods in general.
544 However, it seems impossible with a tool designed around a bunch of templates.
545 Indeed it's not that difficult.<br/>
546 Of course, some features cannot be easily exported into a runtime
547 environment. As an example, sorting a group of components defined at runtime
548 isn't for free if compared to most of the other operations. However, the basic
549 functionalities of an entity-component system such as `EnTT` fit the problem
550 perfectly and can also be used to manage runtime components if required.<br/>
551 All that is necessary to do it is to know the identifiers of the components. An
552 identifier is nothing more than a number or similar that can be used at runtime
553 to work with the type system.
555 In `EnTT`, identifiers are easily accessible:
558 entt::DefaultRegistry registry;
560 // standard component identifier
561 auto ctype = registry.component<Position>();
563 // single instance component identifier
564 auto ttype = registry.tag<PlayingCharacter>();
567 Once the identifiers are made available, almost everything becomes pretty
570 #### A journey through a plugin
572 `EnTT` comes with an example (actually a test) that shows how to integrate
573 compile-time and runtime components in a stack based JavaScript environment. It
574 uses [`duktape`](https://github.com/svaarala/duktape) under the hood, mainly
575 because I wanted to learn how it works at the time I was writing the code.
577 It's not production-ready and overall performance can be highly improved.
578 However, I sacrificed optimizations in favor of a more readable piece of
579 code. I hope I succeeded.<br/>
580 Note also that this isn't neither the only nor (probably) the best way to do it.
581 In fact, the right way depends on the scripting language and the problem one is
584 The basic idea is that of creating a compile-time component aimed to map all the
585 runtime components assigned to an entity.<br/>
586 Identifiers come in use to address the right function from a map when invoked
587 from the runtime environment and to filter entities when iterating.<br/>
588 With a bit of gymnastic, one can narrow views and improve the performance to
589 some extent but it was not the goal of the example.
591 ### Sorting: is it possible?
593 It goes without saying that sorting entities and components is possible with
595 In fact, there are two functions that respond to slightly different needs:
597 * Components can be sorted directly:
600 registry.sort<Renderable>([](const auto &lhs, const auto &rhs) {
601 return lhs.z < rhs.z;
605 * Components can be sorted according to the order imposed by another component:
608 registry.sort<Movement, Physics>();
611 In this case, instances of `Movement` are arranged in memory so that cache
612 misses are minimized when the two components are iterated together.
614 ## View: to persist or not to persist?
616 There are mainly two kinds of views: standard (also known as View) and
617 persistent (alsa known as PersistentView).<br/>
618 Both of them have pros and cons to take in consideration. In particular:
623 * They work out-of-the-box and don't require any dedicated data
625 * Creating and destroying them isn't expensive at all because they don't
626 have any type of initialization.
627 * They are the best tool to iterate single components.
628 * They are the best tool to iterate multiple components at once when
629 tags are involved or one of the component is assigned to a
630 significantly low number of entities.
631 * They don't affect any other operations of the registry.
634 * Their performance tend to degenerate when the number of components
635 to iterate grows up and the most of the entities have all of them.
640 * Once prepared, creating and destroying them isn't expensive at all
641 because they don't have any type of initialization.
642 * They are the best tool to iterate multiple components at once when
643 the most of the entities have all of them.
646 * They have dedicated data structures and thus affect the memory
647 pressure to a minimal extent.
648 * If not previously prepared, the first time they are used they go
649 through an initialization step that could take a while.
650 * They affect to a minimum the creation and destruction of entities and
651 components. In other terms: the more persistent views there will be,
652 the less performing will be creating and destroying entities and
655 To sum up and as a rule of thumb, use a standard view:
656 * To iterate entities for a single component.
657 * To iterate entities for multiple components when a significantly low
658 number of entities have one of the components.
659 * In all those cases where a persistent view would give a boost to
660 performance but the iteration isn't performed frequently.
662 Use a persistent view in all the other cases.
664 To easily iterate entities, all the views offer the common `begin` and `end`
665 member functions that allow users to use a view in a typical range-for
667 Continue reading for more details or refer to the
668 [official documentation](https://skypjack.github.io/entt/).
672 A standard view behaves differently if it's constructed for a single component
673 or if it has been requested to iterate multiple components. Even the API is
674 different in the two cases.<br/>
675 All that they share is the way they are created by means of a registry:
678 // single component standard view
679 auto single = registry.view<Position>();
681 // multi component standard view
682 auto multi = registry.view<Position, Velocity>();
685 For all that remains, it's worth discussing them separately.<br/>
687 #### Single component standard view
689 Single component standard views are specialized in order to give a boost in
690 terms of performance in all the situation. This kind of views can access the
691 underlying data structures directly and avoid superflous checks.<br/>
692 They offer a bunch of functionalities to get the number of entities they are
693 going to return and a raw access to the entity list as well as to the component
695 Refer to the [official documentation](https://skypjack.github.io/entt/) for all
698 There is no need to store views around for they are extremely cheap to
699 construct, even though they can be copied without problems and reused
700 freely. In fact, they return newly created and correctly initialized iterators
701 whenever `begin` or `end` are invoked.<br/>
702 To iterate a single component standard view, either use it in range-for loop:
705 auto view = registry.view<Renderable>();
707 for(auto entity: view) {
708 auto &renderable = view.get(entity);
714 Or rely on the `each` member function to iterate entities and get all their
718 registry.view<Renderable>().each([](auto entity, auto &renderable) {
723 Performance are more or less the same. The best approach depends mainly on
724 whether all the components have to be accessed or not.
726 **Note**: prefer the `get` member function of a view instead of the `get` member
727 function template of a registry during iterations, if possible. However, keep in
728 mind that it works only with the components of the view itself.
730 #### Multi component standard view
732 Multi component standard views iterate entities that have at least all the given
733 components in their bags. During construction, these views look at the number
734 of entities available for each component and pick up a reference to the smallest
735 set of candidates in order to speed up iterations.<br/>
736 They offer fewer functionalities than their companion views for single
737 component, the most important of which can be used to reset the view and refresh
738 the reference to the set of candidate entities to iterate.<br/>
739 Refer to the [official documentation](https://skypjack.github.io/entt/) for all
742 There is no need to store views around for they are extremely cheap to
743 construct, even though they can be copied without problems and reused
744 freely. In fact, they return newly created and correctly initialized iterators
745 whenever `begin` or `end` are invoked.<br/>
746 To iterate a multi component standard view, either use it in range-for loop:
749 auto view = registry.view<Position, Velocity>();
751 for(auto entity: view) {
752 auto &position = view.get<Position>(entity);
753 auto &velocity = view.get<Velocity>(entity);
759 Or rely on the `each` member function to iterate entities and get all their
763 registry.view<Position, Velocity>().each([](auto entity, auto &position, auto &velocity) {
768 Performance are more or less the same. The best approach depends mainly on
769 whether all the components have to be accessed or not.
771 **Note**: prefer the `get` member function of a view instead of the `get` member
772 function template of a registry during iterations, if possible. However, keep in
773 mind that it works only with the components of the view itself.
777 A persistent view returns all the entities and only the entities that have at
778 least the given components. Moreover, it's guaranteed that the entity list is
779 thightly packed in memory for fast iterations.<br/>
780 In general, persistent views don't stay true to the order of any set of
781 components unless users explicitly sort them.
783 Persistent views can be used only to iterate multiple components. Create them
787 auto view = registry.persistent<Position, Velocity>();
790 There is no need to store views around for they are extremely cheap to
791 construct, even though they can be copied without problems and reused
792 freely. In fact, they return newly created and correctly initialized iterators
793 whenever `begin` or `end` are invoked.<br/>
794 That being said, persistent views perform an initialization step the very first
795 time they are constructed and this could be quite costly. To avoid it, consider
796 asking to the registry to _prepare_ them when no entities have been created yet:
799 registry.prepare<Position, Velocity>();
802 If the registry is empty, preparation is extremely fast. Moreover the `prepare`
803 member function template is idempotent. Feel free to invoke it even more than
804 once: if the view has been alreadt prepared before, the function returns
805 immediately and does nothing.
807 A persistent view offers a bunch of functionalities to get the number of
808 entities it's going to return, a raw access to the entity list and the
809 possibility to sort the underlying data structures according to the order of one
810 of the components for which it has been constructed.<br/>
811 Refer to the [official documentation](https://skypjack.github.io/entt/) for all
814 To iterate a persistent view, either use it in range-for loop:
817 auto view = registry.persistent<Position, Velocity>();
819 for(auto entity: view) {
820 auto &position = view.get<Position>(entity);
821 auto &velocity = view.get<Velocity>(entity);
827 Or rely on the `each` member function to iterate entities and get all their
831 registry.persistent<Position, Velocity>().each([](auto entity, auto &position, auto &velocity) {
836 Performance are more or less the same. The best approach depends mainly on
837 whether all the components have to be accessed or not.
839 **Note**: prefer the `get` member function of a view instead of the `get` member
840 function template of a registry during iterations, if possible. However, keep in
841 mind that it works only with the components of the view itself.
845 * Entity identifiers are numbers and nothing more. They are not classes and they
846 have no member functions at all. As already mentioned, do no try to inspect or
847 modify an entity descriptor in any way.
849 * As shown in the examples above, the preferred way to get references to the
850 components while iterating a view is by using the view itself. It's a faster
851 alternative to the `get` member function template that is part of the API of
852 the Registry. This is because the registry must ensure that a pool for the
853 given component exists before to use it; on the other side, views force the
854 construction of the pools for all their components and access them directly,
855 thus avoiding all the checks.
857 * Most of the _ECS_ available out there have an annoying limitation (at least
858 from my point of view): entities and components cannot be created and/or
859 deleted during iterations.<br/>
860 `EnTT` partially solves the problem with a few limitations:
862 * Creating entities and components is allowed during iterations.
863 * Deleting an entity or removing its components is allowed during
864 iterations if it's the one currently returned by a view. For all the
865 other entities, destroying them or removing their components isn't
866 allowed and it can result in undefined behavior.
868 Iterators are invalidated and the behaviour is undefined if an entity is
869 modified or destroyed and it's not the one currently returned by the
871 To work around it, possible approaches are:
873 * Store aside the entities and the components to be removed and perform the
874 operations at the end of the iteration.
875 * Mark entities and components with a proper tag component that indicates
876 they must be purged, then perform a second iteration to clean them up one
879 * Views and thus their iterators aren't thread safe. Do no try to iterate a set
880 of components and modify the same set concurrently.<br/>
881 That being said, as long as a thread iterates the entities that have the
882 component `X` or assign and removes that component from a set of entities,
883 another thread can safely do the same with components `Y` and `Z` and
884 everything will work like a charm.<br/>
885 As an example, users can freely execute the rendering system and iterate the
886 renderable entities while updating a physic component concurrently on a
887 separate thread if needed.
891 If you want to contribute, please send patches as pull requests against the
892 branch `master`.<br/>
894 [contributors list](https://github.com/skypjack/entt/blob/master/AUTHORS) to see
895 who has partecipated so far.
899 Code and documentation Copyright (c) 2017 Michele Caini.<br/>
901 [the MIT license](https://github.com/skypjack/entt/blob/master/LICENSE).
903 [Creative Commons](https://github.com/skypjack/entt/blob/master/docs/LICENSE).
907 Developing and maintaining `EnTT` takes some time and lots of coffee. I'd like
908 to add more and more functionalities in future and turn it in a full-featured
910 If you want to support this project, you can offer me an espresso. I'm from
911 Italy, we're used to turning the best coffee ever in code. If you find that
912 it's not enough, feel free to support me the way you prefer.<br/>
913 Take a look at the donation button at the top of the page for more details or
914 just click [here](https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=W2HF9FESD5LJY&lc=IT&item_name=Michele%20Caini¤cy_code=EUR&bn=PP%2dDonationsBF%3abtn_donateCC_LG%2egif%3aNonHosted).
Checks whether a sparse set is empty.
The number of elements is also the size of the internal packed array. There is no guarantee that the internal sparse array has the same size. Usually the size of the internal sparse array is equal or greater than the one of the internal packed array.
-