From e9b4a6dd1f6c7e6baa31b716f698310b68880970 Mon Sep 17 00:00:00 2001 From: Michele Caini Date: Wed, 15 Nov 2017 22:49:45 +0100 Subject: [PATCH] API reference v2.2.0 --- README_8md_source.html | 4 +- actor_8hpp_source.html | 92 +++ annotated.html | 60 +- bus_8hpp_source.html | 30 +- cache_8hpp_source.html | 93 +++ classentt_1_1Bus.html | 2 +- ...01Event_00_01Other_8_8_8_01_4-members.html | 28 +- ...1Sig_00_01Event_00_01Other_8_8_8_01_4.html | 104 +-- ..._1Bus_3_01Sig_00_01Event_01_4-members.html | 24 +- classentt_1_1Bus_3_01Sig_00_01Event_01_4.html | 106 +-- classentt_1_1Delegate.html | 2 +- ...ate_3_01Ret_07Args_8_8_8_08_4-members.html | 4 +- ...1_1Delegate_3_01Ret_07Args_8_8_8_08_4.html | 8 +- classentt_1_1Dispatcher-members.html | 9 +- classentt_1_1Dispatcher.html | 94 +-- classentt_1_1Emitter-members.html | 4 +- classentt_1_1Emitter.html | 28 +- classentt_1_1Family-members.html | 2 +- classentt_1_1Family.html | 2 +- classentt_1_1HashedString-members.html | 87 +++ classentt_1_1HashedString.html | 304 +++++++++ classentt_1_1PersistentView-members.html | 4 +- classentt_1_1PersistentView.html | 33 +- classentt_1_1Process-members.html | 95 +++ classentt_1_1Process.html | 512 ++++++++++++++ classentt_1_1Process__coll__graph.map | 2 + classentt_1_1Process__coll__graph.md5 | 1 + classentt_1_1Process__coll__graph.png | Bin 0 -> 4373 bytes classentt_1_1Process__inherit__graph.map | 2 + classentt_1_1Process__inherit__graph.md5 | 1 + classentt_1_1Process__inherit__graph.png | Bin 0 -> 4373 bytes classentt_1_1Registry-members.html | 37 +- classentt_1_1Registry.html | 637 ++++++++++++++---- classentt_1_1ResourceCache-members.html | 96 +++ classentt_1_1ResourceCache.html | 563 ++++++++++++++++ classentt_1_1ResourceHandle-members.html | 91 +++ classentt_1_1ResourceHandle.html | 344 ++++++++++ classentt_1_1ResourceLoader-members.html | 82 +++ classentt_1_1ResourceLoader.html | 115 ++++ classentt_1_1Scheduler-members.html | 94 +++ classentt_1_1Scheduler.html | 510 ++++++++++++++ classentt_1_1SigH.html | 2 +- ..._8_8_8_08_00_01Collector_01_4-members.html | 14 +- ...t_07Args_8_8_8_08_00_01Collector_01_4.html | 214 +----- classentt_1_1Signal.html | 2 +- ...al_3_01void_07Args_8_8_8_08_4-members.html | 14 +- ..._1_1Signal_3_01void_07Args_8_8_8_08_4.html | 202 +----- classentt_1_1SparseSet.html | 2 +- ...Set_3_01Entity_00_01Type_01_4-members.html | 40 +- ..._1SparseSet_3_01Entity_00_01Type_01_4.html | 136 ++-- ..._1_1SparseSet_3_01Entity_01_4-members.html | 6 +- classentt_1_1SparseSet_3_01Entity_01_4.html | 85 ++- classentt_1_1View-members.html | 4 +- classentt_1_1View.html | 28 +- ..._01Entity_00_01Component_01_4-members.html | 6 +- ..._1View_3_01Entity_00_01Component_01_4.html | 54 +- classes.html | 42 +- delegate_8hpp_source.html | 8 +- dir_66e9674e8206a335795995fa32a03c91.html | 2 +- dir_68267d1309a1af8e8297ef4c3efbcdba.html | 2 +- dir_721f6154dba3c88bcdead5f446bce319.html | 78 +++ dir_85dbee8884f1b3a817fa7eff8dff73ec.html | 78 +++ dir_a53318306f6ac0f7fe657839abd543ab.html | 2 +- dir_b64489a1e8130d5ebf6d86d282f500f0.html | 2 +- dir_de8f4e6ba3f54a2a21309f742e93a373.html | 2 +- dir_e3a7bb56c55e5c2286e2fe96e197d4f5.html | 2 +- dispatcher_8hpp_source.html | 16 +- emitter_8hpp_source.html | 23 +- entt_8hpp_source.html | 4 +- family_8hpp_source.html | 2 +- files.html | 39 +- functions.html | 19 +- functions_0x7e.html | 23 +- functions_b.html | 6 +- functions_c.html | 20 +- functions_d.html | 17 +- functions_e.html | 9 +- functions_f.html | 5 +- functions_func.html | 341 +--------- functions_func_0x7e.html | 89 +++ functions_func_b.html | 80 +++ functions_func_c.html | 112 +++ functions_func_d.html | 104 +++ functions_func_e.html | 106 +++ functions_func_f.html | 77 +++ functions_func_g.html | 85 +++ functions_func_h.html | 85 +++ functions_func_l.html | 77 +++ functions_func_o.html | 118 ++++ functions_func_p.html | 99 +++ functions_func_r.html | 120 ++++ functions_func_s.html | 112 +++ functions_func_t.html | 83 +++ functions_func_u.html | 90 +++ functions_func_v.html | 87 +++ functions_g.html | 14 +- functions_h.html | 14 +- functions_i.html | 2 +- functions_l.html | 5 +- functions_o.html | 35 +- functions_p.html | 11 +- functions_r.html | 35 +- functions_rela.html | 6 +- functions_s.html | 27 +- functions_t.html | 6 +- functions_type.html | 41 +- functions_u.html | 13 +- functions_v.html | 7 +- functions_vars.html | 12 +- graph_legend.html | 2 +- handle_8hpp_source.html | 84 +++ hashed__string_8hpp_source.html | 85 +++ hierarchy.html | 71 +- ident_8hpp_source.html | 2 +- index.html | 137 ++-- inherit_graph_0.map | 2 +- inherit_graph_0.md5 | 2 +- inherit_graph_0.png | Bin 1564 -> 2125 bytes inherit_graph_1.map | 4 +- inherit_graph_1.md5 | 2 +- inherit_graph_1.png | Bin 6519 -> 1564 bytes inherit_graph_10.map | 2 +- inherit_graph_10.md5 | 2 +- inherit_graph_10.png | Bin 1857 -> 1985 bytes inherit_graph_11.map | 2 +- inherit_graph_11.md5 | 2 +- inherit_graph_11.png | Bin 1340 -> 1857 bytes inherit_graph_12.map | 2 +- inherit_graph_12.md5 | 2 +- inherit_graph_12.png | Bin 2696 -> 1340 bytes inherit_graph_13.map | 2 +- inherit_graph_13.md5 | 2 +- inherit_graph_13.png | Bin 1735 -> 1637 bytes inherit_graph_14.map | 2 +- inherit_graph_14.md5 | 2 +- inherit_graph_14.png | Bin 2063 -> 2696 bytes inherit_graph_15.map | 2 +- inherit_graph_15.md5 | 2 +- inherit_graph_15.png | Bin 2336 -> 2282 bytes inherit_graph_16.map | 3 +- inherit_graph_16.md5 | 2 +- inherit_graph_16.png | Bin 2783 -> 7272 bytes inherit_graph_17.map | 2 +- inherit_graph_17.md5 | 2 +- inherit_graph_17.png | Bin 1890 -> 1735 bytes inherit_graph_18.map | 2 +- inherit_graph_18.md5 | 2 +- inherit_graph_18.png | Bin 2841 -> 2193 bytes inherit_graph_19.map | 3 +- inherit_graph_19.md5 | 2 +- inherit_graph_19.png | Bin 3598 -> 2061 bytes inherit_graph_2.map | 4 +- inherit_graph_2.md5 | 2 +- inherit_graph_2.png | Bin 2312 -> 6519 bytes inherit_graph_20.map | 2 +- inherit_graph_20.md5 | 2 +- inherit_graph_20.png | Bin 2546 -> 2168 bytes inherit_graph_21.map | 2 +- inherit_graph_21.md5 | 2 +- inherit_graph_21.png | Bin 1567 -> 1830 bytes inherit_graph_22.map | 2 +- inherit_graph_22.md5 | 2 +- inherit_graph_22.png | Bin 2384 -> 2063 bytes inherit_graph_23.map | 2 +- inherit_graph_23.md5 | 2 +- inherit_graph_23.png | Bin 2360 -> 2336 bytes inherit_graph_24.map | 3 + inherit_graph_24.md5 | 1 + inherit_graph_24.png | Bin 0 -> 2783 bytes inherit_graph_25.map | 3 + inherit_graph_25.md5 | 1 + inherit_graph_25.png | Bin 0 -> 1890 bytes inherit_graph_26.map | 3 + inherit_graph_26.md5 | 1 + inherit_graph_26.png | Bin 0 -> 2841 bytes inherit_graph_27.map | 4 + inherit_graph_27.md5 | 1 + inherit_graph_27.png | Bin 0 -> 3598 bytes inherit_graph_28.map | 3 + inherit_graph_28.md5 | 1 + inherit_graph_28.png | Bin 0 -> 2546 bytes inherit_graph_29.map | 3 + inherit_graph_29.md5 | 1 + inherit_graph_29.png | Bin 0 -> 1567 bytes inherit_graph_3.map | 2 +- inherit_graph_3.md5 | 2 +- inherit_graph_3.png | Bin 1858 -> 2312 bytes inherit_graph_30.map | 3 + inherit_graph_30.md5 | 1 + inherit_graph_30.png | Bin 0 -> 2384 bytes inherit_graph_31.map | 3 + inherit_graph_31.md5 | 1 + inherit_graph_31.png | Bin 0 -> 2360 bytes inherit_graph_4.map | 2 +- inherit_graph_4.md5 | 2 +- inherit_graph_4.png | Bin 2050 -> 1858 bytes inherit_graph_5.map | 2 +- inherit_graph_5.md5 | 2 +- inherit_graph_5.png | Bin 1537 -> 2050 bytes inherit_graph_6.map | 2 +- inherit_graph_6.md5 | 2 +- inherit_graph_6.png | Bin 3880 -> 1537 bytes inherit_graph_7.map | 2 +- inherit_graph_7.md5 | 2 +- inherit_graph_7.png | Bin 1910 -> 3880 bytes inherit_graph_8.map | 2 +- inherit_graph_8.md5 | 2 +- inherit_graph_8.png | Bin 2037 -> 1910 bytes inherit_graph_9.map | 2 +- inherit_graph_9.md5 | 2 +- inherit_graph_9.png | Bin 1985 -> 2037 bytes inherits.html | 93 ++- loader_8hpp_source.html | 81 +++ locator_8hpp_source.html | 2 +- menudata.js | 34 +- namespaceentt.html | 131 +++- namespacemembers.html | 7 +- namespacemembers_func.html | 4 +- namespacemembers_type.html | 5 +- namespacemembers_vars.html | 2 +- namespaces.html | 2 +- process_8hpp_source.html | 95 +++ registry_8hpp_source.html | 68 +- scheduler_8hpp_source.html | 91 +++ search/all_0.js | 7 +- search/all_1.js | 2 +- search/all_10.js | 4 +- search/all_11.js | 3 +- search/all_12.js | 8 +- search/all_2.js | 7 +- search/all_3.js | 6 +- search/all_4.js | 3 +- search/all_5.js | 1 + search/all_6.js | 2 +- search/all_7.js | 5 +- search/all_9.js | 3 +- search/all_b.js | 13 +- search/all_c.js | 5 + search/all_d.js | 16 +- search/all_e.js | 12 +- search/all_f.js | 3 +- search/classes_0.js | 5 +- search/classes_1.js | 5 +- search/classes_2.js | 4 +- search/classes_3.js | 8 +- search/classes_4.js | 6 +- search/classes_5.js | 2 +- search/classes_6.js | 2 +- search/classes_7.js | 13 +- search/classes_8.js | 6 +- search/classes_9.html | 26 + search/classes_9.js | 13 + search/classes_a.html | 26 + search/classes_a.js | 5 + search/functions_0.js | 7 +- search/functions_1.js | 3 +- search/functions_10.html | 26 + search/functions_10.js | 8 + search/functions_2.js | 7 +- search/functions_3.js | 4 +- search/functions_4.js | 2 +- search/functions_5.js | 2 +- search/functions_6.js | 2 +- search/functions_7.js | 9 +- search/functions_8.js | 5 +- search/functions_9.js | 20 +- search/functions_a.js | 15 +- search/functions_b.js | 14 +- search/functions_c.js | 10 +- search/functions_d.js | 6 +- search/functions_e.js | 13 +- search/functions_f.html | 26 + search/functions_f.js | 6 + search/related_1.js | 2 +- search/related_2.html | 26 + search/related_2.js | 4 + search/searchdata.js | 8 +- search/typedefs_1.js | 4 +- search/typedefs_4.js | 3 +- search/typedefs_5.js | 3 +- search/typedefs_6.js | 3 +- search/typedefs_7.js | 3 +- search/typedefs_8.js | 2 +- search/typedefs_9.js | 3 +- search/typedefs_a.js | 4 +- search/typedefs_b.js | 4 +- search/typedefs_c.js | 3 +- search/typedefs_d.html | 26 + search/typedefs_d.js | 4 + search/variables_0.js | 3 +- search/variables_2.js | 3 +- sigh_8hpp_source.html | 37 +- signal_8hpp_source.html | 29 +- sparse__set_8hpp_source.html | 50 +- structentt_1_1Actor-members.html | 97 +++ structentt_1_1Actor.html | 581 ++++++++++++++++ ...entt_1_1Emitter_1_1Connection-members.html | 9 +- structentt_1_1Emitter_1_1Connection.html | 22 +- structentt_1_1ProcessAdaptor-members.html | 95 +++ structentt_1_1ProcessAdaptor.html | 274 ++++++++ structentt_1_1ProcessAdaptor__coll__graph.map | 3 + structentt_1_1ProcessAdaptor__coll__graph.md5 | 1 + structentt_1_1ProcessAdaptor__coll__graph.png | Bin 0 -> 10957 bytes ...entt_1_1ProcessAdaptor__inherit__graph.map | 3 + ...entt_1_1ProcessAdaptor__inherit__graph.md5 | 1 + ...entt_1_1ProcessAdaptor__inherit__graph.png | Bin 0 -> 10957 bytes structentt_1_1ServiceLocator-members.html | 2 +- structentt_1_1ServiceLocator.html | 2 +- structentt_1_1entt__traits.html | 2 +- ...its_3_01std_1_1uint16__t_01_4-members.html | 8 +- ...ntt__traits_3_01std_1_1uint16__t_01_4.html | 15 +- ...its_3_01std_1_1uint32__t_01_4-members.html | 8 +- ...ntt__traits_3_01std_1_1uint32__t_01_4.html | 15 +- ...its_3_01std_1_1uint64__t_01_4-members.html | 8 +- ...ntt__traits_3_01std_1_1uint64__t_01_4.html | 15 +- traits_8hpp_source.html | 14 +- view_8hpp_source.html | 82 +-- 317 files changed, 8482 insertions(+), 2145 deletions(-) create mode 100644 actor_8hpp_source.html create mode 100644 cache_8hpp_source.html create mode 100644 classentt_1_1HashedString-members.html create mode 100644 classentt_1_1HashedString.html create mode 100644 classentt_1_1Process-members.html create mode 100644 classentt_1_1Process.html create mode 100644 classentt_1_1Process__coll__graph.map create mode 100644 classentt_1_1Process__coll__graph.md5 create mode 100644 classentt_1_1Process__coll__graph.png create mode 100644 classentt_1_1Process__inherit__graph.map create mode 100644 classentt_1_1Process__inherit__graph.md5 create mode 100644 classentt_1_1Process__inherit__graph.png create mode 100644 classentt_1_1ResourceCache-members.html create mode 100644 classentt_1_1ResourceCache.html create mode 100644 classentt_1_1ResourceHandle-members.html create mode 100644 classentt_1_1ResourceHandle.html create mode 100644 classentt_1_1ResourceLoader-members.html create mode 100644 classentt_1_1ResourceLoader.html create mode 100644 classentt_1_1Scheduler-members.html create mode 100644 classentt_1_1Scheduler.html create mode 100644 dir_721f6154dba3c88bcdead5f446bce319.html create mode 100644 dir_85dbee8884f1b3a817fa7eff8dff73ec.html create mode 100644 functions_func_0x7e.html create mode 100644 functions_func_b.html create mode 100644 functions_func_c.html create mode 100644 functions_func_d.html create mode 100644 functions_func_e.html create mode 100644 functions_func_f.html create mode 100644 functions_func_g.html create mode 100644 functions_func_h.html create mode 100644 functions_func_l.html create mode 100644 functions_func_o.html create mode 100644 functions_func_p.html create mode 100644 functions_func_r.html create mode 100644 functions_func_s.html create mode 100644 functions_func_t.html create mode 100644 functions_func_u.html create mode 100644 functions_func_v.html create mode 100644 handle_8hpp_source.html create mode 100644 hashed__string_8hpp_source.html create mode 100644 inherit_graph_24.map create mode 100644 inherit_graph_24.md5 create mode 100644 inherit_graph_24.png create mode 100644 inherit_graph_25.map create mode 100644 inherit_graph_25.md5 create mode 100644 inherit_graph_25.png create mode 100644 inherit_graph_26.map create mode 100644 inherit_graph_26.md5 create mode 100644 inherit_graph_26.png create mode 100644 inherit_graph_27.map create mode 100644 inherit_graph_27.md5 create mode 100644 inherit_graph_27.png create mode 100644 inherit_graph_28.map create mode 100644 inherit_graph_28.md5 create mode 100644 inherit_graph_28.png create mode 100644 inherit_graph_29.map create mode 100644 inherit_graph_29.md5 create mode 100644 inherit_graph_29.png create mode 100644 inherit_graph_30.map create mode 100644 inherit_graph_30.md5 create mode 100644 inherit_graph_30.png create mode 100644 inherit_graph_31.map create mode 100644 inherit_graph_31.md5 create mode 100644 inherit_graph_31.png create mode 100644 loader_8hpp_source.html create mode 100644 process_8hpp_source.html create mode 100644 scheduler_8hpp_source.html create mode 100644 search/classes_9.html create mode 100644 search/classes_9.js create mode 100644 search/classes_a.html create mode 100644 search/classes_a.js create mode 100644 search/functions_10.html create mode 100644 search/functions_10.js create mode 100644 search/functions_f.html create mode 100644 search/functions_f.js create mode 100644 search/related_2.html create mode 100644 search/related_2.js create mode 100644 search/typedefs_d.html create mode 100644 search/typedefs_d.js create mode 100644 structentt_1_1Actor-members.html create mode 100644 structentt_1_1Actor.html create mode 100644 structentt_1_1ProcessAdaptor-members.html create mode 100644 structentt_1_1ProcessAdaptor.html create mode 100644 structentt_1_1ProcessAdaptor__coll__graph.map create mode 100644 structentt_1_1ProcessAdaptor__coll__graph.md5 create mode 100644 structentt_1_1ProcessAdaptor__coll__graph.png create mode 100644 structentt_1_1ProcessAdaptor__inherit__graph.map create mode 100644 structentt_1_1ProcessAdaptor__inherit__graph.md5 create mode 100644 structentt_1_1ProcessAdaptor__inherit__graph.png diff --git a/README_8md_source.html b/README_8md_source.html index 57d69017b..4acb6f77b 100644 --- a/README_8md_source.html +++ b/README_8md_source.html @@ -22,7 +22,7 @@
entt -  2.1.0 +  2.2.0
@@ -63,7 +63,7 @@ $(function() {
README.md
-
1 # EnTT Framework
2 
3 [![Build Status](https://travis-ci.org/skypjack/entt.svg?branch=master)](https://travis-ci.org/skypjack/entt)
4 [![Build status](https://ci.appveyor.com/api/projects/status/rvhaabjmghg715ck?svg=true)](https://ci.appveyor.com/project/skypjack/entt)
5 [![Coverage Status](https://coveralls.io/repos/github/skypjack/entt/badge.svg?branch=master)](https://coveralls.io/github/skypjack/entt?branch=master)
6 [![Donate](https://img.shields.io/badge/Donate-PayPal-green.svg)](https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=W2HF9FESD5LJY&lc=IT&item_name=Michele%20Caini&currency_code=EUR&bn=PP%2dDonationsBF%3abtn_donateCC_LG%2egif%3aNonHosted)
7 
8 # Introduction
9 
10 `EnTT` is a header-only, tiny and easy to use framework written in modern
11 C++.<br/>
12 It was originally designed entirely around an architectural pattern called _ECS_
13 that is used mostly in game development. For further details:
14 
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)
18 
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_.
23 
24 ## The framework
25 
26 `EnTT` was written initially as a faster alternative to other well known and
27 open source entity-component systems. Nowadays the `EnTT` framework is moving
28 its first steps. Much more will come in the future and hopefully I'm going to
29 work on it for a long time.<br/>
30 Requests for feature, PR, suggestions ad feedback are highly appreciated.
31 
32 If you find you can help me and want to contribute to the `EnTT` framework with
33 your experience or you do want to get part of the project for some other
34 reason, feel free to contact me directly (you can find the mail in the
35 [profile](https://github.com/skypjack)).<br/>
36 I can't promise that each and every contribution will be accepted, but I can
37 assure that I'll do my best to take them all seriously.
38 
39 ### State of the art
40 
41 Here is a brief list of what it offers today:
42 
43 * Statically generated integer identifiers for types (assigned either at
44 compile-time or at runtime).
45 * An incredibly fast entity-component system based on sparse sets, with its own
46 views and a _pay for what you use_ policy to adjust performance and memory
47 pressure according to the users' requirements.
48 * Signal handlers of any type, delegates and an event bus.
49 * A general purpose event emitter, that is a CRTP idiom based class template.
50 * An event dispatcher for immediate and delayed events to integrate in loops.
51 * The smallest and most basic implementation of a service locator ever seen.
52 * ...
53 * Any other business.
54 
55 Consider it a work in progress. For more details and an updated list, please
56 refer to the [online documentation](https://skypjack.github.io/entt/).
57 
58 ### A note about the README
59 
60 The README file stays true to the original project and it describes only the
61 entity-component system. However, the whole API is fully documented in-code and
62 the [online documentation](https://skypjack.github.io/entt/) contains much
63 more.<br/>
64 Continue reading to know how the core part of the project works or follow the
65 link above to take a look at the API reference for all other available classes.
66 
67 ## Code Example
68 
69 ```cpp
70 #include <entt/entt.hpp>
71 #include <cstdint>
72 
73 struct Position {
74  float x;
75  float y;
76 };
77 
78 struct Velocity {
79  float dx;
80  float dy;
81 };
82 
83 void update(entt::DefaultRegistry &registry) {
84  auto view = registry.view<Position, Velocity>();
85 
86  for(auto entity: view) {
87  // gets only the components that are going to be used ...
88 
89  auto &velocity = view.get<Velocity>(entity);
90 
91  velocity.dx = 0.;
92  velocity.dy = 0.;
93 
94  // ...
95  }
96 }
97 
98 void update(std::uint64_t dt, entt::DefaultRegistry &registry) {
99  registry.view<Position, Velocity>().each([dt](auto entity, auto &position, auto &velocity) {
100  // gets all the components of the view at once ...
101 
102  position.x += velocity.dx * dt;
103  position.y += velocity.dy * dt;
104 
105  // ...
106  });
107 }
108 
109 int main() {
110  entt::DefaultRegistry registry;
111  std::uint64_t dt = 16;
112 
113  for(auto i = 0; i < 10; ++i) {
114  auto entity = registry.create(Position{i * 1.f, i * 1.f});
115  if(i % 2 == 0) { registry.assign<Velocity>(entity, i * .1f, i * .1f); }
116  }
117 
118  update(dt, registry);
119  update(registry);
120 
121  // ...
122 }
123 ```
124 
125 ## Motivation
126 
127 I started working on `EnTT` because of the wrong reason: my goal was to design
128 an entity-component system that beated another well known open source solution
129 in terms of performance.<br/>
130 I did it, of course, but it wasn't much satisfying. Actually it wasn't
131 satisfying at all. The fastest and nothing more, fairly little indeed. When I
132 realized it, I tried hard to keep intact the great performance of `EnTT` and to
133 add all the features I wanted to see in *my* entity-component system at the same
134 time.
135 
136 Today `EnTT` is finally what I was looking for: still faster than its
137 _competitors_, a really good API and an amazing set of features. And even more,
138 of course.
139 
140 ## Performance
141 
142 As it stands right now, `EnTT` is just fast enough for my requirements if
143 compared to my first choice (that was already amazingly fast indeed).<br/>
144 Here is a comparision between the two (both of them compiled with GCC 7.2.0 on a
145 Dell XPS 13 out of the mid 2014):
146 
147 | Benchmark | EntityX (experimental/compile_time) | EnTT |
148 |-----------|-------------|-------------|
149 | Creating 10M entities | 0.128881s | **0.0408754s** |
150 | Destroying 10M entities | **0.0531374s** | 0.0545839s |
151 | Iterating over 10M entities, unpacking one component, standard view | 0.010661s | **1.58e-07s** |
152 | Iterating over 10M entities, unpacking two components, standard view | **0.0112664s** | 0.0840068s |
153 | Iterating over 10M entities, unpacking two components, standard view, half of the entities have all the components | **0.0077951s** | 0.042168s |
154 | Iterating over 10M entities, unpacking two components, standard view, one of the entities has all the components | 0.00713398s | **8.93e-07s** |
155 | Iterating over 10M entities, unpacking two components, persistent view | 0.0112664s | **5.68e-07s** |
156 | Iterating over 10M entities, unpacking five components, standard view | **0.00905084s** | 0.137757s |
157 | Iterating over 10M entities, unpacking five components, persistent view | 0.00905084s | **2.9e-07s** |
158 | Iterating over 10M entities, unpacking ten components, standard view | **0.0104708s** | 0.388602s |
159 | Iterating over 10M entities, unpacking ten components, standard view, half of the entities have all the components | **0.00899859s** | 0.200752s |
160 | Iterating over 10M entities, unpacking ten components, standard view, one of the entities has all the components | 0.00700349s | **2.565e-06s** |
161 | Iterating over 10M entities, unpacking ten components, persistent view | 0.0104708s | **6.23e-07s** |
162 | Sort 150k entities, one component | - | **0.0080046s** |
163 | Sort 150k entities, match two components | - | **0.00608322s** |
164 
165 `EnTT` includes its own tests and benchmarks. See
166 [benchmark.cpp](https://github.com/skypjack/entt/blob/master/test/benchmark.cpp)
167 for further details.<br/>
168 On Github users can find also a
169 [benchmark suite](https://github.com/abeimler/ecs_benchmark) that compares a
170 bunch of different projects, one of which is `EnTT`.
171 
172 Of course, probably I'll try to get out of `EnTT` more features and better
173 performance in the future, mainly for fun.<br/>
174 If you want to contribute and/or have any suggestion, feel free to make a PR or
175 open an issue to discuss your idea.
176 
177 # Build Instructions
178 
179 ## Requirements
180 
181 To be able to use `EnTT`, users must provide a full-featured compiler that
182 supports at least C++14.<br/>
183 The requirements below are mandatory to compile the tests and to extract the
184 documentation:
185 
186 * CMake version 3.2 or later.
187 * Doxygen version 1.8 or later.
188 
189 ## Library
190 
191 `EnTT` is a header-only library. This means that including the `entt.hpp`
192 header is enough to include the whole framework and use it. For those who are
193 interested only in the entity-component system, consider to include the sole
194 `entity/registry.hpp` header instead.<br/>
195 It's a matter of adding the following line to the top of a file:
196 
197 ```cpp
198 #include <entt/entt.hpp>
199 ```
200 
201 Use the line below to include only the entity-component system instead:
202 
203 ```cpp
204 #include <entt/entity/registry.hpp>
205 ```
206 
207 Then pass the proper `-I` argument to the compiler to add the `src` directory to
208 the include paths.
209 
210 ## Documentation
211 
212 The documentation is based on [doxygen](http://www.stack.nl/~dimitri/doxygen/).
213 To build it:
214 
215  $ cd build
216  $ cmake ..
217  $ make docs
218 
219 The API reference will be created in HTML format within the directory
220 `build/docs/html`. To navigate it with your favorite browser:
221 
222  $ cd build
223  $ your_favorite_browser docs/html/index.html
224 
225 The API reference is also available [online](https://skypjack.github.io/entt/)
226 for the latest version.
227 
228 ## Tests
229 
230 To compile and run the tests, `EnTT` requires *googletest*.<br/>
231 `cmake` will download and compile the library before to compile anything else.
232 
233 To build the tests:
234 
235 * `$ cd build`
236 * `$ cmake ..`
237 * `$ make`
238 * `$ make test`
239 
240 To build the benchmarks, use the following line instead:
241 
242 * `$ cmake -DCMAKE_BUILD_TYPE=Release ..`
243 
244 Benchmarks are compiled only in release mode currently.
245 
246 # Crash Course
247 
248 ## Design choices
249 
250 `EnTT` is entirely designed around the principle that users have to pay only for
251 what they want.
252 
253 When it comes to use an entity-componet system, the tradeoff is usually between
254 performance and memory usage. The faster it is, the more memory it uses.
255 However, slightly worse performance along non-critical paths are the right price
256 to pay to reduce memory usage and I've always wondered why this kind of tools do
257 not leave me the choice.<br/>
258 `EnTT` follows a completely different approach. It squezees the best from the
259 basic data structures and gives users the possibility to pay more for higher
260 performance where needed.<br/>
261 The disadvantage of this approach is that users need to know the systems they
262 are working on and the tools they are using. Otherwise, the risk to ruin the
263 performance along critical paths is high.
264 
265 So far, this choice has proved to be a good one and I really hope it can be for
266 many others besides me.
267 
268 ## Vademecum
269 
270 The `Registry` to store, the `View`s to iterate. That's all.
271 
272 An entity (the _E_ of an _ECS_) is an opaque identifier that users should just
273 use as-is and store around if needed. Do not try to inspect an entity
274 identifier, its type can change in future and a registry offers all the
275 functionalities to query them out-of-the-box. The underlying type of an entity
276 (either `std::uint16_t`, `std::uint32_t` or `std::uint64_t`) can be specified
277 when defining a registry (actually the DefaultRegistry is nothing more than a
278 Registry where the type of the entities is `std::uint32_t`).<br/>
279 Components (the _C_ of an _ECS_) should be plain old data structures or more
280 complex and moveable data structures with a proper constructor. Actually, the
281 sole requirement of a component type is that it must be both move constructible
282 and move assignable. They are list initialized by using the parameters provided
283 to construct the component itself. No need to register components or their types
284 neither with the registry nor with the entity-component system at all.<br/>
285 Systems (the _S_ of an _ECS_) are just plain functions, functors, lambdas or
286 whatever the users want. They can accept a Registry, a View or a PersistentView
287 and use them the way they prefer. No need to register systems or their types
288 neither with the registry nor with the entity-component system at all.
289 
290 The following sections will explain in short how to use the entity-component
291 system, the core part of the whole framework.<br/>
292 In fact, the framework is composed of many other classes in addition to those
293 describe below. For more details, please refer to the
294 [online documentation](https://skypjack.github.io/entt/).
295 
296 ## The Registry, the Entity and the Component
297 
298 A registry is used to store and manage entities as well as to create views to
299 iterate the underlying data structures.<br/>
300 Registry is a class template that lets the users decide what's the preferred
301 type to represent an entity. Because `std::uint32_t` is large enough for almost
302 all the cases, there exists also an alias named DefaultRegistry for
303 `Registry<std::uint32_t>`.
304 
305 Entities are represented by _entitiy identifiers_. An entity identifier is an
306 opaque type that users should not inspect or modify in any way. It carries
307 information about the entity itself and its version.
308 
309 A registry can be used both to construct and to destroy entities:
310 
311 ```cpp
312 // constructs a naked entity with no components ad returns its identifier
313 auto entity = registry.create();
314 
315 // constructs an entity and assigns it default-initialized components
316 auto another = registry.create<Position, Velocity>();
317 
318 // destroys an entity and all its components
319 registry.destroy(entity);
320 ```
321 
322 Once an entity is deleted, the registry can freely reuse it internally with a
323 slightly different identifier. In particular, the version of an entity is
324 increased each and every time it's destroyed.<br/>
325 In case entity identifiers are stored around, the registry offers all the
326 functionalities required to test them and get out of the them all the
327 information they carry:
328 
329 ```cpp
330 // returns true if the entity is still valid, false otherwise
331 bool b = registry.valid(entity);
332 
333 // gets the version contained in the entity identifier
334 auto version = registry.version(entity);
335 
336 // gets the actual version for the given entity
337 auto curr = registry.current(entity);
338 ```
339 
340 Components can be assigned to or removed from entities at any time with a few
341 calls to member functions of the registry. As for the entities, the registry
342 offers also a set of functionalities users can use to work with the components.
343 
344 The `assign` member function template creates, initializes and assigns to an
345 entity the given component. It accepts a variable number of arguments that are
346 used to construct the component itself if present:
347 
348 ```cpp
349 registry.assign<Position>(entity, 0., 0.);
350 
351 // ...
352 
353 auto &velocity = registry.assign<Velocity>(entity);
354 velocity.dx = 0.;
355 velocity.dy = 0.;
356 ```
357 
358 If the entity already has the given component, the `replace` member function
359 template can be used to replace it:
360 
361 ```cpp
362 registry.replace<Position>(entity, 0., 0.);
363 
364 // ...
365 
366 auto &velocity = registry.replace<Velocity>(entity);
367 velocity.dx = 0.;
368 velocity.dy = 0.;
369 ```
370 
371 In case users want to assign a component to an entity, but it's unknown whether
372 the entity already has it or not, `accomodate` does the work in a single call
373 (there is a performance penalty to pay for that mainly due to the fact that it
374 must check if `entity` already has the given component or not):
375 
376 ```cpp
377 registry.accomodate<Position>(entity, 0., 0.);
378 
379 // ...
380 
381 auto &velocity = registry.accomodate<Velocity>(entity);
382 velocity.dx = 0.;
383 velocity.dy = 0.;
384 ```
385 
386 Note that `accomodate` is a sliglhty faster alternative for the following
387 `if`/`else` statement and nothing more:
388 
389 ```cpp
390 if(registry.has<Comp>(entity)) {
391  registry.replace<Comp>(entity, arg1, argN);
392 } else {
393  registry.assign<Comp>(entity, arg1, argN);
394 }
395 ```
396 
397 As already shown, if in doubt about whether or not an entity has one or more
398 components, the `has` member function template may be useful:
399 
400 ```cpp
401 bool b = registry.has<Position, Velocity>(entity);
402 ```
403 
404 On the other side, if the goal is to delete a single component, the `remove`
405 member function template is the way to go when it's certain that the entity owns
406 a copy of the component:
407 
408 ```cpp
409 registry.remove<Position>(entity);
410 ```
411 
412 Otherwise consider to use the `reset` member function. It behaves similarly to
413 `remove` but with a strictly defined behaviour (and a performance penalty is the
414 price to pay for that). In particular it removes the component if and only if it
415 exists, otherwise it returns safely to the caller:
416 
417 ```cpp
418 registry.reset<Position>(entity);
419 ```
420 
421 There exist also two other _versions_ of the `reset` member function:
422 
423 * If no entity is passed to it, `reset` will remove the given component from
424 each entity that has it:
425 
426  ```cpp
427  registry.reset<Position>();
428  ```
429 
430 * If neither the entity nor the component are specified, all the entities and
431 their components are destroyed:
432 
433  ```cpp
434  registry.reset();
435  ```
436 
437 Finally, references to components can be retrieved by just doing this:
438 
439 ```cpp
440 // either a non-const reference ...
441 DefaultRegistry registry;
442 auto &position = registry.get<Position>(entity);
443 
444 // ... or a const one
445 const auto &cregistry = registry;
446 const auto &position = cregistry.get<Position>(entity);
447 ```
448 
449 The `get` member function template gives direct access to the component of an
450 entity stored in the underlying data structures of the registry.
451 
452 ### Sorting: is it possible?
453 
454 It goes without saying that sorting entities and components is possible with
455 `EnTT`.<br/>
456 In fact, there are two functions that respond to slightly different needs:
457 
458 * Components can be sorted directly:
459 
460  ```cpp
461  registry.sort<Renderable>([](const auto &lhs, const auto &rhs) {
462  return lhs.z < rhs.z;
463  });
464  ```
465 
466 * Components can be sorted according to the order imposed by another component:
467 
468  ```cpp
469  registry.sort<Movement, Physics>();
470  ```
471 
472  In this case, instances of `Movement` are arranged in memory so that cache
473  misses are minimized when the two components are iterated together.
474 
475 ## View: to persist or not to persist?
476 
477 There are mainly two kinds of views: standard (also known as View) and
478 persistent (alsa known as PersistentView).<br/>
479 Both of them have pros and cons to take in consideration. In particular:
480 
481 * Standard views:
482 
483  Pros:
484  * They work out-of-the-box and don't require any dedicated data
485  structure.
486  * Creating and destroying them isn't expensive at all because they don't
487  have any type of initialization.
488  * They are the best tool to iterate single components.
489  * They are the best tool to iterate multiple components at once when
490  tags are involved or one of the component is assigned to a
491  significantly low number of entities.
492  * They don't affect any other operations of the registry.
493 
494  Cons:
495  * Their performance tend to degenerate when the number of components
496  to iterate grows up and the most of the entities have all of them.
497 
498 * Persistent views:
499 
500  Pros:
501  * Once prepared, creating and destroying them isn't expensive at all
502  because they don't have any type of initialization.
503  * They are the best tool to iterate multiple components at once when
504  the most of the entities have all of them.
505 
506  Cons:
507  * They have dedicated data structures and thus affect the memory
508  pressure to a minimal extent.
509  * If not previously prepared, the first time they are used they go
510  through an initialization step that could take a while.
511  * They affect to a minimum the creation and destruction of entities and
512  components. In other terms: the more persistent views there will be,
513  the less performing will be creating and destroying entities and
514  components.
515 
516 To sum up and as a rule of thumb, use a standard view:
517 * To iterate entities for a single component.
518 * To iterate entities for multiple components when a significantly low
519  number of entities have one of the components.
520 * In all those cases where a persistent view would give a boost to
521  performance but the iteration isn't performed frequently.
522 
523 Use a persistent view in all the other cases.
524 
525 To easily iterate entities, all the views offer the common `begin` and `end`
526 member functions that allow users to use a view in a typical range-for
527 loop.<br/>
528 Continue reading for more details or refer to the
529 [official documentation](https://skypjack.github.io/entt/).
530 
531 ### Standard View
532 
533 A standard view behaves differently if it's constructed for a single component
534 or if it has been requested to iterate multiple components. Even the API is
535 different in the two cases.<br/>
536 All that they share is the way they are created by means of a registry:
537 
538 ```cpp
539 // single component standard view
540 auto single = registry.view<Position>();
541 
542 // multi component standard view
543 auto multi = registry.view<Position, Velocity>();
544 ```
545 
546 For all that remains, it's worth discussing them separately.<br/>
547 
548 #### Single component standard view
549 
550 Single component standard views are specialized in order to give a boost in
551 terms of performance in all the situation. This kind of views can access the
552 underlying data structures directly and avoid superflous checks.<br/>
553 They offer a bunch of functionalities to get the number of entities they are
554 going to return and a raw access to the entity list as well as to the component
555 list.<br/>
556 Refer to the [official documentation](https://skypjack.github.io/entt/) for all
557 the details.
558 
559 There is no need to store views around for they are extremely cheap to
560 construct, even though they can be copied without problems and reused
561 freely. In fact, they return newly created and correctly initialized iterators
562 whenever `begin` or `end` are invoked.<br/>
563 To iterate a single component standard view, either use it in range-for loop:
564 
565 ```cpp
566 auto view = registry.view<Renderable>();
567 
568 for(auto entity: view) {
569  auto &renderable = view.get(entity);
570 
571  // ...
572 }
573 ```
574 
575 Or rely on the `each` member function to iterate entities and get all their
576 components at once:
577 
578 ```cpp
579 registry.view<Renderable>().each([](auto entity, auto &renderable) {
580  // ...
581 });
582 ```
583 
584 Performance are more or less the same. The best approach depends mainly on
585 whether all the components have to be accessed or not.
586 
587 **Note**: prefer the `get` member function of a view instead of the `get` member
588 function template of a registry during iterations, if possible. However, keep in
589 mind that it works only with the components of the view itself.
590 
591 #### Multi component standard view
592 
593 Multi component standard views iterate entities that have at least all the given
594 components in their bags. During construction, these views look at the number
595 of entities available for each component and pick up a reference to the smallest
596 set of candidates in order to speed up iterations.<br/>
597 They offer fewer functionalities than their companion views for single
598 component, the most important of which can be used to reset the view and refresh
599 the reference to the set of candidate entities to iterate.<br/>
600 Refer to the [official documentation](https://skypjack.github.io/entt/) for all
601 the details.
602 
603 There is no need to store views around for they are extremely cheap to
604 construct, even though they can be copied without problems and reused
605 freely. In fact, they return newly created and correctly initialized iterators
606 whenever `begin` or `end` are invoked.<br/>
607 To iterate a multi component standard view, either use it in range-for loop:
608 
609 ```cpp
610 auto view = registry.view<Position, Velocity>();
611 
612 for(auto entity: view) {
613  auto &position = view.get<Position>(entity);
614  auto &velocity = view.get<Velocity>(entity);
615 
616  // ...
617 }
618 ```
619 
620 Or rely on the `each` member function to iterate entities and get all their
621 components at once:
622 
623 ```cpp
624 registry.view<Position, Velocity>().each([](auto entity, auto &position, auto &velocity) {
625  // ...
626 });
627 ```
628 
629 Performance are more or less the same. The best approach depends mainly on
630 whether all the components have to be accessed or not.
631 
632 **Note**: prefer the `get` member function of a view instead of the `get` member
633 function template of a registry during iterations, if possible. However, keep in
634 mind that it works only with the components of the view itself.
635 
636 ### Persistent View
637 
638 A persistent view returns all the entities and only the entities that have at
639 least the given components. Moreover, it's guaranteed that the entity list is
640 thightly packed in memory for fast iterations.<br/>
641 In general, persistent views don't stay true to the order of any set of
642 components unless users explicitly sort them.
643 
644 Persistent views can be used only to iterate multiple components. Create them
645 as it follows:
646 
647 ```cpp
648 auto view = registry.persistent<Position, Velocity>();
649 ```
650 
651 There is no need to store views around for they are extremely cheap to
652 construct, even though they can be copied without problems and reused
653 freely. In fact, they return newly created and correctly initialized iterators
654 whenever `begin` or `end` are invoked.<br/>
655 That being said, persistent views perform an initialization step the very first
656 time they are constructed and this could be quite costly. To avoid it, consider
657 asking to the registry to _prepare_ them when no entities have been created yet:
658 
659 ```cpp
660 registry.prepare<Position, Velocity>();
661 ```
662 
663 If the registry is empty, preparation is extremely fast. Moreover the `prepare`
664 member function template is idempotent. Feel free to invoke it even more than
665 once: if the view has been alreadt prepared before, the function returns
666 immediately and does nothing.
667 
668 A persistent view offers a bunch of functionalities to get the number of
669 entities it's going to return, a raw access to the entity list and the
670 possibility to sort the underlying data structures according to the order of one
671 of the components for which it has been constructed.<br/>
672 Refer to the [official documentation](https://skypjack.github.io/entt/) for all
673 the details.
674 
675 To iterate a persistent view, either use it in range-for loop:
676 
677 ```cpp
678 auto view = registry.persistent<Position, Velocity>();
679 
680 for(auto entity: view) {
681  auto &position = view.get<Position>(entity);
682  auto &velocity = view.get<Velocity>(entity);
683 
684  // ...
685 }
686 ```
687 
688 Or rely on the `each` member function to iterate entities and get all their
689 components at once:
690 
691 ```cpp
692 registry.persistent<Position, Velocity>().each([](auto entity, auto &position, auto &velocity) {
693  // ...
694 });
695 ```
696 
697 Performance are more or less the same. The best approach depends mainly on
698 whether all the components have to be accessed or not.
699 
700 **Note**: prefer the `get` member function of a view instead of the `get` member
701 function template of a registry during iterations, if possible. However, keep in
702 mind that it works only with the components of the view itself.
703 
704 ## Side notes
705 
706 * Entity identifiers are numbers and nothing more. They are not classes and they
707  have no member functions at all. As already mentioned, do no try to inspect or
708  modify an entity descriptor in any way.
709 
710 * As shown in the examples above, the preferred way to get references to the
711  components while iterating a view is by using the view itself. It's a faster
712  alternative to the `get` member function template that is part of the API of
713  the Registry. That's because the registry must ensure that a pool for the
714  given component exists before to use it; on the other side, views force the
715  construction of the pools for all their components and access them directly,
716  thus avoiding all the checks.
717 
718 * Most of the _ECS_ available out there have an annoying limitation (at least
719  from my point of view): entities and components cannot be created and/or
720  deleted during iterations.<br/>
721  `EnTT` partially solves the problem with a few limitations:
722 
723  * Creating entities and components is allowed during iterations.
724  * Deleting an entity or removing its components is allowed during
725  iterations if it's the one currently returned by a view. For all the
726  other entities, destroying them or removing their components isn't
727  allowed and it can result in undefined behavior.
728 
729  Iterators are invalidated and the behaviour is undefined if an entity is
730  modified or destroyed and it's not the one currently returned by the
731  view.<br/>
732  To work around it, possible approaches are:
733 
734  * Store aside the entities and the components to be removed and perform the
735  operations at the end of the iteration.
736  * Mark entities and components with a proper tag component that indicates
737  they must be purged, then perform a second iteration to clean them up one
738  by one.
739 
740 * Views and thus their iterators aren't thread safe. Do no try to iterate a set
741  of components and modify the same set concurrently.<br/>
742  That being said, as long as a thread iterates the entities that have the
743  component `X` or assign and removes that component from a set of entities,
744  another thread can safely do the same with components `Y` and `Z` and
745  everything will work like a charm.<br/>
746  As an example, users can freely execute the rendering system and iterate the
747  renderable entities while updating a physic component concurrently on a
748  separate thread if needed.
749 
750 # Contributors
751 
752 If you want to contribute, please send patches as pull requests against the
753 branch `master`.<br/>
754 Check the
755 [contributors list](https://github.com/skypjack/entt/blob/master/AUTHORS) to see
756 who has partecipated so far.
757 
758 # License
759 
760 Code and documentation Copyright (c) 2017 Michele Caini.<br/>
761 Code released under
762 [the MIT license](https://github.com/skypjack/entt/blob/master/LICENSE).
763 Docs released under
764 [Creative Commons](https://github.com/skypjack/entt/blob/master/docs/LICENSE).
765 
766 # Donation
767 
768 Developing and maintaining `EnTT` takes some time and lots of coffee. I'd like
769 to add more and more functionalities in future and turn it in a full-featured
770 framework.<br/>
771 If you want to support this project, you can offer me an espresso. I'm from
772 Italy, we're used to turning the best coffee ever in code. If you find that
773 it's not enough, feel free to support me the way you prefer.<br/>
774 Take a look at the donation button at the top of the page for more details or
775 just click [here](https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=W2HF9FESD5LJY&lc=IT&item_name=Michele%20Caini&currency_code=EUR&bn=PP%2dDonationsBF%3abtn_donateCC_LG%2egif%3aNonHosted).
+
1 # EnTT Framework
2 
3 [![Build Status](https://travis-ci.org/skypjack/entt.svg?branch=master)](https://travis-ci.org/skypjack/entt)
4 [![Build status](https://ci.appveyor.com/api/projects/status/rvhaabjmghg715ck?svg=true)](https://ci.appveyor.com/project/skypjack/entt)
5 [![Coverage Status](https://coveralls.io/repos/github/skypjack/entt/badge.svg?branch=master)](https://coveralls.io/github/skypjack/entt?branch=master)
6 [![Donate](https://img.shields.io/badge/Donate-PayPal-green.svg)](https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=W2HF9FESD5LJY&lc=IT&item_name=Michele%20Caini&currency_code=EUR&bn=PP%2dDonationsBF%3abtn_donateCC_LG%2egif%3aNonHosted)
7 
8 # Introduction
9 
10 `EnTT` is a header-only, tiny and easy to use framework written in modern
11 C++.<br/>
12 It was originally designed entirely around an architectural pattern called _ECS_
13 that is used mostly in game development. For further details:
14 
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)
18 
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_.
23 
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.
28 
29 ## The framework
30 
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.
36 
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.
43 
44 ### State of the art
45 
46 Here is a brief list of what it offers today:
47 
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.
61 * ...
62 * Any other business.
63 
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/).
66 
67 ### A note about the README
68 
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
72 more.<br/>
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.
75 
76 ## Code Example
77 
78 ```cpp
79 #include <entt/entt.hpp>
80 #include <cstdint>
81 
82 struct Position {
83  float x;
84  float y;
85 };
86 
87 struct Velocity {
88  float dx;
89  float dy;
90 };
91 
92 void update(entt::DefaultRegistry &registry) {
93  auto view = registry.view<Position, Velocity>();
94 
95  for(auto entity: view) {
96  // gets only the components that are going to be used ...
97 
98  auto &velocity = view.get<Velocity>(entity);
99 
100  velocity.dx = 0.;
101  velocity.dy = 0.;
102 
103  // ...
104  }
105 }
106 
107 void update(std::uint64_t dt, entt::DefaultRegistry &registry) {
108  registry.view<Position, Velocity>().each([dt](auto entity, auto &position, auto &velocity) {
109  // gets all the components of the view at once ...
110 
111  position.x += velocity.dx * dt;
112  position.y += velocity.dy * dt;
113 
114  // ...
115  });
116 }
117 
118 int main() {
119  entt::DefaultRegistry registry;
120  std::uint64_t dt = 16;
121 
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); }
125  }
126 
127  update(dt, registry);
128  update(registry);
129 
130  // ...
131 }
132 ```
133 
134 ## Motivation
135 
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 I did it, of course, 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
143 time.
144 
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,
147 of course.
148 
149 ## Performance
150 
151 As it stands right now, `EnTT` is just fast enough for my requirements if
152 compared to my first choice (that was already amazingly fast indeed).<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):
155 
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 | - | **0.0084s** |
172 | Sort 150k entities, enforce permutation | - | **0.0067s** |
173 
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`.
180 
181 Of course, probably I'll try to get out of `EnTT` more features and better
182 performance in 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.
185 
186 # Build Instructions
187 
188 ## Requirements
189 
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
193 documentation:
194 
195 * CMake version 3.2 or later.
196 * Doxygen version 1.8 or later.
197 
198 ## Library
199 
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:
205 
206 ```cpp
207 #include <entt/entt.hpp>
208 ```
209 
210 Use the line below to include only the entity-component system instead:
211 
212 ```cpp
213 #include <entt/entity/registry.hpp>
214 ```
215 
216 Then pass the proper `-I` argument to the compiler to add the `src` directory to
217 the include paths.
218 
219 ## Documentation
220 
221 The documentation is based on [doxygen](http://www.stack.nl/~dimitri/doxygen/).
222 To build it:
223 
224  $ cd build
225  $ cmake ..
226  $ make docs
227 
228 The API reference will be created in HTML format within the directory
229 `build/docs/html`. To navigate it with your favorite browser:
230 
231  $ cd build
232  $ your_favorite_browser docs/html/index.html
233 
234 The API reference is also available [online](https://skypjack.github.io/entt/)
235 for the latest version.
236 
237 ## Tests
238 
239 To compile and run the tests, `EnTT` requires *googletest*.<br/>
240 `cmake` will download and compile the library before to compile anything else.
241 
242 To build the tests:
243 
244 * `$ cd build`
245 * `$ cmake ..`
246 * `$ make`
247 * `$ make test`
248 
249 To build the benchmarks, use the following line instead:
250 
251 * `$ cmake -DCMAKE_BUILD_TYPE=Release ..`
252 
253 Benchmarks are compiled only in release mode currently.
254 
255 # Crash Course
256 
257 ## Design choices
258 
259 ### A bitset-free entity-component system
260 
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 That's the reason for which users can instantiate the core class simply as:
264 
265 ```cpp
266 entt::DefaultRegistry registry;
267 ```
268 
269 In place of its more annoying and error-prone counterpart:
270 
271 ```cpp
272 entt::DefaultRegistry<Comp0, Comp1, ..., CompN> registry;
273 ```
274 
275 ### Pay per use
276 
277 `EnTT` is entirely designed around the principle that users have to pay only for
278 what they want.
279 
280 When it comes to use an entity-componet system, the tradeoff is usually between
281 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.
291 
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.
294 
295 ## Vademecum
296 
297 The `Registry` to store, the `View`s to iterate. That's all.
298 
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.
316 
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/).
322 
323 ## The Registry, the Entity and the Component
324 
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>`.
331 
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.
335 
336 A registry can be used both to construct and to destroy entities:
337 
338 ```cpp
339 // constructs a naked entity with no components ad returns its identifier
340 auto entity = registry.create();
341 
342 // constructs an entity and assigns it default-initialized components
343 auto another = registry.create<Position, Velocity>();
344 
345 // destroys an entity and all its components
346 registry.destroy(entity);
347 ```
348 
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:
355 
356 ```cpp
357 // returns true if the entity is still valid, false otherwise
358 bool b = registry.valid(entity);
359 
360 // gets the version contained in the entity identifier
361 auto version = registry.version(entity);
362 
363 // gets the actual version for the given entity
364 auto curr = registry.current(entity);
365 ```
366 
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.
370 
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:
374 
375 ```cpp
376 registry.assign<Position>(entity, 0., 0.);
377 
378 // ...
379 
380 auto &velocity = registry.assign<Velocity>(entity);
381 velocity.dx = 0.;
382 velocity.dy = 0.;
383 ```
384 
385 If the entity already has the given component, the `replace` member function
386 template can be used to replace it:
387 
388 ```cpp
389 registry.replace<Position>(entity, 0., 0.);
390 
391 // ...
392 
393 auto &velocity = registry.replace<Velocity>(entity);
394 velocity.dx = 0.;
395 velocity.dy = 0.;
396 ```
397 
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 that mainly due to the fact that it
401 must check if `entity` already has the given component or not):
402 
403 ```cpp
404 registry.accomodate<Position>(entity, 0., 0.);
405 
406 // ...
407 
408 auto &velocity = registry.accomodate<Velocity>(entity);
409 velocity.dx = 0.;
410 velocity.dy = 0.;
411 ```
412 
413 Note that `accomodate` is a sliglhty faster alternative for the following
414 `if`/`else` statement and nothing more:
415 
416 ```cpp
417 if(registry.has<Comp>(entity)) {
418  registry.replace<Comp>(entity, arg1, argN);
419 } else {
420  registry.assign<Comp>(entity, arg1, argN);
421 }
422 ```
423 
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:
426 
427 ```cpp
428 bool b = registry.has<Position, Velocity>(entity);
429 ```
430 
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:
434 
435 ```cpp
436 registry.remove<Position>(entity);
437 ```
438 
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 that). In particular it removes the component if and only if it
442 exists, otherwise it returns safely to the caller:
443 
444 ```cpp
445 registry.reset<Position>(entity);
446 ```
447 
448 There exist also two other _versions_ of the `reset` member function:
449 
450 * If no entity is passed to it, `reset` will remove the given component from
451 each entity that has it:
452 
453  ```cpp
454  registry.reset<Position>();
455  ```
456 
457 * If neither the entity nor the component are specified, all the entities and
458 their components are destroyed:
459 
460  ```cpp
461  registry.reset();
462  ```
463 
464 Finally, references to components can be retrieved simply by doing this:
465 
466 ```cpp
467 // either a non-const reference ...
468 entt::DefaultRegistry registry;
469 auto &position = registry.get<Position>(entity);
470 
471 // ... or a const one
472 const auto &cregistry = registry;
473 const auto &position = cregistry.get<Position>(entity);
474 ```
475 
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.
478 
479 ### Single instance components
480 
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
485 constructor.<br/>
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
488 their own types.
489 
490 Attaching tags to entities and removing them is trivial:
491 
492 ```cpp
493 auto player = registry.create();
494 auto camera = registry.create();
495 
496 // attaches a default-initialized tag to an entity
497 registry.attach<PlayingCharacter>(player);
498 
499 // attaches a tag to an entity and initializes it
500 registry.attach<Camera>(camera, player);
501 
502 // removes tags from their owners
503 registry.remove<PlayingCharacter>();
504 registry.remove<Camera>();
505 ```
506 
507 If in doubt about whether or not a tag has already an owner, the `has` member
508 function template may be useful:
509 
510 ```cpp
511 bool b = registry.has<PlayingCharacter>();
512 ```
513 
514 References to tags can be retrieved simply by doing this:
515 
516 ```cpp
517 // either a non-const reference ...
518 entt::DefaultRegistry registry;
519 auto &player = registry.get<PlayingCharacter>();
520 
521 // ... or a const one
522 const auto &cregistry = registry;
523 const auto &camera = cregistry.get<Camera>();
524 ```
525 
526 The `get` member function template gives direct access to the tag as stored in
527 the underlying data structures of the registry.
528 
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:
533 
534 ```cpp
535 auto player = registry.attachee<PlayingCharacter>();
536 ```
537 
538 Note that iterating tags isn't possible for obvious reasons. Tags give direct
539 access to single entities and nothing more.
540 
541 ### Sorting: is it possible?
542 
543 It goes without saying that sorting entities and components is possible with
544 `EnTT`.<br/>
545 In fact, there are two functions that respond to slightly different needs:
546 
547 * Components can be sorted directly:
548 
549  ```cpp
550  registry.sort<Renderable>([](const auto &lhs, const auto &rhs) {
551  return lhs.z < rhs.z;
552  });
553  ```
554 
555 * Components can be sorted according to the order imposed by another component:
556 
557  ```cpp
558  registry.sort<Movement, Physics>();
559  ```
560 
561  In this case, instances of `Movement` are arranged in memory so that cache
562  misses are minimized when the two components are iterated together.
563 
564 ## View: to persist or not to persist?
565 
566 There are mainly two kinds of views: standard (also known as View) and
567 persistent (alsa known as PersistentView).<br/>
568 Both of them have pros and cons to take in consideration. In particular:
569 
570 * Standard views:
571 
572  Pros:
573  * They work out-of-the-box and don't require any dedicated data
574  structure.
575  * Creating and destroying them isn't expensive at all because they don't
576  have any type of initialization.
577  * They are the best tool to iterate single components.
578  * They are the best tool to iterate multiple components at once when
579  tags are involved or one of the component is assigned to a
580  significantly low number of entities.
581  * They don't affect any other operations of the registry.
582 
583  Cons:
584  * Their performance tend to degenerate when the number of components
585  to iterate grows up and the most of the entities have all of them.
586 
587 * Persistent views:
588 
589  Pros:
590  * Once prepared, creating and destroying them isn't expensive at all
591  because they don't have any type of initialization.
592  * They are the best tool to iterate multiple components at once when
593  the most of the entities have all of them.
594 
595  Cons:
596  * They have dedicated data structures and thus affect the memory
597  pressure to a minimal extent.
598  * If not previously prepared, the first time they are used they go
599  through an initialization step that could take a while.
600  * They affect to a minimum the creation and destruction of entities and
601  components. In other terms: the more persistent views there will be,
602  the less performing will be creating and destroying entities and
603  components.
604 
605 To sum up and as a rule of thumb, use a standard view:
606 * To iterate entities for a single component.
607 * To iterate entities for multiple components when a significantly low
608  number of entities have one of the components.
609 * In all those cases where a persistent view would give a boost to
610  performance but the iteration isn't performed frequently.
611 
612 Use a persistent view in all the other cases.
613 
614 To easily iterate entities, all the views offer the common `begin` and `end`
615 member functions that allow users to use a view in a typical range-for
616 loop.<br/>
617 Continue reading for more details or refer to the
618 [official documentation](https://skypjack.github.io/entt/).
619 
620 ### Standard View
621 
622 A standard view behaves differently if it's constructed for a single component
623 or if it has been requested to iterate multiple components. Even the API is
624 different in the two cases.<br/>
625 All that they share is the way they are created by means of a registry:
626 
627 ```cpp
628 // single component standard view
629 auto single = registry.view<Position>();
630 
631 // multi component standard view
632 auto multi = registry.view<Position, Velocity>();
633 ```
634 
635 For all that remains, it's worth discussing them separately.<br/>
636 
637 #### Single component standard view
638 
639 Single component standard views are specialized in order to give a boost in
640 terms of performance in all the situation. This kind of views can access the
641 underlying data structures directly and avoid superflous checks.<br/>
642 They offer a bunch of functionalities to get the number of entities they are
643 going to return and a raw access to the entity list as well as to the component
644 list.<br/>
645 Refer to the [official documentation](https://skypjack.github.io/entt/) for all
646 the details.
647 
648 There is no need to store views around for they are extremely cheap to
649 construct, even though they can be copied without problems and reused
650 freely. In fact, they return newly created and correctly initialized iterators
651 whenever `begin` or `end` are invoked.<br/>
652 To iterate a single component standard view, either use it in range-for loop:
653 
654 ```cpp
655 auto view = registry.view<Renderable>();
656 
657 for(auto entity: view) {
658  auto &renderable = view.get(entity);
659 
660  // ...
661 }
662 ```
663 
664 Or rely on the `each` member function to iterate entities and get all their
665 components at once:
666 
667 ```cpp
668 registry.view<Renderable>().each([](auto entity, auto &renderable) {
669  // ...
670 });
671 ```
672 
673 Performance are more or less the same. The best approach depends mainly on
674 whether all the components have to be accessed or not.
675 
676 **Note**: prefer the `get` member function of a view instead of the `get` member
677 function template of a registry during iterations, if possible. However, keep in
678 mind that it works only with the components of the view itself.
679 
680 #### Multi component standard view
681 
682 Multi component standard views iterate entities that have at least all the given
683 components in their bags. During construction, these views look at the number
684 of entities available for each component and pick up a reference to the smallest
685 set of candidates in order to speed up iterations.<br/>
686 They offer fewer functionalities than their companion views for single
687 component, the most important of which can be used to reset the view and refresh
688 the reference to the set of candidate entities to iterate.<br/>
689 Refer to the [official documentation](https://skypjack.github.io/entt/) for all
690 the details.
691 
692 There is no need to store views around for they are extremely cheap to
693 construct, even though they can be copied without problems and reused
694 freely. In fact, they return newly created and correctly initialized iterators
695 whenever `begin` or `end` are invoked.<br/>
696 To iterate a multi component standard view, either use it in range-for loop:
697 
698 ```cpp
699 auto view = registry.view<Position, Velocity>();
700 
701 for(auto entity: view) {
702  auto &position = view.get<Position>(entity);
703  auto &velocity = view.get<Velocity>(entity);
704 
705  // ...
706 }
707 ```
708 
709 Or rely on the `each` member function to iterate entities and get all their
710 components at once:
711 
712 ```cpp
713 registry.view<Position, Velocity>().each([](auto entity, auto &position, auto &velocity) {
714  // ...
715 });
716 ```
717 
718 Performance are more or less the same. The best approach depends mainly on
719 whether all the components have to be accessed or not.
720 
721 **Note**: prefer the `get` member function of a view instead of the `get` member
722 function template of a registry during iterations, if possible. However, keep in
723 mind that it works only with the components of the view itself.
724 
725 ### Persistent View
726 
727 A persistent view returns all the entities and only the entities that have at
728 least the given components. Moreover, it's guaranteed that the entity list is
729 thightly packed in memory for fast iterations.<br/>
730 In general, persistent views don't stay true to the order of any set of
731 components unless users explicitly sort them.
732 
733 Persistent views can be used only to iterate multiple components. Create them
734 as it follows:
735 
736 ```cpp
737 auto view = registry.persistent<Position, Velocity>();
738 ```
739 
740 There is no need to store views around for they are extremely cheap to
741 construct, even though they can be copied without problems and reused
742 freely. In fact, they return newly created and correctly initialized iterators
743 whenever `begin` or `end` are invoked.<br/>
744 That being said, persistent views perform an initialization step the very first
745 time they are constructed and this could be quite costly. To avoid it, consider
746 asking to the registry to _prepare_ them when no entities have been created yet:
747 
748 ```cpp
749 registry.prepare<Position, Velocity>();
750 ```
751 
752 If the registry is empty, preparation is extremely fast. Moreover the `prepare`
753 member function template is idempotent. Feel free to invoke it even more than
754 once: if the view has been alreadt prepared before, the function returns
755 immediately and does nothing.
756 
757 A persistent view offers a bunch of functionalities to get the number of
758 entities it's going to return, a raw access to the entity list and the
759 possibility to sort the underlying data structures according to the order of one
760 of the components for which it has been constructed.<br/>
761 Refer to the [official documentation](https://skypjack.github.io/entt/) for all
762 the details.
763 
764 To iterate a persistent view, either use it in range-for loop:
765 
766 ```cpp
767 auto view = registry.persistent<Position, Velocity>();
768 
769 for(auto entity: view) {
770  auto &position = view.get<Position>(entity);
771  auto &velocity = view.get<Velocity>(entity);
772 
773  // ...
774 }
775 ```
776 
777 Or rely on the `each` member function to iterate entities and get all their
778 components at once:
779 
780 ```cpp
781 registry.persistent<Position, Velocity>().each([](auto entity, auto &position, auto &velocity) {
782  // ...
783 });
784 ```
785 
786 Performance are more or less the same. The best approach depends mainly on
787 whether all the components have to be accessed or not.
788 
789 **Note**: prefer the `get` member function of a view instead of the `get` member
790 function template of a registry during iterations, if possible. However, keep in
791 mind that it works only with the components of the view itself.
792 
793 ## Side notes
794 
795 * Entity identifiers are numbers and nothing more. They are not classes and they
796  have no member functions at all. As already mentioned, do no try to inspect or
797  modify an entity descriptor in any way.
798 
799 * As shown in the examples above, the preferred way to get references to the
800  components while iterating a view is by using the view itself. It's a faster
801  alternative to the `get` member function template that is part of the API of
802  the Registry. That's because the registry must ensure that a pool for the
803  given component exists before to use it; on the other side, views force the
804  construction of the pools for all their components and access them directly,
805  thus avoiding all the checks.
806 
807 * Most of the _ECS_ available out there have an annoying limitation (at least
808  from my point of view): entities and components cannot be created and/or
809  deleted during iterations.<br/>
810  `EnTT` partially solves the problem with a few limitations:
811 
812  * Creating entities and components is allowed during iterations.
813  * Deleting an entity or removing its components is allowed during
814  iterations if it's the one currently returned by a view. For all the
815  other entities, destroying them or removing their components isn't
816  allowed and it can result in undefined behavior.
817 
818  Iterators are invalidated and the behaviour is undefined if an entity is
819  modified or destroyed and it's not the one currently returned by the
820  view.<br/>
821  To work around it, possible approaches are:
822 
823  * Store aside the entities and the components to be removed and perform the
824  operations at the end of the iteration.
825  * Mark entities and components with a proper tag component that indicates
826  they must be purged, then perform a second iteration to clean them up one
827  by one.
828 
829 * Views and thus their iterators aren't thread safe. Do no try to iterate a set
830  of components and modify the same set concurrently.<br/>
831  That being said, as long as a thread iterates the entities that have the
832  component `X` or assign and removes that component from a set of entities,
833  another thread can safely do the same with components `Y` and `Z` and
834  everything will work like a charm.<br/>
835  As an example, users can freely execute the rendering system and iterate the
836  renderable entities while updating a physic component concurrently on a
837  separate thread if needed.
838 
839 # Contributors
840 
841 If you want to contribute, please send patches as pull requests against the
842 branch `master`.<br/>
843 Check the
844 [contributors list](https://github.com/skypjack/entt/blob/master/AUTHORS) to see
845 who has partecipated so far.
846 
847 # License
848 
849 Code and documentation Copyright (c) 2017 Michele Caini.<br/>
850 Code released under
851 [the MIT license](https://github.com/skypjack/entt/blob/master/LICENSE).
852 Docs released under
853 [Creative Commons](https://github.com/skypjack/entt/blob/master/docs/LICENSE).
854 
855 # Donation
856 
857 Developing and maintaining `EnTT` takes some time and lots of coffee. I'd like
858 to add more and more functionalities in future and turn it in a full-featured
859 framework.<br/>
860 If you want to support this project, you can offer me an espresso. I'm from
861 Italy, we're used to turning the best coffee ever in code. If you find that
862 it's not enough, feel free to support me the way you prefer.<br/>
863 Take a look at the donation button at the top of the page for more details or
864 just click [here](https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=W2HF9FESD5LJY&lc=IT&item_name=Michele%20Caini&currency_code=EUR&bn=PP%2dDonationsBF%3abtn_donateCC_LG%2egif%3aNonHosted).