From 74f3ad98f0a257058304472221f614de7c1d8b35 Mon Sep 17 00:00:00 2001 From: Michele Caini Date: Wed, 30 May 2018 22:49:40 +0200 Subject: [PATCH] API reference v2.6.0 --- README_8md_source.html | 4 +- actor_8hpp_source.html | 34 +- algorithm_8hpp_source.html | 83 + annotated.html | 72 +- bus_8hpp_source.html | 98 - cache_8hpp_source.html | 30 +- ...01Event_00_01Other_8_8_8_01_4-members.html | 91 - ...1Sig_00_01Event_00_01Other_8_8_8_01_4.html | 450 ----- ...ent_00_01Other_8_8_8_01_4__coll__graph.map | 4 - ...ent_00_01Other_8_8_8_01_4__coll__graph.md5 | 1 - ...ent_00_01Other_8_8_8_01_4__coll__graph.png | Bin 7996 -> 0 bytes ..._00_01Other_8_8_8_01_4__inherit__graph.map | 4 - ..._00_01Other_8_8_8_01_4__inherit__graph.md5 | 1 - ..._00_01Other_8_8_8_01_4__inherit__graph.png | Bin 7996 -> 0 bytes classentt_1_1Bus_3_01Sig_00_01Event_01_4.html | 437 ----- ..._01Sig_00_01Event_01_4__inherit__graph.map | 3 - ..._01Sig_00_01Event_01_4__inherit__graph.md5 | 1 - ..._01Sig_00_01Event_01_4__inherit__graph.png | Bin 5281 -> 0 bytes classentt_1_1ContinuousLoader-members.html | 32 +- classentt_1_1ContinuousLoader.html | 200 +- classentt_1_1Delegate.html | 4 +- ...ate_3_01Ret_07Args_8_8_8_08_4-members.html | 12 +- ...1_1Delegate_3_01Ret_07Args_8_8_8_08_4.html | 74 +- classentt_1_1Dispatcher-members.html | 18 +- classentt_1_1Dispatcher.html | 279 ++- classentt_1_1Emitter-members.html | 16 +- classentt_1_1Emitter.html | 110 +- classentt_1_1Family-members.html | 4 +- classentt_1_1Family.html | 20 +- classentt_1_1HashedString-members.html | 12 +- classentt_1_1HashedString.html | 78 +- classentt_1_1PersistentView-members.html | 26 +- classentt_1_1PersistentView.html | 361 +++- classentt_1_1Process-members.html | 24 +- classentt_1_1Process.html | 154 +- classentt_1_1Prototype-members.html | 96 + classentt_1_1Prototype.html | 707 ++++++++ classentt_1_1RawView-members.html | 22 +- classentt_1_1RawView.html | 449 ++++- classentt_1_1Registry-members.html | 108 +- classentt_1_1Registry.html | 1614 ++++++++++------- classentt_1_1ResourceCache-members.html | 26 +- classentt_1_1ResourceCache.html | 166 +- classentt_1_1ResourceHandle-members.html | 18 +- classentt_1_1ResourceHandle.html | 100 +- classentt_1_1ResourceLoader-members.html | 2 +- classentt_1_1ResourceLoader.html | 2 +- classentt_1_1Scheduler-members.html | 12 +- classentt_1_1Scheduler.html | 78 +- classentt_1_1SigH.html | 6 +- ..._8_8_8_08_00_01Collector_01_4-members.html | 20 +- ...t_07Args_8_8_8_08_00_01Collector_01_4.html | 341 +--- ..._8_08_00_01Collector_01_4__coll__graph.md5 | 2 +- ..._8_08_00_01Collector_01_4__coll__graph.png | Bin 5010 -> 6315 bytes ...08_00_01Collector_01_4__inherit__graph.md5 | 2 +- ...08_00_01Collector_01_4__inherit__graph.png | Bin 5010 -> 6315 bytes ...al_3_01void_07Args_8_8_8_08_4-members.html | 94 - ..._1_1Signal_3_01void_07Args_8_8_8_08_4.html | 606 ------- ...t_1_1Signal.html => classentt_1_1Sink.html | 32 +- ...ink_3_01Ret_07Args_8_8_8_08_4-members.html | 23 +- ...ntt_1_1Sink_3_01Ret_07Args_8_8_8_08_4.html | 364 ++++ classentt_1_1Snapshot-members.html | 17 +- classentt_1_1Snapshot.html | 334 +++- classentt_1_1SnapshotLoader-members.html | 16 +- classentt_1_1SnapshotLoader.html | 168 +- classentt_1_1SparseSet.html | 4 +- ...Set_3_01Entity_00_01Type_01_4-members.html | 56 +- ..._1SparseSet_3_01Entity_00_01Type_01_4.html | 548 ++++-- ..._1_1SparseSet_3_01Entity_01_4-members.html | 40 +- classentt_1_1SparseSet_3_01Entity_01_4.html | 444 +++-- classentt_1_1View-members.html | 27 +- classentt_1_1View.html | 381 ++-- ..._01Entity_00_01Component_01_4-members.html | 26 +- ..._1View_3_01Entity_00_01Component_01_4.html | 405 +++-- classes.html | 50 +- config_8h_source.html | 78 + delegate_8hpp_source.html | 20 +- dir_66e9674e8206a335795995fa32a03c91.html | 2 +- dir_68267d1309a1af8e8297ef4c3efbcdba.html | 2 +- dir_721f6154dba3c88bcdead5f446bce319.html | 2 +- dir_7929ab29d3f740cf727ccbd263321562.html | 78 + dir_85dbee8884f1b3a817fa7eff8dff73ec.html | 2 +- dir_a53318306f6ac0f7fe657839abd543ab.html | 2 +- dir_b64489a1e8130d5ebf6d86d282f500f0.html | 2 +- dir_de8f4e6ba3f54a2a21309f742e93a373.html | 2 +- dir_e3a7bb56c55e5c2286e2fe96e197d4f5.html | 2 +- dispatcher_8hpp_source.html | 21 +- emitter_8hpp_source.html | 30 +- entt_8hpp_source.html | 4 +- entt__traits_8hpp_source.html | 4 +- family_8hpp_source.html | 10 +- files.html | 62 +- functions.html | 22 +- functions_0x7e.html | 10 +- functions_b.html | 12 +- functions_c.html | 75 +- functions_d.html | 42 +- functions_e.html | 51 +- functions_f.html | 8 +- functions_func.html | 22 +- functions_func_0x7e.html | 10 +- functions_func_b.html | 12 +- functions_func_c.html | 68 +- functions_func_d.html | 39 +- functions_func_e.html | 48 +- functions_func_f.html | 8 +- functions_func_g.html | 19 +- functions_func_h.html | 13 +- functions_func_l.html | 4 +- functions_func_m.html | 4 +- functions_func_o.html | 42 +- functions_func_p.html | 14 +- functions_func_r.html | 44 +- functions_func_s.html | 48 +- functions_func_t.html | 16 +- functions_func_u.html | 17 +- functions_func_v.html | 8 +- functions_g.html | 19 +- functions_h.html | 13 +- functions_i.html | 5 +- functions_l.html | 4 +- functions_m.html | 4 +- functions_o.html | 40 +- functions_p.html | 14 +- functions_r.html | 49 +- functions_rela.html | 6 +- functions_s.html | 63 +- functions_t.html | 16 +- functions_type.html | 32 +- functions_u.html | 17 +- functions_v.html | 8 +- functions_vars.html | 2 +- graph_legend.html | 2 +- handle_8hpp_source.html | 14 +- hashed__string_8hpp_source.html | 16 +- helper_8hpp_source.html | 83 + hierarchy.html | 93 +- ident_8hpp_source.html | 6 +- index.html | 374 ++-- inherit_graph_0.map | 2 +- inherit_graph_0.md5 | 2 +- inherit_graph_0.png | Bin 2118 -> 1607 bytes inherit_graph_1.map | 2 +- inherit_graph_1.md5 | 2 +- inherit_graph_1.png | Bin 1566 -> 1047 bytes inherit_graph_10.map | 2 +- inherit_graph_10.md5 | 2 +- inherit_graph_10.png | Bin 2036 -> 1983 bytes inherit_graph_11.map | 2 +- inherit_graph_11.md5 | 2 +- inherit_graph_11.png | Bin 1983 -> 1851 bytes inherit_graph_12.map | 2 +- inherit_graph_12.md5 | 2 +- inherit_graph_12.png | Bin 1851 -> 1336 bytes inherit_graph_13.map | 2 +- inherit_graph_13.md5 | 2 +- inherit_graph_13.png | Bin 1336 -> 1633 bytes inherit_graph_14.map | 2 +- inherit_graph_14.md5 | 2 +- inherit_graph_14.png | Bin 1633 -> 1281 bytes inherit_graph_15.map | 2 +- inherit_graph_15.md5 | 2 +- inherit_graph_15.png | Bin 2696 -> 1138 bytes inherit_graph_16.map | 2 +- inherit_graph_16.md5 | 2 +- inherit_graph_16.png | Bin 2274 -> 2696 bytes inherit_graph_17.map | 3 +- inherit_graph_17.md5 | 2 +- inherit_graph_17.png | Bin 7482 -> 2274 bytes inherit_graph_18.map | 3 +- inherit_graph_18.md5 | 2 +- inherit_graph_18.png | Bin 2626 -> 7482 bytes inherit_graph_19.map | 2 +- inherit_graph_19.md5 | 2 +- inherit_graph_19.png | Bin 1730 -> 1637 bytes inherit_graph_2.map | 4 +- inherit_graph_2.md5 | 2 +- inherit_graph_2.png | Bin 6493 -> 2271 bytes inherit_graph_20.map | 2 +- inherit_graph_20.md5 | 2 +- inherit_graph_20.png | Bin 2193 -> 1090 bytes inherit_graph_21.map | 2 +- inherit_graph_21.md5 | 2 +- inherit_graph_21.png | Bin 2056 -> 2626 bytes inherit_graph_22.map | 2 +- inherit_graph_22.md5 | 2 +- inherit_graph_22.png | Bin 2161 -> 1730 bytes inherit_graph_23.map | 2 +- inherit_graph_23.md5 | 2 +- inherit_graph_23.png | Bin 1819 -> 2193 bytes inherit_graph_24.map | 2 +- inherit_graph_24.md5 | 2 +- inherit_graph_24.png | Bin 2059 -> 2056 bytes inherit_graph_25.map | 2 +- inherit_graph_25.md5 | 2 +- inherit_graph_25.png | Bin 2332 -> 2161 bytes inherit_graph_26.map | 2 +- inherit_graph_26.md5 | 2 +- inherit_graph_26.png | Bin 2781 -> 1819 bytes inherit_graph_27.map | 2 +- inherit_graph_27.md5 | 2 +- inherit_graph_27.png | Bin 1878 -> 2059 bytes inherit_graph_28.map | 2 +- inherit_graph_28.md5 | 2 +- inherit_graph_28.png | Bin 2827 -> 2332 bytes inherit_graph_29.map | 2 +- inherit_graph_29.md5 | 2 +- inherit_graph_29.png | Bin 1954 -> 3872 bytes inherit_graph_3.map | 2 +- inherit_graph_3.md5 | 2 +- inherit_graph_3.png | Bin 2271 -> 2308 bytes inherit_graph_30.map | 2 +- inherit_graph_30.md5 | 2 +- inherit_graph_30.png | Bin 2414 -> 2675 bytes inherit_graph_31.map | 3 +- inherit_graph_31.md5 | 2 +- inherit_graph_31.png | Bin 3584 -> 1767 bytes inherit_graph_32.map | 2 +- inherit_graph_32.md5 | 2 +- inherit_graph_32.png | Bin 2545 -> 2140 bytes inherit_graph_33.map | 2 +- inherit_graph_33.md5 | 2 +- inherit_graph_33.png | Bin 1551 -> 1954 bytes inherit_graph_34.map | 2 +- inherit_graph_34.md5 | 2 +- inherit_graph_34.png | Bin 2384 -> 2414 bytes inherit_graph_35.map | 3 +- inherit_graph_35.md5 | 2 +- inherit_graph_35.png | Bin 2384 -> 3584 bytes inherit_graph_36.map | 3 + inherit_graph_36.md5 | 1 + inherit_graph_36.png | Bin 0 -> 1551 bytes inherit_graph_37.map | 3 + inherit_graph_37.md5 | 1 + inherit_graph_37.png | Bin 0 -> 1250 bytes inherit_graph_38.map | 3 + inherit_graph_38.md5 | 1 + inherit_graph_38.png | Bin 0 -> 965 bytes inherit_graph_39.map | 3 + inherit_graph_39.md5 | 1 + inherit_graph_39.png | Bin 0 -> 2384 bytes inherit_graph_4.map | 2 +- inherit_graph_4.md5 | 2 +- inherit_graph_4.png | Bin 2308 -> 1844 bytes inherit_graph_40.map | 3 + inherit_graph_40.md5 | 1 + inherit_graph_40.png | Bin 0 -> 2384 bytes inherit_graph_5.map | 2 +- inherit_graph_5.md5 | 2 +- inherit_graph_5.png | Bin 1844 -> 1425 bytes inherit_graph_6.map | 2 +- inherit_graph_6.md5 | 2 +- inherit_graph_6.png | Bin 2047 -> 1508 bytes inherit_graph_7.map | 2 +- inherit_graph_7.md5 | 2 +- inherit_graph_7.png | Bin 1508 -> 3863 bytes inherit_graph_8.map | 2 +- inherit_graph_8.md5 | 2 +- inherit_graph_8.png | Bin 3863 -> 1908 bytes inherit_graph_9.map | 2 +- inherit_graph_9.md5 | 2 +- inherit_graph_9.png | Bin 1908 -> 2036 bytes inherits.html | 139 +- loader_8hpp_source.html | 6 +- locator_8hpp_source.html | 14 +- namespaceentt.html | 457 +++-- namespacemembers.html | 24 +- namespacemembers_func.html | 7 +- namespacemembers_type.html | 19 +- namespacemembers_vars.html | 2 +- namespaces.html | 2 +- process_8hpp_source.html | 36 +- prototype_8hpp_source.html | 93 + registry_8hpp_source.html | 130 +- scheduler_8hpp_source.html | 28 +- search/all_0.js | 14 +- search/all_1.js | 7 +- search/all_10.js | 9 +- search/all_11.js | 6 +- search/all_12.js | 8 +- search/all_2.js | 25 +- search/all_3.js | 23 +- search/all_4.js | 19 +- search/all_5.js | 4 +- search/all_6.js | 2 +- search/all_7.js | 6 +- search/all_8.js | 5 +- search/all_9.js | 2 +- search/all_a.js | 4 +- search/all_b.js | 22 +- search/all_c.js | 9 +- search/all_d.js | 28 +- search/all_e.js | 30 +- search/all_f.js | 9 +- search/classes_1.js | 5 +- search/classes_7.js | 5 +- search/classes_8.js | 11 +- search/classes_9.js | 18 +- search/classes_a.js | 15 +- search/{typedefs_d.html => classes_b.html} | 2 +- search/classes_b.js | 4 + search/{typedefs_e.html => classes_c.html} | 2 +- search/classes_c.js | 5 + search/functions_0.js | 14 +- search/functions_1.js | 2 +- search/functions_10.js | 6 +- search/functions_11.js | 8 +- search/functions_2.js | 24 +- search/functions_3.js | 17 +- search/functions_4.js | 17 +- search/functions_5.js | 4 +- search/functions_6.js | 2 +- search/functions_7.js | 6 +- search/functions_8.js | 2 +- search/functions_9.js | 2 +- search/functions_a.js | 22 +- search/functions_b.js | 7 +- search/functions_c.js | 25 +- search/functions_d.js | 18 +- search/functions_e.js | 8 +- search/functions_f.js | 7 +- search/related_2.js | 3 +- search/searchdata.js | 4 +- search/typedefs_0.js | 3 +- search/typedefs_1.js | 5 +- search/typedefs_2.js | 2 +- search/typedefs_5.js | 4 +- search/typedefs_7.js | 3 +- search/typedefs_8.js | 2 +- search/typedefs_9.js | 4 +- search/typedefs_a.js | 6 +- search/typedefs_b.js | 3 +- search/typedefs_c.js | 2 +- search/typedefs_d.js | 5 - search/typedefs_e.js | 4 - sigh_8hpp_source.html | 41 +- signal_8hpp_source.html | 94 - snapshot_8hpp_source.html | 59 +- sparse__set_8hpp_source.html | 79 +- structentt_1_1Actor-members.html | 44 +- structentt_1_1Actor.html | 903 +++++---- ...entt_1_1Emitter_1_1Connection-members.html | 4 +- structentt_1_1Emitter_1_1Connection.html | 18 +- structentt_1_1InsertionSort-members.html | 82 + structentt_1_1InsertionSort.html | 166 ++ structentt_1_1ProcessAdaptor-members.html | 26 +- structentt_1_1ProcessAdaptor.html | 90 +- structentt_1_1ServiceLocator-members.html | 8 +- structentt_1_1ServiceLocator.html | 52 +- structentt_1_1StdSort-members.html | 82 + structentt_1_1StdSort.html | 168 ++ ...1_1Bus.html => structentt_1_1break__t.html | 26 +- structentt_1_1entt__traits.html | 2 +- ...its_3_01std_1_1uint16__t_01_4-members.html | 2 +- ...ntt__traits_3_01std_1_1uint16__t_01_4.html | 2 +- ...its_3_01std_1_1uint32__t_01_4-members.html | 2 +- ...ntt__traits_3_01std_1_1uint32__t_01_4.html | 2 +- ...its_3_01std_1_1uint64__t_01_4-members.html | 2 +- ...ntt__traits_3_01std_1_1uint64__t_01_4.html | 2 +- structentt_1_1persistent__t.html | 90 + structentt_1_1raw__t.html | 90 + structentt_1_1tag__t.html | 90 + utility_8hpp_source.html | 83 + view_8hpp_source.html | 155 +- 364 files changed, 9411 insertions(+), 6722 deletions(-) create mode 100644 algorithm_8hpp_source.html delete mode 100644 bus_8hpp_source.html delete mode 100644 classentt_1_1Bus_3_01Sig_00_01Event_00_01Other_8_8_8_01_4-members.html delete mode 100644 classentt_1_1Bus_3_01Sig_00_01Event_00_01Other_8_8_8_01_4.html delete mode 100644 classentt_1_1Bus_3_01Sig_00_01Event_00_01Other_8_8_8_01_4__coll__graph.map delete mode 100644 classentt_1_1Bus_3_01Sig_00_01Event_00_01Other_8_8_8_01_4__coll__graph.md5 delete mode 100644 classentt_1_1Bus_3_01Sig_00_01Event_00_01Other_8_8_8_01_4__coll__graph.png delete mode 100644 classentt_1_1Bus_3_01Sig_00_01Event_00_01Other_8_8_8_01_4__inherit__graph.map delete mode 100644 classentt_1_1Bus_3_01Sig_00_01Event_00_01Other_8_8_8_01_4__inherit__graph.md5 delete mode 100644 classentt_1_1Bus_3_01Sig_00_01Event_00_01Other_8_8_8_01_4__inherit__graph.png delete mode 100644 classentt_1_1Bus_3_01Sig_00_01Event_01_4.html delete mode 100644 classentt_1_1Bus_3_01Sig_00_01Event_01_4__inherit__graph.map delete mode 100644 classentt_1_1Bus_3_01Sig_00_01Event_01_4__inherit__graph.md5 delete mode 100644 classentt_1_1Bus_3_01Sig_00_01Event_01_4__inherit__graph.png create mode 100644 classentt_1_1Prototype-members.html create mode 100644 classentt_1_1Prototype.html delete mode 100644 classentt_1_1Signal_3_01void_07Args_8_8_8_08_4-members.html delete mode 100644 classentt_1_1Signal_3_01void_07Args_8_8_8_08_4.html rename classentt_1_1Signal.html => classentt_1_1Sink.html (73%) rename classentt_1_1Bus_3_01Sig_00_01Event_01_4-members.html => classentt_1_1Sink_3_01Ret_07Args_8_8_8_08_4-members.html (51%) create mode 100644 classentt_1_1Sink_3_01Ret_07Args_8_8_8_08_4.html create mode 100644 config_8h_source.html create mode 100644 dir_7929ab29d3f740cf727ccbd263321562.html create mode 100644 helper_8hpp_source.html create mode 100644 inherit_graph_36.map create mode 100644 inherit_graph_36.md5 create mode 100644 inherit_graph_36.png create mode 100644 inherit_graph_37.map create mode 100644 inherit_graph_37.md5 create mode 100644 inherit_graph_37.png create mode 100644 inherit_graph_38.map create mode 100644 inherit_graph_38.md5 create mode 100644 inherit_graph_38.png create mode 100644 inherit_graph_39.map create mode 100644 inherit_graph_39.md5 create mode 100644 inherit_graph_39.png create mode 100644 inherit_graph_40.map create mode 100644 inherit_graph_40.md5 create mode 100644 inherit_graph_40.png create mode 100644 prototype_8hpp_source.html rename search/{typedefs_d.html => classes_b.html} (94%) create mode 100644 search/classes_b.js rename search/{typedefs_e.html => classes_c.html} (94%) create mode 100644 search/classes_c.js delete mode 100644 search/typedefs_d.js delete mode 100644 search/typedefs_e.js delete mode 100644 signal_8hpp_source.html create mode 100644 structentt_1_1InsertionSort-members.html create mode 100644 structentt_1_1InsertionSort.html create mode 100644 structentt_1_1StdSort-members.html create mode 100644 structentt_1_1StdSort.html rename classentt_1_1Bus.html => structentt_1_1break__t.html (69%) create mode 100644 structentt_1_1persistent__t.html create mode 100644 structentt_1_1raw__t.html create mode 100644 structentt_1_1tag__t.html create mode 100644 utility_8hpp_source.html diff --git a/README_8md_source.html b/README_8md_source.html index ef2f31936..b0fba8acb 100644 --- a/README_8md_source.html +++ b/README_8md_source.html @@ -22,7 +22,7 @@
entt -  2.5.0 +  2.6.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 # Table of Contents
9 
10 * [Introduction](#introduction)
11 * [Build Instructions](#build-instructions)
12 * [Crash Course: entity-component system](#crash-course-entity-component-system)
13  * [Design choices](#design-choices)
14  * [A bitset-free entity-component system](#a-bitset-free-entity-component-system)
15  * [Pay per use](#pay-per-use)
16  * [Vademecum](#vademecum)
17  * [The Registry, the Entity and the Component](#the-registry-the-entity-and-the-component)
18  * [Single instance components](#single-instance-components)
19  * [Runtime components](#runtime-components)
20  * [A journey through a plugin](#a-journey-through-a-plugin)
21  * [Sorting: is it possible?](#sorting-is-it-possible)
22  * [Snapshot: complete vs continuous](#snapshot-complete-vs-continuous)
23  * [Snapshot loader](#snapshot-loader)
24  * [Continuous loader](#continuous-loader)
25  * [Archives](#archives)
26  * [One example to rule them all](#one-example-to-rule-them-all)
27  * [View: to persist or not to persist?](#view-to-persist-or-not-to-persist)
28  * [Standard View](#standard-view)
29  * [Single component standard view](#single-component-standard-view)
30  * [Multi component standard view](#multi-component-standard-view)
31  * [Persistent View](#persistent-view)
32  * [Raw View](#raw-view)
33  * [Give me everything](#give-me-everything)
34  * [Side notes](#side-notes)
35 * [Crash Course: core functionalities](#crash-course-core-functionalities)
36  * [Compile-time identifiers](#compile-time-identifiers)
37  * [Runtime identifiers](#runtime-identifiers)
38  * [Hashed strings](#hashed-strings)
39 * [Crash Course: service locator](#crash-course-service-locator)
40 * [Crash Course: cooperative scheduler](#crash-course-cooperative-scheduler)
41  * [The process](#the-process)
42  * [The scheduler](#the-scheduler)
43 * [Crash Course: resource management](#crash-course-resource-management)
44  * [The resource, the loader and the cache](#the-resource-the-loader-and-the-cache)
45 * [Crash Course: events, signals and everything in between](#crash-course-events-signals-and-everything-in-between)
46  * [Signals](#signals)
47  * [Compile-time event bus](#compile-time-event-bus)
48  * [Delegate](#delegate)
49  * [Event dispatcher](#event-dispatcher)
50  * [Event emitter](#event-emitter)
51 * [License](#license)
52 * [Support](#support)
53  * [Donation](#donation)
54  * [Hire me](#hire-me)
55 
56 # Introduction
57 
58 `EnTT` is a header-only, tiny and easy to use framework written in modern
59 C++.<br/>
60 It was originally designed entirely around an architectural pattern called _ECS_
61 that is used mostly in game development. For further details:
62 
63 * [Entity Systems Wiki](http://entity-systems.wikidot.com/)
64 * [Evolve Your Hierarchy](http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/)
65 * [ECS on Wikipedia](https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system)
66 
67 A long time ago, the sole entity-component system was part of the project. After
68 a while the codebase has grown and more and more classes have become part of the
69 repository.<br/>
70 That's why today it's called _the EnTT Framework_.
71 
72 Currently, `EnTT` is tested on Linux, Microsoft Windows and OS X. It has proven
73 to work also on both Android and iOS.<br/>
74 Most likely it will not be problematic on other systems as well, but has not
75 been sufficiently tested so far.
76 
77 ## The framework
78 
79 `EnTT` was written initially as a faster alternative to other well known and
80 open source entity-component systems. Nowadays the `EnTT` framework is moving
81 its first steps. Much more will come in the future and hopefully I'm going to
82 work on it for a long time.<br/>
83 Requests for feature, PR, suggestions ad feedback are highly appreciated.
84 
85 If you find you can help me and want to contribute to the `EnTT` framework with
86 your experience or you do want to get part of the project for some other
87 reasons, feel free to contact me directly (you can find the mail in the
88 [profile](https://github.com/skypjack)).<br/>
89 I can't promise that each and every contribution will be accepted, but I can
90 assure that I'll do my best to take them all seriously.
91 
92 ### State of the art
93 
94 Here is a brief list of what it offers today:
95 
96 * Statically generated integer identifiers for types (assigned either at
97  compile-time or at runtime).
98 * A constexpr utility for human readable resource identifiers.
99 * An incredibly fast entity-component system based on sparse sets, with its own
100  views and a _pay for what you use_ policy to adjust performance and memory
101  usage according to the users' requirements.
102 * Actor class for those who aren't confident with entity-component systems.
103 * The smallest and most basic implementation of a service locator ever seen.
104 * A cooperative scheduler for processes of any type.
105 * All what is needed for resource management (cache, loaders, handles).
106 * Signal handlers of any type, delegates and an event bus.
107 * A general purpose event emitter, that is a CRTP idiom based class template.
108 * An event dispatcher for immediate and delayed events to integrate in loops.
109 * ...
110 * Any other business.
111 
112 Consider it a work in progress. For more details and an updated list, please
113 refer to the [online documentation](https://skypjack.github.io/entt/). It
114 probably contains much more. Moreover, the whole API is fully documented in-code
115 for those who are brave enough to read it.<br/>
116 Continue reading to know how the different parts of the project work or follow
117 the link above to take a look at the API reference.
118 
119 ## Code Example
120 
121 ```cpp
122 #include <entt/entt.hpp>
123 #include <cstdint>
124 
125 struct Position {
126  float x;
127  float y;
128 };
129 
130 struct Velocity {
131  float dx;
132  float dy;
133 };
134 
135 void update(entt::DefaultRegistry &registry) {
136  auto view = registry.view<Position, Velocity>();
137 
138  for(auto entity: view) {
139  // gets only the components that are going to be used ...
140 
141  auto &velocity = view.get<Velocity>(entity);
142 
143  velocity.dx = 0.;
144  velocity.dy = 0.;
145 
146  // ...
147  }
148 }
149 
150 void update(std::uint64_t dt, entt::DefaultRegistry &registry) {
151  registry.view<Position, Velocity>().each([dt](auto entity, auto &position, auto &velocity) {
152  // gets all the components of the view at once ...
153 
154  position.x += velocity.dx * dt;
155  position.y += velocity.dy * dt;
156 
157  // ...
158  });
159 }
160 
161 int main() {
162  entt::DefaultRegistry registry;
163  std::uint64_t dt = 16;
164 
165  for(auto i = 0; i < 10; ++i) {
166  auto entity = registry.create(Position{i * 1.f, i * 1.f});
167  if(i % 2 == 0) { registry.assign<Velocity>(entity, i * .1f, i * .1f); }
168  }
169 
170  update(dt, registry);
171  update(registry);
172 
173  // ...
174 }
175 ```
176 
177 ## Motivation
178 
179 I started working on `EnTT` because of the wrong reason: my goal was to design
180 an entity-component system that beated another well known open source solution
181 in terms of performance and used (possibly) less memory in the average
182 case.<br/>
183 In the end, I did it, but it wasn't much satisfying. Actually it wasn't
184 satisfying at all. The fastest and nothing more, fairly little indeed. When I
185 realized it, I tried hard to keep intact the great performance of `EnTT` and to
186 add all the features I wanted to see in *my own library* at the same time.
187 
188 Today `EnTT` is finally what I was looking for: still faster than its
189 _competitors_, lower memory usage in the average case, a really good API and an
190 amazing set of features. And even more, of course.
191 
192 ## Performance
193 
194 As it stands right now, `EnTT` is just fast enough for my requirements if
195 compared to my first choice (it was already amazingly fast actually).<br/>
196 Below is a comparison between the two (both of them compiled with GCC 7.3.0 on a
197 Dell XPS 13 out of the mid 2014):
198 
199 | Benchmark | EntityX (compile-time) | EnTT |
200 |-----------|-------------|-------------|
201 | Create 1M entities | 0.0167s | **0.0046s** |
202 | Destroy 1M entities | 0.0053s | **0.0039s** |
203 | Standard view, 1M entities, one component | 0.0012s | **1.9e-07s** |
204 | Standard view, 1M entities, two components | 0.0012s | **3.8e-07s** |
205 | Standard view, 1M entities, two components<br/>Half of the entities have all the components | 0.0009s | **3.8e-07s** |
206 | Standard view, 1M entities, two components<br/>One of the entities has all the components | 0.0008s | **1.0e-06s** |
207 | Persistent view, 1M entities, two components | 0.0012s | **2.8e-07s** |
208 | Standard view, 1M entities, five components | 0.0010s | **7.0e-07s** |
209 | Persistent view, 1M entities, five components | 0.0010s | **2.8e-07s** |
210 | Standard view, 1M entities, ten components | 0.0011s | **1.2e-06s** |
211 | Standard view, 1M entities, ten components<br/>Half of the entities have all the components | 0.0010s | **1.2e-06s** |
212 | Standard view, 1M entities, ten components<br/>One of the entities has all the components | 0.0008s | **1.2e-06s** |
213 | Persistent view, 1M entities, ten components | 0.0011s | **3.0e-07s** |
214 | Raw view, 1M entities | - | **2.2e-07s** |
215 | Sort 150k entities, one component<br/>Arrays are in reverse order | - | **0.0036s** |
216 | Sort 150k entities, enforce permutation<br/>Arrays are in reverse order | - | **0.0005s** |
217 
218 Note: The default version of `EntityX` (`master` branch) wasn't added to the
219 comparison because it's already much slower than its compile-time counterpart.
220 
221 Pretty interesting, aren't them? In fact, these benchmarks are the same used by
222 `EntityX` to show _how fast it is_. To be honest, they aren't so good and these
223 results shouldn't be taken much seriously (they are completely unrealistic
224 indeed).<br/>
225 The proposed entity-component system is incredibly fast to iterate entities,
226 this is a fact. The compiler can make a lot of optimizations because of how
227 `EnTT` works, even more when components aren't used at all. This is exactly the
228 case for these benchmarks.<br/>
229 This is why they are completely wrong and cannot be used to evaluate any of the
230 entity-component systems.
231 
232 If you decide to use `EnTT`, choose it because of its API and its performance,
233 not because there is a benchmark somewhere that makes it seem the fastest.
234 
235 Probably I'll try to get out of `EnTT` more features and even better performance
236 in the future, mainly for fun.<br/>
237 If you want to contribute and/or have any suggestion, feel free to make a PR or
238 open an issue to discuss your idea.
239 
240 # Build Instructions
241 
242 ## Requirements
243 
244 To be able to use `EnTT`, users must provide a full-featured compiler that
245 supports at least C++14.<br/>
246 The requirements below are mandatory to compile the tests and to extract the
247 documentation:
248 
249 * CMake version 3.2 or later.
250 * Doxygen version 1.8 or later.
251 
252 ## Library
253 
254 `EnTT` is a header-only library. This means that including the `entt.hpp`
255 header is enough to include the whole framework and use it. For those who are
256 interested only in the entity-component system, consider to include the sole
257 `entity/registry.hpp` header instead.<br/>
258 It's a matter of adding the following line to the top of a file:
259 
260 ```cpp
261 #include <entt/entt.hpp>
262 ```
263 
264 Use the line below to include only the entity-component system instead:
265 
266 ```cpp
267 #include <entt/entity/registry.hpp>
268 ```
269 
270 Then pass the proper `-I` argument to the compiler to add the `src` directory to
271 the include paths.
272 
273 ## Documentation
274 
275 The documentation is based on [doxygen](http://www.stack.nl/~dimitri/doxygen/).
276 To build it:
277 
278  $ cd build
279  $ cmake ..
280  $ make docs
281 
282 The API reference will be created in HTML format within the directory
283 `build/docs/html`. To navigate it with your favorite browser:
284 
285  $ cd build
286  $ your_favorite_browser docs/html/index.html
287 
288 The API reference is also available [online](https://skypjack.github.io/entt/)
289 for the latest version.
290 
291 ## Tests
292 
293 To compile and run the tests, `EnTT` requires *googletest*.<br/>
294 `cmake` will download and compile the library before to compile anything else.
295 
296 To build the most basic set of tests:
297 
298 * `$ cd build`
299 * `$ cmake ..`
300 * `$ make`
301 * `$ make test`
302 
303 Note that benchmarks are not part of this set.
304 
305 # Crash Course: entity-component system
306 
307 ## Design choices
308 
309 ### A bitset-free entity-component system
310 
311 `EnTT` is a _bitset-free_ entity-component system that doesn't require users to
312 specify the component set at compile-time.<br/>
313 This is why users can instantiate the core class simply like:
314 
315 ```cpp
316 entt::DefaultRegistry registry;
317 ```
318 
319 In place of its more annoying and error-prone counterpart:
320 
321 ```cpp
322 entt::DefaultRegistry<Comp0, Comp1, ..., CompN> registry;
323 ```
324 
325 ### Pay per use
326 
327 `EnTT` is entirely designed around the principle that users have to pay only for
328 what they want.
329 
330 When it comes to using an entity-component system, the tradeoff is usually
331 between performance and memory usage. The faster it is, the more memory it uses.
332 However, slightly worse performance along non-critical paths are the right price
333 to pay to reduce memory usage and I've always wondered why this kind of tools do
334 not leave me the choice.<br/>
335 `EnTT` follows a completely different approach. It squeezes the best from the
336 basic data structures and gives users the possibility to pay more for higher
337 performance where needed.<br/>
338 The disadvantage of this approach is that users need to know the systems they
339 are working on and the tools they are using. Otherwise, the risk to ruin the
340 performance along critical paths is high.
341 
342 So far, this choice has proven to be a good one and I really hope it can be for
343 many others besides me.
344 
345 ## Vademecum
346 
347 The `Registry` to store, the views to iterate. That's all.
348 
349 An entity (the _E_ of an _ECS_) is an opaque identifier that users should just
350 use as-is and store around if needed. Do not try to inspect an entity
351 identifier, its format can change in future and a registry offers all the
352 functionalities to query them out-of-the-box. The underlying type of an entity
353 (either `std::uint16_t`, `std::uint32_t` or `std::uint64_t`) can be specified
354 when defining a registry (actually the `DefaultRegistry` is nothing more than a
355 `Registry` where the type of the entities is `std::uint32_t`).<br/>
356 Components (the _C_ of an _ECS_) should be plain old data structures or more
357 complex and movable data structures with a proper constructor. Actually, the
358 sole requirement of a component type is that it must be both move constructible
359 and move assignable. They are list initialized by using the parameters provided
360 to construct the component itself. No need to register components or their types
361 neither with the registry nor with the entity-component system at all.<br/>
362 Systems (the _S_ of an _ECS_) are just plain functions, functors, lambdas or
363 whatever the users want. They can accept a `Registry` or a view of any type and
364 use them the way they prefer. No need to register systems or their types neither
365 with the registry nor with the entity-component system at all.
366 
367 The following sections will explain in short how to use the entity-component
368 system, the core part of the whole framework.<br/>
369 In fact, the framework is composed of many other classes in addition to those
370 describe below. For more details, please refer to the
371 [online documentation](https://skypjack.github.io/entt/).
372 
373 ## The Registry, the Entity and the Component
374 
375 A registry can store and manage entities, as well as create views to iterate the
376 underlying data structures.<br/>
377 `Registry` is a class template that lets the users decide what's the preferred
378 type to represent an entity. Because `std::uint32_t` is large enough for almost
379 all the cases, there exists also an alias named `DefaultRegistry` for
380 `Registry<std::uint32_t>`.
381 
382 Entities are represented by _entity identifiers_. An entity identifier is an
383 opaque type that users should not inspect or modify in any way. It carries
384 information about the entity itself and its version.
385 
386 A registry can be used both to construct and to destroy entities:
387 
388 ```cpp
389 // constructs a naked entity with no components and returns its identifier
390 auto entity = registry.create();
391 
392 // constructs an entity and assigns it default-initialized components
393 auto another = registry.create<Position, Velocity>();
394 
395 // destroys an entity and all its components
396 registry.destroy(entity);
397 ```
398 
399 Once an entity is deleted, the registry can freely reuse it internally with a
400 slightly different identifier. In particular, the version of an entity is
401 increased each and every time it's destroyed.<br/>
402 In case entity identifiers are stored around, the registry offers all the
403 functionalities required to test them and get out of the them all the
404 information they carry:
405 
406 ```cpp
407 // returns true if the entity is still valid, false otherwise
408 bool b = registry.valid(entity);
409 
410 // gets the version contained in the entity identifier
411 auto version = registry.version(entity);
412 
413 // gets the actual version for the given entity
414 auto curr = registry.current(entity);
415 ```
416 
417 Components can be assigned to or removed from entities at any time with a few
418 calls to member functions of the registry. As for the entities, the registry
419 offers also a set of functionalities users can use to work with the components.
420 
421 The `assign` member function template creates, initializes and assigns to an
422 entity the given component. It accepts a variable number of arguments to
423 construct the component itself if present:
424 
425 ```cpp
426 registry.assign<Position>(entity, 0., 0.);
427 
428 // ...
429 
430 Velocity &velocity = registry.assign<Velocity>(entity);
431 velocity.dx = 0.;
432 velocity.dy = 0.;
433 ```
434 
435 If an entity already has the given component, the `replace` member function
436 template can be used to replace it:
437 
438 ```cpp
439 registry.replace<Position>(entity, 0., 0.);
440 
441 // ...
442 
443 Velocity &velocity = registry.replace<Velocity>(entity);
444 velocity.dx = 0.;
445 velocity.dy = 0.;
446 ```
447 
448 In case users want to assign a component to an entity, but it's unknown whether
449 the entity already has it or not, `accommodate` does the work in a single call
450 (there is a performance penalty to pay for this mainly due to the fact that it
451 has to check if the entity already has the given component or not):
452 
453 ```cpp
454 registry.accommodate<Position>(entity, 0., 0.);
455 
456 // ...
457 
458 Velocity &velocity = registry.accommodate<Velocity>(entity);
459 velocity.dx = 0.;
460 velocity.dy = 0.;
461 ```
462 
463 Note that `accommodate` is a slightly faster alternative for the following
464 `if`/`else` statement and nothing more:
465 
466 ```cpp
467 if(registry.has<Comp>(entity)) {
468  registry.replace<Comp>(entity, arg1, argN);
469 } else {
470  registry.assign<Comp>(entity, arg1, argN);
471 }
472 ```
473 
474 As already shown, if in doubt about whether or not an entity has one or more
475 components, the `has` member function template may be useful:
476 
477 ```cpp
478 bool b = registry.has<Position, Velocity>(entity);
479 ```
480 
481 On the other side, if the goal is to delete a single component, the `remove`
482 member function template is the way to go when it's certain that the entity owns
483 a copy of the component:
484 
485 ```cpp
486 registry.remove<Position>(entity);
487 ```
488 
489 Otherwise consider to use the `reset` member function. It behaves similarly to
490 `remove` but with a strictly defined behavior (and a performance penalty is the
491 price to pay for this). In particular it removes the component if and only if it
492 exists, otherwise it returns safely to the caller:
493 
494 ```cpp
495 registry.reset<Position>(entity);
496 ```
497 
498 There exist also two other _versions_ of the `reset` member function:
499 
500 * If no entity is passed to it, `reset` will remove the given component from
501  each entity that has it:
502 
503  ```cpp
504  registry.reset<Position>();
505  ```
506 
507 * If neither the entity nor the component are specified, all the entities still
508  in use and their components are destroyed:
509 
510  ```cpp
511  registry.reset();
512  ```
513 
514 Finally, references to components can be retrieved simply by doing this:
515 
516 ```cpp
517 const auto &cregistry = registry;
518 
519 // const and non-const reference
520 const Position &position = cregistry.get<Position>(entity);
521 Position &position = registry.get<Position>(entity);
522 
523 // const and non-const references
524 std::tuple<const Position &, const Velocity &> tup = cregistry.get<Position, Velocity>(entity);
525 std::tuple<Position &, Velocity &> tup = registry.get<Position, Velocity>(entity);
526 ```
527 
528 The `get` member function template gives direct access to the component of an
529 entity stored in the underlying data structures of the registry.
530 
531 ### Single instance components
532 
533 In those cases where all what is needed is a single instance component, tags are
534 the right tool to achieve the purpose.<br/>
535 Tags undergo the same requirements of components. They can be either plain old
536 data structures or more complex and movable data structures with a proper
537 constructor.<br/>
538 Actually, the same type can be used both as a tag and as a component and the
539 registry will not complain about it. It is up to the users to properly manage
540 their own types.
541 
542 Attaching tags to entities and removing them is trivial:
543 
544 ```cpp
545 auto player = registry.create();
546 auto camera = registry.create();
547 
548 // attaches a default-initialized tag to an entity
549 registry.attach<PlayingCharacter>(player);
550 
551 // attaches a tag to an entity and initializes it
552 registry.attach<Camera>(camera, player);
553 
554 // removes tags from their owners
555 registry.remove<PlayingCharacter>();
556 registry.remove<Camera>();
557 ```
558 
559 In case a tag already has an owner, its content can be updated by means of the
560 `set` member function template and the ownership of the tag can be transferred
561 to another entity using the `move` member function template:
562 
563 ```
564 // replaces the content of the given tag
565 Point &point = registry.set<Point>(1.f, 1.f);
566 
567 // transfers the ownership of the tag to another entity
568 entity_type prev = registry.move<Point>(next);
569 ```
570 
571 If in doubt about whether or not a tag already has an owner, the `has` member
572 function template may be useful:
573 
574 ```cpp
575 bool b = registry.has<PlayingCharacter>();
576 ```
577 
578 References to tags can be retrieved simply by doing this:
579 
580 ```cpp
581 const auto &cregistry = registry;
582 
583 // either a non-const reference ...
584 PlayingCharacter &player = registry.get<PlayingCharacter>();
585 
586 // ... or a const one
587 const Camera &camera = cregistry.get<Camera>();
588 ```
589 
590 The `get` member function template gives direct access to the tag as stored in
591 the underlying data structures of the registry.
592 
593 As shown above, in almost all the cases the entity identifier isn't required.
594 Since a single instance component can have only one associated entity, it
595 doesn't make much sense to mention it explicitly.<br/>
596 To find out who the owner is, just do the following:
597 
598 ```cpp
599 auto player = registry.attachee<PlayingCharacter>();
600 ```
601 
602 Note that iterating tags isn't possible for obvious reasons. Tags give direct
603 access to single entities and nothing more.
604 
605 ### Runtime components
606 
607 Defining components at runtime is useful to support plugins and mods in general.
608 However, it seems impossible with a tool designed around a bunch of templates.
609 Indeed it's not that difficult.<br/>
610 Of course, some features cannot be easily exported into a runtime
611 environment. As an example, sorting a group of components defined at runtime
612 isn't for free if compared to most of the other operations. However, the basic
613 functionalities of an entity-component system such as `EnTT` fit the problem
614 perfectly and can also be used to manage runtime components if required.<br/>
615 All that is necessary to do it is to know the identifiers of the components. An
616 identifier is nothing more than a number or similar that can be used at runtime
617 to work with the type system.
618 
619 In `EnTT`, identifiers are easily accessible:
620 
621 ```cpp
622 entt::DefaultRegistry registry;
623 
624 // standard component identifier
625 auto ctype = registry.component<Position>();
626 
627 // single instance component identifier
628 auto ttype = registry.tag<PlayingCharacter>();
629 ```
630 
631 Once the identifiers are made available, almost everything becomes pretty
632 simple.
633 
634 #### A journey through a plugin
635 
636 `EnTT` comes with an example (actually a test) that shows how to integrate
637 compile-time and runtime components in a stack based JavaScript environment. It
638 uses [`Duktape`](https://github.com/svaarala/duktape) under the hood, mainly
639 because I wanted to learn how it works at the time I was writing the code.
640 
641 The code is not production-ready and overall performance can be highly improved.
642 However, I sacrificed optimizations in favor of a more readable piece of code. I
643 hope I succeeded.<br/>
644 Note also that this isn't neither the only nor (probably) the best way to do it.
645 In fact, the right way depends on the scripting language and the problem one is
646 facing in general.<br/>
647 That being said, feel free to use it at your own risk.
648 
649 The basic idea is that of creating a compile-time component aimed to map all the
650 runtime components assigned to an entity.<br/>
651 Identifiers come in use to address the right function from a map when invoked
652 from the runtime environment and to filter entities when iterating.<br/>
653 With a bit of gymnastic, one can narrow views and improve the performance to
654 some extent but it was not the goal of the example.
655 
656 ### Sorting: is it possible?
657 
658 It goes without saying that sorting entities and components is possible with
659 `EnTT`.<br/>
660 In fact, there are two functions that respond to slightly different needs:
661 
662 * Components can be sorted directly:
663 
664  ```cpp
665  registry.sort<Renderable>([](const auto &lhs, const auto &rhs) {
666  return lhs.z < rhs.z;
667  });
668  ```
669 
670 * Components can be sorted according to the order imposed by another component:
671 
672  ```cpp
673  registry.sort<Movement, Physics>();
674  ```
675 
676  In this case, instances of `Movement` are arranged in memory so that cache
677  misses are minimized when the two components are iterated together.
678 
679 ### Snapshot: complete vs continuous
680 
681 The `Registry` class offers basic support to serialization.<br/>
682 It doesn't convert components and tags to bytes directly, there wasn't the need
683 of another tool for serialization out there. Instead, it accepts an opaque
684 object with a suitable interface (namely an _archive_) to serialize its internal
685 data structures and restore them later. The way types and instances are
686 converted to a bunch of bytes is completely in charge to the archive and thus to
687 the users.
688 
689 The goal of the serialization part is to allow users to make both a dump of the
690 entire registry or a narrower snapshot, that is to select only the components
691 and the tags in which they are interested.<br/>
692 Intuitively, the use cases are different. As an example, the first approach is
693 suitable for local save/restore functionalities while the latter is suitable for
694 creating client-server applications and for transferring somehow parts of the
695 representation side to side.
696 
697 To take a snapshot of the registry, use the `snapshot` member function. It
698 returns a temporary object properly initialized to _save_ the whole registry or
699 parts of it.
700 
701 Example of use:
702 
703 ```cpp
704 OutputArchive output;
705 
706 registry.snapshot()
707  .entities(output)
708  .destroyed(output)
709  .component<AComponent, AnotherComponent>(output)
710  .tag<MyTag>(output);
711 ```
712 
713 It isn't necessary to invoke all these functions each and every time. What
714 functions to use in which case mostly depends on the goal and there is not a
715 golden rule to do that.
716 
717 The `entities` member function asks to the registry to serialize all the
718 entities that are still in use along with their versions. On the other side, the
719 `destroyed` member function tells to the registry to serialize the entities that
720 have been destroyed and are no longer in use.<br/>
721 These two functions can be used to save and restore the whole set of entities
722 with the versions they had during serialization.
723 
724 The `component` member function is a function template the aim of which is to
725 store aside components. The presence of a template parameter list is a
726 consequence of a couple of design choices from the past and in the present:
727 
728 * First of all, there is no reason to force an user to serialize all the
729  components at once and most of the times it isn't desiderable. As an example,
730  in case the stuff for the HUD in a game is put into the registry for some
731  reasons, its components can be freely discarded during a serialization step
732  because probably the software already knows how to reconstruct the HUD
733  correctly from scratch.
734 
735 * Furthermore, the registry makes heavy use of _type-erasure_ techniques
736  internally and doesn't know at any time what types of components it contains.
737  Therefore being explicit at the call point is mandatory.
738 
739 The `tag` member function is similar to the previous one, apart from the fact
740 that it works with tags and not with components.<br/>
741 Note also that both `component` and `tag` store items along with entities. It
742 means that they work properly without a call to the `entities` member function.
743 
744 Once a snapshot is created, there exist mainly two _ways_ to load it: as a whole
745 and in a kind of _continuous mode_.<br/>
746 The following sections describe both loaders and archives in details.
747 
748 #### Snapshot loader
749 
750 A snapshot loader requires that the destination registry be empty and loads all
751 the data at once while keeping intact the identifiers that the entities
752 originally had.<br/>
753 To do that, the registry offers a member function named `restore` that returns a
754 temporary object properly initialized to _restore_ a snapshot.
755 
756 Example of use:
757 
758 ```cpp
759 InputArchive input;
760 
761 registry.restore()
762  .entities()
763  .destroyed()
764  .component<AComponent, AnotherComponent>(output)
765  .tag<MyTag>(output)
766  .orphans();
767 ```
768 
769 It isn't necessary to invoke all these functions each and every time. What
770 functions to use in which case mostly depends on the goal and there is not a
771 golden rule to do that. For obvious reasons, what is important is that the data
772 are restored in exactly the same order in which they were serialized.
773 
774 The `entities` and `destroyed` member functions restore the sets of entities and
775 the versions that the entities originally had at the source.
776 
777 The `component` member function restores all and only the components specified
778 and assigns them to the right entities. Note that the template parameter list
779 must be exactly the same used during the serialization. The same applies to the
780 `tag` member function.
781 
782 The `orphans` member function literally destroys those entities that have
783 neither components nor tags. It's usually useless if the snapshot is a full dump
784 of the source. However, in case all the entities are serialized but only few
785 components and tags are saved, it could happen that some of the entities have
786 neither components nor tags once restored. The best users can do to deal with
787 them is to destroy those entities and thus update their versions.
788 
789 #### Continuous loader
790 
791 A continuous loader is designed to load data from a source registry to a
792 (possibly) non-empty destination. The loader can accomodate in a registry more
793 than one snapshot in a sort of _continuous loading_ that updates the
794 destination one step at a time.<br/>
795 Identifiers that entities originally had are not transferred to the target.
796 Instead, the loader maps remote identifiers to local ones while restoring a
797 snapshot. Because of that, this kind of loader offers a way to update
798 automatically identifiers that are part of components or tags (as an example, as
799 data members or gathered in a container).<br/>
800 Another difference with the snapshot loader is that the continuous loader does
801 not need to work with the private data structures of a registry. Furthermore, it
802 has an internal state that must persist over time. Therefore, there is no reason
803 to create it by means of a registry, or to limit its lifetime to that of a
804 temporary object.
805 
806 Example of use:
807 
808 ```cpp
809 entt::ContinuousLoader<entity_type> loader{registry};
810 InputArchive input;
811 
812 loader.entities(input)
813  .destroyed(input)
814  .component<AComponent, AnotherComponent>(input)
815  .component<DirtyComponent>(input, &DirtyComponent::parent, &DirtyComponent::child)
816  .tag<MyTag>(input)
817  .tag<DirtyTag>(input, &DirtyTag::container)
818  .orphans()
819  .shrink();
820 ```
821 
822 It isn't necessary to invoke all these functions each and every time. What
823 functions to use in which case mostly depends on the goal and there is not a
824 golden rule to do that. For obvious reasons, what is important is that the data
825 are restored in exactly the same order in which they were serialized.
826 
827 The `entities` and `destroyed` member functions restore groups of entities and
828 map each entity to a local counterpart when required. In other terms, for each
829 remote entity identifier not yet registered by the loader, the latter creates a
830 local identifier so that it can keep the local entity in sync with the remote
831 one.
832 
833 The `component` and `tag` member functions restore all and only the components
834 and the tags specified and assign them to the right entities.<br/>
835 In case the component or the tag contains entities itself (either as data
836 members of type `entity_type` or as containers of entities), the loader can
837 update them automatically. To do that, it's enough to specify the data members
838 to update as shown in the example. If the component or the tag was in the middle
839 of the template parameter list during serialization, multiple commands are
840 required during a restore:
841 
842 ```cpp
843 registry.snapshot().component<ASimpleComponent, AnotherSimpleComponent, AMoreComplexComponent, TheLastComponent>();
844 
845 // ...
846 
847 loader
848  .component<ASimpleComponent, AnotherSimpleComponent>(input)
849  .component<AMoreComplexComponent>(input, &AMoreComplexComponent::entity);
850  .component<TheLastComponent>(input);
851 ```
852 
853 The `orphans` member function literally destroys those entities that have
854 neither components nor tags after a restore. It has exactly the same purpose
855 described in the previous section and works the same way.
856 
857 Finally, `shrink` helps to purge local entities that no longer have a remote
858 conterpart. Users should invoke this member function after restoring each
859 snapshot, unless they know exactly what they are doing.
860 
861 #### Archives
862 
863 Archives must publicly expose a predefined set of member functions. The API is
864 straightforward and consists only of a group of function call operators that
865 are invoked by the registry.
866 
867 In particular:
868 
869 * An output archive, the one used when creating a snapshot, must expose a
870  function call operator with the following signature to store entities:
871 
872  ```cpp
873  void operator()(Entity);
874  ```
875 
876  Where `Entity` is the type of the entities used by the registry.<br/>
877  In addition, it must accept the types of both the components and the tags to
878  serialize. Therefore, given a type `T` (either a component or a tag), it must
879  contain a function call operator with the following signature:
880 
881  ```cpp
882  void operator()(const T &);
883  ```
884 
885  The output archive can freely decide how to serialize the data. The register
886  is not affected at all by the decision.
887 
888 * An input archive, the one used when restoring a snapshot, must expose a
889  function call operator with the following signature to load entities:
890 
891  ```cpp
892  void operator()(Entity &);
893  ```
894 
895  Where `Entity` is the type of the entities used by the registry. Each time the
896  function is invoked, the archive must read the next element from the
897  underlying storage and copy it in the given variable.<br/>
898  In addition, it must accept the types of both the components and the tags to
899  restore. Therefore, given a type `T` (either a component or a tag), it must
900  contain a function call operator with the following signature:
901 
902  ```cpp
903  void operator()(T &);
904  ```
905 
906  Every time such an operator is invoked, the archive must read the next element
907  from the underlying storage and copy it in the given variable.
908 
909 #### One example to rule them all
910 
911 `EnTT` comes with some examples (actually some tests) that show how to integrate
912 a well known library for serialization as an archive. It uses
913 [`Cereal C++`](https://uscilab.github.io/cereal/) under the hood, mainly
914 because I wanted to learn how it works at the time I was writing the code.
915 
916 The code is not production-ready and it isn't neither the only nor (probably)
917 the best way to do it. However, feel free to use it at your own risk.
918 
919 The basic idea is to store everything in a group of queues in memory, then bring
920 everything back to the registry with different loaders.
921 
922 ## View: to persist or not to persist?
923 
924 First of all, it is worth answering an obvious question: why views?<br/>
925 Roughly speaking, they are a good tool to enforce single responsibility. A
926 system that has access to a registry can create and destroy entities, as well as
927 assign and remove components. On the other side, a system that has access to a
928 view can only iterate entities and their components, then read or update the
929 data members of the latter.<br/>
930 It is a subtle difference that can help designing a better software sometimes.
931 
932 There are mainly three kinds of views: standard (also known as `View`),
933 persistent (also known as `PersistentView`) and raw (also known as
934 `RawView`).<br/>
935 All of them have pros and cons to take in consideration. In particular:
936 
937 * Standard views:
938 
939  Pros:
940  * They work out-of-the-box and don't require any dedicated data structure.
941  * Creating and destroying them isn't expensive at all because they don't have
942  any type of initialization.
943  * They are the best tool for iterating entities for a single component.
944  * They are the best tool for iterating entities for multiple components when
945  one of the components is assigned to a significantly low number of entities.
946  * They don't affect any other operations of the registry.
947 
948  Cons:
949  * Their performance tend to degenerate when the number of components to
950  iterate grows up and the most of the entities have all of them.
951 
952 * Persistent views:
953 
954  Pros:
955  * Once prepared, creating and destroying them isn't expensive at all because
956  they don't have any type of initialization.
957  * They are the best tool for iterating entities for mmultiple components and
958  most entities have them all.
959 
960  Cons:
961  * They have dedicated data structures and thus affect the memory usage to a
962  minimal extent.
963  * If not previously prepared, the first time they are used they go through an
964  initialization step that could take a while.
965  * They affect to a minimum the creation and destruction of entities and
966  components. In other terms: the more persistent views there will be, the
967  less performing will be creating and destroying entities and components.
968 
969 * Raw views:
970 
971  Pros:
972  * They work out-of-the-box and don't require any dedicated data structure.
973  * Creating and destroying them isn't expensive at all because they don't have
974  any type of initialization.
975  * They are the best tool for iterating components when it is not necessary to
976  know which entities they belong to.
977  * They don't affect any other operations of the registry.
978 
979  Cons:
980  * They can be used to iterate only one type of component at a time.
981  * They don't return the entity to which a component belongs to the caller.
982 
983 To sum up and as a rule of thumb:
984 * Use a raw view to iterate components only (no entities) for a given type.
985 * Use a standard view to iterate entities for a single component.
986 * Use a standard view to iterate entities for multiple components when a
987  significantly low number of entities have one of the components.
988 * Use a standard view in all those cases where a persistent view would give a
989  boost to performance but the iteration isn't performed frequently.
990 * Prepare and use a persistent view in all the other cases.
991 
992 To easily iterate entities and components, all the views offer the common
993 `begin` and `end` member functions that allow users to use a view in a typical
994 range-for loop. Almost all the views offer also a *more functional* `each`
995 member function that accepts a callback for convenience.<br/>
996 Continue reading for more details or refer to the
997 [official documentation](https://skypjack.github.io/entt/).
998 
999 ### Standard View
1000 
1001 A standard view behaves differently if it's constructed for a single component
1002 or if it has been requested to iterate multiple components. Even the API is
1003 different in the two cases.<br/>
1004 All that they share is the way they are created by means of a registry:
1005 
1006 ```cpp
1007 // single component standard view
1008 auto single = registry.view<Position>();
1009 
1010 // multi component standard view
1011 auto multi = registry.view<Position, Velocity>();
1012 ```
1013 
1014 For all that remains, it's worth discussing them separately.<br/>
1015 
1016 #### Single component standard view
1017 
1018 Single component standard views are specialized in order to give a boost in
1019 terms of performance in all the situation. This kind of views can access the
1020 underlying data structures directly and avoid superfluous checks.<br/>
1021 They offer a bunch of functionalities to get the number of entities they are
1022 going to return and a raw access to the entity list as well as to the component
1023 list. It's also possible to ask a view if it contains a given entity.<br/>
1024 Refer to the [official documentation](https://skypjack.github.io/entt/) for all
1025 the details.
1026 
1027 There is no need to store views around for they are extremely cheap to
1028 construct, even though they can be copied without problems and reused freely. In
1029 fact, they return newly created and correctly initialized iterators whenever
1030 `begin` or `end` are invoked.<br/>
1031 To iterate a single component standard view, either use it in range-for loop:
1032 
1033 ```cpp
1034 auto view = registry.view<Renderable>();
1035 
1036 for(auto entity: view) {
1037  Renderable &renderable = view.get(entity);
1038 
1039  // ...
1040 }
1041 ```
1042 
1043 Or rely on the `each` member function to iterate entities and get all their
1044 components at once:
1045 
1046 ```cpp
1047 registry.view<Renderable>().each([](auto entity, auto &renderable) {
1048  // ...
1049 });
1050 ```
1051 
1052 Performance are more or less the same. The best approach depends mainly on
1053 whether all the components have to be accessed or not.
1054 
1055 **Note**: prefer the `get` member function of a view instead of the `get` member
1056 function template of a registry during iterations, if possible. However, keep in
1057 mind that it works only with the components of the view itself.
1058 
1059 #### Multi component standard view
1060 
1061 Multi component standard views iterate entities that have at least all the given
1062 components in their bags. During construction, these views look at the number of
1063 entities available for each component and pick up a reference to the smallest
1064 set of candidates in order to speed up iterations.<br/>
1065 They offer fewer functionalities than their companion views for single
1066 component. In particular, a multi component standard view exposes utility
1067 functions to reset its internal state (optimization purposes) and to get the
1068 estimated number of entities it is going to return. It's also possible to ask a
1069 view if it contains a given entity.<br/>
1070 Refer to the [official documentation](https://skypjack.github.io/entt/) for all
1071 the details.
1072 
1073 There is no need to store views around for they are extremely cheap to
1074 construct, even though they can be copied without problems and reused freely. In
1075 fact, they return newly created and correctly initialized iterators whenever
1076 `begin` or `end` are invoked.<br/>
1077 To iterate a multi component standard view, either use it in range-for loop:
1078 
1079 ```cpp
1080 auto view = registry.view<Position, Velocity>();
1081 
1082 for(auto entity: view) {
1083  // a component at a time ...
1084  Position &position = view.get<Position>(entity);
1085  Velocity &velocity = view.get<Velocity>(entity);
1086 
1087  // ... or multiple components at once
1088  std::tuple<Position &, Velocity &> tup = view.get<Position, Velocity>(entity);
1089 
1090  // ...
1091 }
1092 ```
1093 
1094 Or rely on the `each` member function to iterate entities and get all their
1095 components at once:
1096 
1097 ```cpp
1098 registry.view<Position, Velocity>().each([](auto entity, auto &position, auto &velocity) {
1099  // ...
1100 });
1101 ```
1102 
1103 Performance are more or less the same. The best approach depends mainly on
1104 whether all the components have to be accessed or not.
1105 
1106 **Note**: prefer the `get` member function of a view instead of the `get` member
1107 function template of a registry during iterations, if possible. However, keep in
1108 mind that it works only with the components of the view itself.
1109 
1110 ### Persistent View
1111 
1112 A persistent view returns all the entities and only the entities that have at
1113 least the given components. Moreover, it's guaranteed that the entity list is
1114 tightly packed in memory for fast iterations.<br/>
1115 In general, persistent views don't stay true to the order of any set of
1116 components unless users explicitly sort them.
1117 
1118 Persistent views can be used only to iterate multiple components. Create them
1119 as it follows:
1120 
1121 ```cpp
1122 auto view = registry.persistent<Position, Velocity>();
1123 ```
1124 
1125 There is no need to store views around for they are extremely cheap to
1126 construct, even though they can be copied without problems and reused freely. In
1127 fact, they return newly created and correctly initialized iterators whenever
1128 `begin` or `end` are invoked.<br/>
1129 That being said, persistent views perform an initialization step the very first
1130 time they are constructed and this could be quite costly. To avoid it, consider
1131 asking to the registry to _prepare_ them when no entities have been created yet:
1132 
1133 ```cpp
1134 registry.prepare<Position, Velocity>();
1135 ```
1136 
1137 If the registry is empty, preparation is extremely fast. Moreover the `prepare`
1138 member function template is idempotent. Feel free to invoke it even more than
1139 once: if the view has been already prepared before, the function returns
1140 immediately and does nothing.
1141 
1142 A persistent view offers a bunch of functionalities to get the number of
1143 entities it's going to return, a raw access to the entity list and the
1144 possibility to sort the underlying data structures according to the order of one
1145 of the components for which it has been constructed. It's also possible to ask a
1146 view if it contains a given entity.<br/>
1147 Refer to the [official documentation](https://skypjack.github.io/entt/) for all
1148 the details.
1149 
1150 To iterate a persistent view, either use it in range-for loop:
1151 
1152 ```cpp
1153 auto view = registry.persistent<Position, Velocity>();
1154 
1155 for(auto entity: view) {
1156  // a component at a time ...
1157  Position &position = view.get<Position>(entity);
1158  Velocity &velocity = view.get<Velocity>(entity);
1159 
1160  // ... or multiple components at once
1161  std::tuple<Position &, Velocity &> tup = view.get<Position, Velocity>(entity);
1162 
1163  // ...
1164 }
1165 ```
1166 
1167 Or rely on the `each` member function to iterate entities and get all their
1168 components at once:
1169 
1170 ```cpp
1171 registry.persistent<Position, Velocity>().each([](auto entity, auto &position, auto &velocity) {
1172  // ...
1173 });
1174 ```
1175 
1176 Performance are more or less the same. The best approach depends mainly on
1177 whether all the components have to be accessed or not.
1178 
1179 **Note**: prefer the `get` member function of a view instead of the `get` member
1180 function template of a registry during iterations, if possible. However, keep in
1181 mind that it works only with the components of the view itself.
1182 
1183 ### Raw View
1184 
1185 Raw views return all the components of a given type. This kind of views can
1186 access components directly and avoid extra indirections as if components were
1187 accessed via an entity identifier.<br/>
1188 They offer a bunch of functionalities to get the number of instances they are
1189 going to return and a raw access to the entity list as well as to the component
1190 list.<br/>
1191 Refer to the [official documentation](https://skypjack.github.io/entt/) for all
1192 the details.
1193 
1194 There is no need to store views around for they are extremely cheap to
1195 construct, even though they can be copied without problems and reused freely. In
1196 fact, they return newly created and correctly initialized iterators whenever
1197 `begin` or `end` are invoked.<br/>
1198 To iterate a raw view, use it in range-for loop:
1199 
1200 ```cpp
1201 auto view = registry.raw<Renderable>();
1202 
1203 for(auto &&component: raw) {
1204  // ...
1205 }
1206 ```
1207 
1208 **Note**: raw views don't have the `each` nor the `get` member function for
1209 obvious reasons. The former would only return the components and therefore it
1210 would be redundant, the latter isn't required at all.
1211 
1212 ### Give me everything
1213 
1214 Views are narrow windows on the entire list of entities. They work by filtering
1215 entities according to their components.<br/>
1216 In some cases there may be the need to iterate all the entities still in use
1217 regardless of their components. The registry offers a specific member function
1218 to do that:
1219 
1220 ```cpp
1221 registry.each([](auto entity) {
1222  // ...
1223 });
1224 ```
1225 
1226 It returns to the caller all the entities that are still in use by means of the
1227 given function.<br/>
1228 As a rule of thumb, consider using a view if the goal is to iterate entities
1229 that have a determinate set of components. A view is usually much faster than
1230 combining this function with a bunch of custom tests.<br/>
1231 In all the other cases, this is the way to go.
1232 
1233 There exists also another member function to use to retrieve orphans. An orphan
1234 is an entity that is still in use and has neither assigned components nor
1235 tags.<br/>
1236 The signature of the function is the same of `each`:
1237 
1238 ```cpp
1239 registry.orphans([](auto entity) {
1240  // ...
1241 });
1242 ```
1243 
1244 To test the _orphanity_ of a single entity, use the member function `orphan`
1245 instead. It accepts a valid entity identifer as an argument and returns true in
1246 case the entity is an orphan, false otherwise.
1247 
1248 In general, all these functions can result in poor performance.<br/>
1249 `each` is fairly slow because of some checks it performs on each and every
1250 entity. For similar reasons, `orphans` can be even slower. Both functions should
1251 not be used frequently to avoid the risk of a performance hit.
1252 
1253 ## Side notes
1254 
1255 * Entity identifiers are numbers and nothing more. They are not classes and they
1256  have no member functions at all. As already mentioned, do no try to inspect or
1257  modify an entity descriptor in any way.
1258 
1259 * As shown in the examples above, the preferred way to get references to the
1260  components while iterating a view is by using the view itself. It's a faster
1261  alternative to the `get` member function template that is part of the API of
1262  the `Registry`. This is because the registry must ensure that a pool for the
1263  given component exists before to use it; on the other side, views force the
1264  construction of the pools for all their components and access them directly,
1265  thus avoiding all the checks.
1266 
1267 * Most of the _ECS_ available out there have an annoying limitation (at least
1268  from my point of view): entities and components cannot be created and/or
1269  destroyed during iterations.<br/>
1270  `EnTT` partially solves the problem with a few limitations:
1271 
1272  * Creating entities and components is allowed during iterations.
1273  * Deleting an entity or removing its components is allowed during
1274  iterations if it's the one currently returned by a view. For all the
1275  other entities, destroying them or removing their components isn't
1276  allowed and it can result in undefined behavior.
1277 
1278  Iterators are invalidated and the behavior is undefined if an entity is
1279  modified or destroyed and it's not the one currently returned by the
1280  view.<br/>
1281  To work around it, possible approaches are:
1282 
1283  * Store aside the entities and the components to be removed and perform the
1284  operations at the end of the iteration.
1285  * Mark entities and components with a proper tag component that indicates
1286  they must be purged, then perform a second iteration to clean them up one
1287  by one.
1288 
1289 * Views and thus their iterators aren't thread safe. Do no try to iterate a set
1290  of components and modify the same set concurrently.<br/>
1291  That being said, as long as a thread iterates the entities that have the
1292  component `X` or assign and removes that component from a set of entities,
1293  another thread can safely do the same with components `Y` and `Z` and
1294  everything will work like a charm.<br/>
1295  As a trivial example, users can freely execute the rendering system and
1296  iterate the renderable entities while updating a physic component concurrently
1297  on a separate thread.
1298 
1299 * In general, the entire registry isn't thread safe as it is. Thread safety
1300  isn't something that users should want out of the box for several reasons.
1301  Just to mention one of them: performance.<br/>
1302  This kind of entity-component systems can be used in single threaded
1303  applications as well as along with async stuff. Moreover, typical thread based
1304  models for ECS don't require a fully thread safe registry to work. Actually
1305  one could reach the goal with the registry as it is while working with most of
1306  the common models, after all.<br/>
1307  Because of the few reasons mentioned above and many others not mentioned,
1308  users are completely responsible for synchronization whether required.
1309 
1310 # Crash Course: core functionalities
1311 
1312 The `EnTT` framework comes with a bunch of core functionalities mostly used by
1313 the other parts of the library itself.<br/>
1314 Hardly users of the framework will include these features in their code, but
1315 it's worth describing what `EnTT` offers so as not to reinvent the wheel in case
1316 of need.
1317 
1318 ## Compile-time identifiers
1319 
1320 Sometimes it's useful to be able to give unique identifiers to types at
1321 compile-time.<br/>
1322 There are plenty of different solutions out there and I could have used one of
1323 them. However, I decided to spend my time to define a compact and versatile tool
1324 that fully embraces what the modern C++ has to offer.
1325 
1326 The _result of my efforts_ is the `ident` `constexpr` variable:
1327 
1328 ```cpp
1329 #include <ident.hpp>
1330 
1331 // defines the identifiers for the given types
1332 constexpr auto identifiers = entt::ident<AType, AnotherType>;
1333 
1334 // ...
1335 
1336 switch(aTypeIdentifier) {
1337 case identifers.get<AType>():
1338  // ...
1339  break;
1340 case identifers.get<AnotherType>():
1341  // ...
1342  break;
1343 default:
1344  // ...
1345 }
1346 ```
1347 
1348 This is all what the variable has to offer: a `get` member function that returns
1349 a numerical identifier for the given type. It can be used in any context where
1350 constant expressions are required.
1351 
1352 As long as the list remains unchanged, identifiers are also guaranteed to be the
1353 same for every run. In case they have been used in a production environment and
1354 a type has to be removed, one can just use a placeholder to left the other
1355 identifiers unchanged:
1356 
1357 ```cpp
1358 template<typename> struct IgnoreType {};
1359 
1360 constexpr auto identifiers = entt::ident<
1361  ATypeStillValid,
1362  IgnoreType<ATypeNoLongerValid>,
1363  AnotherTypeStillValid
1364 >;
1365 ```
1366 
1367 A bit ugly to see, but it works at least.
1368 
1369 ## Runtime identifiers
1370 
1371 Sometimes it's useful to be able to give unique identifiers to types at
1372 runtime.<br/>
1373 There are plenty of different solutions out there and I could have used one of
1374 them. In fact, I adapted the most common one to my requirements and used it
1375 extensively within the entire framework.
1376 
1377 It's the `Family` class. Here is an example of use directly from the
1378 entity-component system:
1379 
1380 ```cpp
1381 using component_family = entt::Family<struct InternalRegistryComponentFamily>;
1382 
1383 // ...
1384 
1385 template<typename Component>
1386 component_type component() const noexcept {
1387  return component_family::type<Component>();
1388 }
1389 ```
1390 
1391 This is all what a _family_ has to offer: a `type` member function that returns
1392 a numerical identifier for the given type.
1393 
1394 Please, note that identifiers aren't guaranteed to be the same for every run.
1395 Indeed it mostly depends on the flow of execution.
1396 
1397 ## Hashed strings
1398 
1399 A hashed string is a zero overhead resource identifier. Users can use
1400 human-readable identifiers in the codebase while using their numeric
1401 counterparts at runtime, thus without affecting performance.<br/>
1402 The class has an implicit `constexpr` constructor that chews a bunch of
1403 characters. Once created, all what one can do with it is getting back the
1404 original string or converting it into a number.<br/>
1405 The good part is that a hashed string can be used wherever a constant expression
1406 is required and no _string-to-number_ conversion will take place at runtime if
1407 used carefully.
1408 
1409 Example of use:
1410 
1411 ```cpp
1412 auto load(entt::HashedString::hash_type resource) {
1413  // uses the numeric representation of the resource to load and return it
1414 }
1415 
1416 auto resource = load(entt::HashedString{"gui/background"});
1417 ```
1418 
1419 ### Conflicts
1420 
1421 The hashed string class uses internally FNV-1a to compute the numeric
1422 counterpart of a string. Because of the _pigeonhole principle_, conflicts are
1423 possible. This is a fact.<br/>
1424 There is no silver bullet to solve the problem of conflicts when dealing with
1425 hashing functions. In this case, the best solution seemed to be to give up.
1426 That's all.<br/>
1427 After all, human-readable resource identifiers aren't something strictly defined
1428 and over which users have not the control. Choosing a slightly different
1429 identifier is probably the best solution to make the conflict disappear in this
1430 case.
1431 
1432 # Crash Course: service locator
1433 
1434 Usually service locators are tightly bound to the services they expose and it's
1435 hard to define a general purpose solution. This template based implementation
1436 tries to fill the gap and to get rid of the burden of defining a different
1437 specific locator for each application.<br/>
1438 This class is tiny, partially unsafe and thus risky to use. Moreover it doesn't
1439 fit probably most of the scenarios in which a service locator is required. Look
1440 at it as a small tool that can sometimes be useful if the user knows how to
1441 handle it.
1442 
1443 The API is straightforward. The basic idea is that services are implemented by
1444 means of interfaces and rely on polymorphism.<br/>
1445 The locator is instantiated with the base type of the service if any and a
1446 concrete implementation is provided along with all the parameters required to
1447 initialize it. As an example:
1448 
1449 ```cpp
1450 // the service has no base type, a locator is used to treat it as a kind of singleton
1451 entt::ServiceLocator<MyService>::set(params...);
1452 
1453 // sets up an opaque service
1454 entt::ServiceLocator<AudioInterface>::set<AudioImplementation>(params...);
1455 
1456 // resets (destroys) the service
1457 entt::ServiceLocator<AudioInterface>::reset();
1458 ```
1459 
1460 The locator can also be queried to know if an active service is currently set
1461 and to retrieve it if necessary (either as a pointer or as a reference):
1462 
1463 ```cpp
1464 // no service currently set
1465 auto empty = entt::ServiceLocator<AudioInterface>::empty();
1466 
1467 // gets a (possibly empty) shared pointer to the service ...
1468 std::shared_ptr<AudioInterface> ptr = entt::ServiceLocator<AudioInterface>::get();
1469 
1470 // ... or a reference, but it's undefined behaviour if the service isn't set yet
1471 AudioInterface &ref = entt::ServiceLocator<AudioInterface>::ref();
1472 ```
1473 
1474 A common use is to wrap the different locators in a container class, creating
1475 aliases for the various services:
1476 
1477 ```cpp
1478 struct Locator {
1479  using Camera = entt::ServiceLocator<CameraInterface>;
1480  using Audio = entt::ServiceLocator<AudioInterface>;
1481  // ...
1482 };
1483 
1484 // ...
1485 
1486 void init() {
1487  Locator::Camera::set<CameraNull>();
1488  Locator::Audio::set<AudioImplementation>(params...);
1489  // ...
1490 }
1491 ```
1492 
1493 # Crash Course: cooperative scheduler
1494 
1495 Sometimes processes are a useful tool to work around the strict definition of a
1496 system and introduce logic in a different way, usually without resorting to the
1497 introduction of other components.
1498 
1499 The `EnTT` framework offers a minimal support to this paradigm by introducing a
1500 few classes that users can use to define and execute cooperative processes.
1501 
1502 ## The process
1503 
1504 A typical process must inherit from the `Process` class template that stays true
1505 to the CRTP idiom. Moreover, derived classes must specify what's the intended
1506 type for elapsed times.
1507 
1508 A process should expose publicly the following member functions whether
1509 required (note that it isn't required to define a function unless the derived
1510 class wants to _override_ the default behavior):
1511 
1512 * `void update(Delta, void *);`
1513 
1514  It's invoked once per tick until a process is explicitly aborted or it
1515  terminates either with or without errors. Even though it's not mandatory to
1516  declare this member function, as a rule of thumb each process should at
1517  least define it to work properly. The `void *` parameter is an opaque pointer
1518  to user data (if any) forwarded directly to the process during an update.
1519 
1520 * `void init(void *);`
1521 
1522  It's invoked at the first tick, immediately before an update. The `void *`
1523  parameter is an opaque pointer to user data (if any) forwarded directly to the
1524  process during an update.
1525 
1526 * `void succeeded();`
1527 
1528  It's invoked in case of success, immediately after an update and during the
1529  same tick.
1530 
1531 * `void failed();`
1532 
1533  It's invoked in case of errors, immediately after an update and during the
1534  same tick.
1535 
1536 * `void aborted();`
1537 
1538  It's invoked only if a process is explicitly aborted. There is no guarantee
1539  that it executes in the same tick, this depends solely on whether the
1540  process is aborted immediately or not.
1541 
1542 Derived classes can also change the internal state of a process by invoking
1543 `succeed` and `fail`, as well as `pause` and `unpause` the process itself. All
1544 these are protected member functions made available to be able to manage the
1545 life cycle of a process from a derived class.
1546 
1547 Here is a minimal example for the sake of curiosity:
1548 
1549 ```cpp
1550 struct MyProcess: entt::Process<MyProcess, std::uint32_t> {
1551  using delta_type = std::uint32_t;
1552 
1553  void update(delta_type delta, void *) {
1554  remaining = delta > remaining ? delta_type{] : (remaining - delta);
1555 
1556  // ...
1557 
1558  if(!remaining) {
1559  succeed();
1560  }
1561  }
1562 
1563  void init(void *data) {
1564  remaining = *static_cast<delta_type *>(data);
1565  }
1566 
1567 private:
1568  delta_type remaining;
1569 };
1570 ```
1571 
1572 ### Adaptor
1573 
1574 Lambdas and functors can't be used directly with a scheduler for they are not
1575 properly defined processes with managed life cycles.<br/>
1576 This class helps in filling the gap and turning lambdas and functors into
1577 full featured processes usable by a scheduler.
1578 
1579 The function call operator has a signature similar to the one of the `update`
1580 function of a process but for the fact that it receives two extra arguments to
1581 call whenever a process is terminated with success or with an error:
1582 
1583 ```cpp
1584 void(Delta delta, void *data, auto succeed, auto fail);
1585 ```
1586 
1587 Parameters have the following meaning:
1588 
1589 * `delta` is the elapsed time.
1590 * `data` is an opaque pointer to user data if any, `nullptr` otherwise.
1591 * `succeed` is a function to call when a process terminates with success.
1592 * `fail` is a function to call when a process terminates with errors.
1593 
1594 Both `succeed` and `fail` accept no parameters at all.
1595 
1596 Note that usually users shouldn't worry about creating adaptors at all. A
1597 scheduler creates them internally each and every time a lambda or a functor is
1598 used as a process.
1599 
1600 ## The scheduler
1601 
1602 A cooperative scheduler runs different processes and helps managing their life
1603 cycles.
1604 
1605 Each process is invoked once per tick. If it terminates, it's removed
1606 automatically from the scheduler and it's never invoked again. Otherwise it's
1607 a good candidate to run once more the next tick.<br/>
1608 A process can also have a child. In this case, the process is replaced with
1609 its child when it terminates if it returns with success. In case of errors,
1610 both the process and its child are discarded. This way, it's easy to create
1611 chain of processes to run sequentially.
1612 
1613 Using a scheduler is straightforward. To create it, users must provide only the
1614 type for the elapsed times and no arguments at all:
1615 
1616 ```cpp
1617 Scheduler<std::uint32_t> scheduler;
1618 ```
1619 
1620 It has member functions to query its internal data structures, like `empty` or
1621 `size`, as well as a `clear` utility to reset it to a clean state:
1622 
1623 ```cpp
1624 // checks if there are processes still running
1625 bool empty = scheduler.empty();
1626 
1627 // gets the number of processes still running
1628 Scheduler<std::uint32_t>::size_type size = scheduler.size();
1629 
1630 // resets the scheduler to its initial state and discards all the processes
1631 scheduler.clear();
1632 ```
1633 
1634 To attach a process to a scheduler there are mainly two ways:
1635 
1636 * If the process inherits from the `Process` class template, it's enough to
1637  indicate its type and submit all the parameters required to construct it to
1638  the `attach` member function:
1639 
1640  ```cpp
1641  scheduler.attach<MyProcess>("foobar");
1642  ```
1643 
1644 * Otherwise, in case of a lambda or a functor, it's enough to provide an
1645  instance of the class to the `attach` member function:
1646 
1647  ```cpp
1648  scheduler.attach([](auto...){ /* ... */ });
1649  ```
1650 
1651 In both cases, the return value is an opaque object that offers a `then` member
1652 function to use to create chains of processes to run sequentially.<br/>
1653 As a minimal example of use:
1654 
1655 ```cpp
1656 // schedules a task in the form of a lambda function
1657 scheduler.attach([](auto delta, void *, auto succeed, auto fail) {
1658  // ...
1659 })
1660 // appends a child in the form of another lambda function
1661 .then([](auto delta, void *, auto succeed, auto fail) {
1662  // ...
1663 })
1664 // appends a child in the form of a process class
1665 .then<MyProcess>();
1666 ```
1667 
1668 To update a scheduler and thus all its processes, the `update` member function
1669 is the way to go:
1670 
1671 ```cpp
1672 // updates all the processes, no user data are provided
1673 scheduler.update(delta);
1674 
1675 // updates all the processes and provides them with custom data
1676 scheduler.update(delta, &data);
1677 ```
1678 
1679 In addition to these functions, the scheduler offers an `abort` member function
1680 that can be used to discard all the running processes at once:
1681 
1682 ```cpp
1683 // aborts all the processes abruptly ...
1684 scheduler.abort(true);
1685 
1686 // ... or gracefully during the next tick
1687 scheduler.abort();
1688 ```
1689 
1690 # Crash Course: resource management
1691 
1692 Resource management is usually one of the most critical part of a software like
1693 a game. Solutions are often tuned to the particular application. There exist
1694 several approaches and all of them are perfectly fine as long as they fit the
1695 requirements of the piece of software in which they are used.<br/>
1696 Examples are loading everything on start, loading on request, predictive
1697 loading, and so on.
1698 
1699 The `EnTT` framework doesn't pretend to offer a _one-fits-all_ solution for the
1700 different cases. Instead, it offers a minimal and perhaps trivial cache that can
1701 be useful most of the time during prototyping and sometimes even in a production
1702 environment.<br/>
1703 For those interested in the subject, the plan is to improve it considerably over
1704 time in terms of performance, memory usage and functionalities. Hoping to make
1705 it, of course, one step at a time.
1706 
1707 ## The resource, the loader and the cache
1708 
1709 There are three main actors in the model: the resource, the loader and the
1710 cache.
1711 
1712 The _resource_ is whatever the user wants it to be. An image, a video, an audio,
1713 whatever. There are no limits.<br/>
1714 As a minimal example:
1715 
1716 ```cpp
1717 struct MyResource { const int value; };
1718 ```
1719 
1720 A _loader_ is a class the aim of which is to load a specific resource. It has to
1721 inherit directly from the dedicated base class as in the following example:
1722 
1723 ```cpp
1724 struct MyLoader final: entt::ResourceLoader<MyLoader, MyResource> {
1725  // ...
1726 };
1727 ```
1728 
1729 Where `MyResource` is the type of resources it creates.<br/>
1730 A resource loader must also expose a public const member function named `load`
1731 that accepts a variable number of arguments and returns a shared pointer to a
1732 resource.<br/>
1733 As an example:
1734 
1735 ```cpp
1736 struct MyLoader: entt::ResourceLoader<MyLoader, MyResource> {
1737  std::shared_ptr<MyResource> load(int value) const {
1738  // ...
1739  return std::shared_ptr<MyResource>(new MyResource{ value });
1740  }
1741 };
1742 ```
1743 
1744 In general, resource loaders should not have a state or retain data of any type.
1745 They should let the cache manage their resources instead.<br/>
1746 As a side note, base class and CRTP idiom aren't strictly required with the
1747 current implementation. One could argue that a cache can easily work with
1748 loaders of any type. However, future changes won't be breaking ones by forcing
1749 the use of a base class today and that's why the model is already in its place.
1750 
1751 Finally, a cache is a specialization of a class template tailored to a specific
1752 resource:
1753 
1754 ```cpp
1755 using MyResourceCache = entt::ResourceCache<MyResource>;
1756 
1757 // ...
1758 
1759 MyResourceCache cache{};
1760 ```
1761 
1762 The idea is to create different caches for different types of resources and to
1763 manage each one independently and in the most appropriate way.<br/>
1764 As a (very) trivial example, audio tracks can survive in most of the scenes of
1765 an application while meshes can be associated with a single scene and then
1766 discarded when the user leaves it.
1767 
1768 A cache offers a set of basic functionalities to query its internal state and to
1769 _organize_ it:
1770 
1771 ```cpp
1772 // gets the number of resources managed by a cache
1773 auto size = cache.size();
1774 
1775 // checks if a cache contains at least a valid resource
1776 auto empty = cache.empty();
1777 
1778 // clears a cache and discards its content
1779 cache.clear();
1780 ```
1781 
1782 Besides these member functions, it contains what is needed to load, use and
1783 discard resources of the given type.<br/>
1784 Before to explore this part of the interface, it makes sense to mention how
1785 resources are identified. The type of the identifiers to use is defined as:
1786 
1787 ```cpp
1788 entt::ResourceCache<Resource>::resource_type
1789 ```
1790 
1791 Where `resource_type` is an alias for `entt::HashedString`. Therefore, resource
1792 identifiers are created explicitly as in the following example:
1793 
1794 ```cpp
1795 constexpr auto identifier = entt::ResourceCache<Resource>::resource_type{"my/resource/identifier"};
1796 // this is equivalent to the following
1797 constexpr auto hs = entt::HashedString{"my/resource/identifier"};
1798 ```
1799 
1800 The class `HashedString` is described in a dedicated section, so I won't do in
1801 details here.
1802 
1803 Resources are loaded and thus stored in a cache through the `load` member
1804 function. It accepts the loader to use as a template parameter, the resource
1805 identifier and the parameters used to construct the resource as arguments:
1806 
1807 ```cpp
1808 // uses the identifier declared above
1809 cache.load<MyLoader>(identifier, 0);
1810 
1811 // uses a const char * directly as an identifier
1812 cache.load<MyLoader>("another/identifier", 42);
1813 ```
1814 
1815 The return value can be used to know if the resource has been loaded correctly.
1816 In case the loader returns an invalid pointer or the resource already exists in
1817 the cache, a false value is returned:
1818 
1819 ```cpp
1820 if(!cache.load<MyLoader>("another/identifier", 42)) {
1821  // ...
1822 }
1823 ```
1824 
1825 Unfortunately, in this case there is no way to know what was the problem
1826 exactly. However, before trying to load a resource or after an error, one can
1827 use the `contains` member function to know if a cache already contains a
1828 specific resource:
1829 
1830 ```cpp
1831 auto exists = cache.contains("my/identifier");
1832 ```
1833 
1834 There exists also a member function to use to force a reload of an already
1835 existing resource if needed:
1836 
1837 ```cpp
1838 auto result = cache.reload<MyLoader>("another/identifier", 42);
1839 ```
1840 
1841 As above, the function returns true in case of success, false otherwise. The
1842 sole difference in this case is that an error necessarily means that the loader
1843 has failed for some reasons to load the resource.<br/>
1844 Note that the `reload` member function is a kind of alias of the following
1845 snippet:
1846 
1847 ```cpp
1848 cache.discard(identifier);
1849 cache.load<MyLoader>(identifier, 42);
1850 ```
1851 
1852 Where the `discard` member function is used to get rid of a resource if loaded.
1853 In case the cache doesn't contain a resource for the given identifier, the
1854 function does nothing and returns immediately.
1855 
1856 So far, so good. Resources are finally loaded and stored within the cache.<br/>
1857 They are returned to the users in the form of handles. To get one of them:
1858 
1859 ```cpp
1860 auto handle = cache.handle("my/identifier");
1861 ```
1862 
1863 The idea behind a handle is the same of the flyweight pattern. In other terms,
1864 resources aren't copied around. Instead, instances are shared between handles.
1865 Users of a resource owns a handle and it guarantees that a resource isn't
1866 destroyed until all the handles are destroyed, even if the resource itself is
1867 removed from the cache.<br/>
1868 Handles are tiny objects both movable and copyable. They returns the contained
1869 resource as a const reference on request:
1870 
1871 * By means of the `get` member function:
1872 
1873  ```cpp
1874  const auto &resource = handle.get();
1875  ```
1876 
1877 * Using the proper cast operator:
1878 
1879  ```cpp
1880  const auto &resource = handle;
1881  ```
1882 
1883 * Through the dereference operator:
1884 
1885  ```cpp
1886  const auto &resource = *handle;
1887  ```
1888 
1889 The resource can also be accessed directly using the arrow operator if required:
1890 
1891 ```cpp
1892 auto value = handle->value;
1893 ```
1894 
1895 To test if a handle is still valid, the cast operator to `bool` allows the users
1896 to use it in a guard:
1897 
1898 ```cpp
1899 if(handle) {
1900  // ...
1901 }
1902 ```
1903 
1904 Finally, in case there is the need to load a resource and thus to get a handle
1905 without storing the resource itself in the cache, users can rely on the `temp`
1906 member function template.<br/>
1907 The declaration is similar to the one of `load` but for the fact that it doesn't
1908 return a boolean value. Instead, it returns a (possibly invalid) handle for the
1909 resource:
1910 
1911 ```cpp
1912 auto handle = cache.temp<MyLoader>("another/identifier", 42);
1913 ```
1914 
1915 Do not forget to test the handle for validity. Otherwise, getting the reference
1916 to the resource it points may result in undefined behavior.
1917 
1918 # Crash Course: events, signals and everything in between
1919 
1920 Signals are usually a core part of games and software architectures in
1921 general.<br/>
1922 Roughly speaking, they help to decouple the various parts of a system while
1923 allowing them to communicate with each other somehow.
1924 
1925 The so called _modern C++_ comes with a tool that can be useful in these terms,
1926 the `std::function`. As an example, it can be used to create delegates.<br/>
1927 However, there is no guarantee that an `std::function` does not perform
1928 allocations under the hood and this could be problematic sometimes. Furthermore,
1929 it solves a problem but may not adapt well to other requirements that may arise
1930 from time to time.
1931 
1932 In case that the flexibility and potential of an `std::function` are not
1933 required or where you are looking for something different, the `EnTT` framework
1934 offers a full set of classes to solve completely different problems.
1935 
1936 ## Signals
1937 
1938 There are two types of signal handlers in `EnTT`, internally called _managed_
1939 and _unmanaged_.<br/>
1940 They differ in the way they work around the tradeoff between performance, memory
1941 usage and safety. Managed listeners must be wrapped in an `std::shared_ptr` and
1942 the sink will take care of disconnecting them whenever they die. Unmanaged
1943 listeners can be any kind of objects and the client is in charge of connecting
1944 and disconnecting them from a sink to avoid crashes due to different lifetimes.
1945 
1946 ### Managed signal handler
1947 
1948 A managed signal handler works with weak pointers to classes and pointers to
1949 member functions as well as pointers to free functions. References are
1950 automatically removed when the instances to which they point are freed.<br/>
1951 In other terms, users can simply connect a listener and forget about it, thus
1952 getting rid of the burden of controlling its lifetime. The drawback is that
1953 listeners must be allocated on the dynamic storage and wrapped into an
1954 `std::shared_ptr`. Performance and memory management can suffer from this in
1955 real world softwares.
1956 
1957 To create an instance of this type of handler, the function type is all what is
1958 needed:
1959 
1960 ```cpp
1961 entt::Signal<void(int, char)> signal;
1962 ```
1963 
1964 From now on, free functions and member functions that respect the given
1965 signature can be easily connected to and disconnected from the signal:
1966 
1967 ```cpp
1968 void foo(int, char) { /* ... */ }
1969 
1970 struct S {
1971  void bar(int, char) { /* ... */ }
1972 };
1973 
1974 // ...
1975 
1976 auto instance = std::make_shared<S>();
1977 
1978 signal.connect<&foo>();
1979 signal.connect<S, &S::bar>(instance);
1980 
1981 // ...
1982 
1983 signal.disconnect<&foo>();
1984 
1985 // disconnect a specific member function of an instance ...
1986 signal.disconnect<S, &S::bar>(instance);
1987 
1988 // ... or an instance as a whole
1989 signal.disconnect(instance);
1990 ```
1991 
1992 Once listeners are attached (or even if there are no listeners at all), events
1993 and data in general can be published through a signal by means of the `publish`
1994 member function:
1995 
1996 ```cpp
1997 signal.publish(42, 'c');
1998 ```
1999 
2000 This is more or less all what a managed signal handler has to offer.<br/>
2001 A bunch of other member functions are exposed actually. As an example, there is
2002 a method to use to know how many listeners a managed signal handler contains
2003 (`size`) or if it contains at least a listener (`empty`), to reset it to its
2004 initial state (`clear`) and even to swap two handlers (`swap`).<br/>
2005 Refer to the [official documentation](https://skypjack.github.io/entt/) for all
2006 the details.
2007 
2008 ### Unmanaged signal handler
2009 
2010 An unmanaged signal handler works with naked pointers to classes and pointers to
2011 member functions as well as pointers to free functions. Removing references when
2012 the instances to which they point are freed is in charge to the users.<br/>
2013 In other terms, users must explicitly disconnect a listener before to delete the
2014 class to which it belongs, thus taking care of the lifetime of each instance. On
2015 the other side, performance shouldn't be affected that much by the presence of
2016 such a signal handler.
2017 
2018 The API of an unmanaged signal handler is similar to the one of a managed signal
2019 handler.<br/>
2020 The most important difference is that it comes in two forms: with and without a
2021 collector. In case it is associated with a collector, all the values returned by
2022 the listeners can be literally _collected_ and used later by the caller.<br/>
2023 
2024 **Note**: collectors are allowed only in case of function types whose the return
2025 type isn't `void` for obvious reasons.
2026 
2027 To create instances of this type of handler there exist mainly two ways:
2028 
2029 ```cpp
2030 // no collector type
2031 entt::SigH<void(int, char)> signal;
2032 
2033 // explicit collector type
2034 entt::SigH<void(int, char), MyCollector<bool>> collector;
2035 ```
2036 
2037 As expected, an unmanaged signal handler offers all the basic functionalities
2038 required to know how many listeners it contains (`size`) or if it contains at
2039 least a listener (`empty`), to reset it to its initial state (`clear`) and even
2040 to swap two handlers (`swap`).
2041 
2042 Besides them, there are member functions to use both to connect and disconnect
2043 listeners in all their forms:
2044 
2045 ```cpp
2046 void foo(int, char) { /* ... */ }
2047 
2048 struct S {
2049  void bar(int, char) { /* ... */ }
2050 };
2051 
2052 // ...
2053 
2054 S instance;
2055 
2056 signal.connect<&foo>();
2057 signal.connect<S, &S::bar>(&instance);
2058 
2059 // ...
2060 
2061 signal.disconnect<&foo>();
2062 
2063 // disconnect a specific member function of an instance ...
2064 signal.disconnect<S, &S::bar>(&instance);
2065 
2066 // ... or an instance as a whole
2067 signal.disconnect(&instance);
2068 ```
2069 
2070 Once listeners are attached (or even if there are no listeners at all), events
2071 and data in general can be published through a signal by means of the `publish`
2072 member function:
2073 
2074 ```cpp
2075 signal.publish(42, 'c');
2076 ```
2077 
2078 To collect data, the `collect` member function should be used instead. Below is
2079 a minimal example to show how to use it:
2080 
2081 ```cpp
2082 struct MyCollector {
2083  std::vector<int> vec{};
2084 
2085  bool operator()(int v) noexcept {
2086  vec.push_back(v);
2087  return true;
2088  }
2089 };
2090 
2091 int f() { return 0; }
2092 int g() { return 1; }
2093 
2094 // ...
2095 
2096 entt::SigH<int(), MyCollector<int>> signal;
2097 
2098 signal.connect<&f>();
2099 signal.connect<&g>();
2100 
2101 MyCollector collector = signal.collect();
2102 
2103 assert(collector.vec[0] == 0);
2104 assert(collector.vec[1] == 1);
2105 ```
2106 
2107 As shown above, a collector must expose a function operator that accepts as an
2108 argument a type to which the return type of the listeners can be converted.
2109 Moreover, it has to return a boolean value that is false to stop collecting
2110 data, true otherwise. This way one can avoid calling all the listeners in case
2111 it isn't necessary.
2112 
2113 ## Compile-time event bus
2114 
2115 A bus can be used to create a compile-time backbone for event management.<br/>
2116 The intended use is as a base class, which is the opposite of what the signals
2117 are meant for. Internally it uses either managed or unmanaged signal handlers,
2118 that is why there exist both a managed and an unmanaged event bus.
2119 
2120 The API of a bus is a kind of subset of the one of a signal. First of all, it
2121 requires that all the types of events are specified when the bus is declared:
2122 
2123 ```cpp
2124 struct AnEvent { int value; };
2125 struct AnotherEvent {};
2126 
2127 // define a managed bus that works with std::shared_ptr/std::weak_ptr
2128 entt::ManagedBus<AnEvent, AnotherEvent> managed;
2129 
2130 // define an unmanaged bus that works with naked pointers
2131 entt::UnmanagedBus<AnEvent, AnotherEvent> unmanaged;
2132 ```
2133 
2134 For the sake of brevity, below is described the interface of the sole unmanaged
2135 bus. The interface of the managed bus is almost the same but for the fact that
2136 it accepts smart pointers instead of naked pointers.
2137 
2138 In order to register an instance of a class to a bus, its type must expose one
2139 or more member functions named `receive` of which the return types are `void`
2140 and the argument lists are `const E &`, for each type of event `E`.<br/>
2141 The `reg` member function is the way to go to register such an instance:
2142 
2143 ```cpp
2144 struct Listener
2145 {
2146  void receive(const AnEvent &) { /* ... */ }
2147  void receive(const AnotherEvent &) { /* ... */ }
2148 };
2149 
2150 // ...
2151 
2152 Listener listener;
2153 bus.reg(&listener);
2154 ```
2155 
2156 To disconnect an instance of a class from a bus, use the `unreg` member
2157 function instead:
2158 
2159 ```cpp
2160 bus.unreg(&listener);
2161 ```
2162 
2163 Each function that respects the accepted signature is automatically registered
2164 and/or unregistered. Note that invoking `unreg` with an instance of a class that
2165 hasn't been previously registered is a perfectly valid operation.
2166 
2167 Free functions can be registered and unregistered as well by means of the
2168 dedicated member functions, namely `connect` and `disconnect`:
2169 
2170 ```cpp
2171 void foo(const AnEvent &) { /* ... */ }
2172 void bar(const AnotherEvent &) { /* ... */ }
2173 
2174 // ...
2175 
2176 bus.connect<AnEvent, &foo>();
2177 bus.connect<AnotherEvent, &bar>();
2178 
2179 // ...
2180 
2181 bus.disconnect<AnEvent, &foo>();
2182 bus.disconnect<AnotherEvent, &bar>();
2183 ```
2184 
2185 Whenever the need to send an event arises, it can be done through the `publish`
2186 member function:
2187 
2188 ```cpp
2189 bus.publish<AnEvent>(42);
2190 bus.publish<AnotherEvent>();
2191 ```
2192 
2193 Finally, there are another few functions to use to query the internal state of a
2194 bus like `empty` and `size` whose meaning is quite intuitive.
2195 
2196 ## Delegate
2197 
2198 A delegate can be used as general purpose invoker with no memory overhead for
2199 free functions and member functions provided along with an instance on which
2200 to invoke them.<br/>
2201 It does not claim to be a drop-in replacement for an `std::function`, so do not
2202 expect to use it whenever an `std::function` fits well. However, it can be used
2203 to send opaque delegates around to be used to invoke functions as needed.
2204 
2205 The interface is trivial. It offers a default constructor to create empty
2206 delegates:
2207 
2208 ```cpp
2209 entt::Delegate<int(int)> delegate{};
2210 ```
2211 
2212 All what is needed to create an instance is to specify the type of the function
2213 the delegate will _contain_, that is the signature of the free function or the
2214 member function one wants to assign to it.
2215 
2216 Attempting to use an empty delegate by invoking its function call operator
2217 results in undefined behavior, most likely a crash actually. Before to use a
2218 delegate, it must be initialized.<br/>
2219 There exist two functions to do that, both named `connect`:
2220 
2221 ```cpp
2222 int f(int i) { return i; }
2223 
2224 struct MyStruct {
2225  int f(int i) { return i }
2226 };
2227 
2228 // bind a free function to the delegate
2229 delegate.connect<&f>();
2230 
2231 // bind a member function to the delegate
2232 MyStruct instance;
2233 delegate.connect<MyStruct, &MyStruct::f>(&instance);
2234 ```
2235 
2236 It hasn't a `disconnect` counterpart. Instead, there exists a `reset` member
2237 function to clear it.<br/>
2238 Finally, to invoke a delegate, the function call operator is the way to go as
2239 usual:
2240 
2241 ```cpp
2242 auto ret = delegate(42);
2243 ```
2244 
2245 Probably too much small and pretty poor of functionalities, but the delegate
2246 class can help in a lot of cases and it has shown that it is worth keeping it
2247 within the framework.
2248 
2249 ## Event dispatcher
2250 
2251 The event dispatcher class is designed so as to be used in a loop. It allows
2252 users both to trigger immediate events or to queue events to be published all
2253 together once per tick.<br/>
2254 Internally it uses either managed or unmanaged signal handlers, that is why
2255 there exist both a managed and an unmanaged event dispatcher.
2256 
2257 This class shares part of its API with the one of the signals, but it doesn't
2258 require that all the types of events are specified when declared:
2259 
2260 ```cpp
2261 // define a managed dispatcher that works with std::shared_ptr/std::weak_ptr
2262 entt::Dispatcher<entt::Signal> managed{};
2263 
2264 // define an unmanaged dispatcher that works with naked pointers
2265 entt::Dispatcher<entt::SigH> unmanaged{};
2266 ```
2267 
2268 Actually there exist two aliases for the classes shown in the previous example:
2269 `entt::ManagedDispatcher` and `entt::UnmanagedDispatcher`.
2270 
2271 For the sake of brevity, below is described the interface of the sole unmanaged
2272 dispatcher. The interface of the managed dispatcher is almost the same but for
2273 the fact that it accepts smart pointers instead of naked pointers.
2274 
2275 In order to register an instance of a class to a dispatcher, its type must
2276 expose one or more member functions of which the return types are `void` and the
2277 argument lists are `const E &`, for each type of event `E`.<br/>
2278 To ease the development, member functions that are named `receive` are
2279 automatically detected and have not to be explicitly specified when registered.
2280 In all the other cases, the name of the member function aimed to receive the
2281 event must be provided to the `connect` member function:
2282 
2283 ```cpp
2284 struct AnEvent { int value; };
2285 struct AnotherEvent {};
2286 
2287 struct Listener
2288 {
2289  void receive(const AnEvent &) { /* ... */ }
2290  void method(const AnotherEvent &) { /* ... */ }
2291 };
2292 
2293 // ...
2294 
2295 Listener listener;
2296 dispatcher.connect<AnEvent>(&listener);
2297 dispatcher.connect<AnotherEvent, Listener, &Listener::method>(&listener);
2298 ```
2299 
2300 The `disconnect` member function follows the same pattern and can be used to
2301 selectively remove listeners:
2302 
2303 ```cpp
2304 dispatcher.disconnect<AnEvent>(&listener);
2305 dispatcher.disconnect<AnotherEvent, Listener, &Listener::method>(&listener);
2306 ```
2307 
2308 The `trigger` member function serves the purpose of sending an immediate event
2309 to all the listeners registered so far. It offers a convenient approach that
2310 relieves the user from having to create the event itself. Instead, it's enough
2311 to specify the type of event and provide all the parameters required to
2312 construct it.<br/>
2313 As an example:
2314 
2315 ```cpp
2316 dispatcher.trigger<AnEvent>(42);
2317 dispatcher.trigger<AnotherEvent>();
2318 ```
2319 
2320 Listeners are invoked immediately, order of execution isn't guaranteed. This
2321 method can be used to push around urgent messages like an _is terminating_
2322 notification on a mobile app.
2323 
2324 On the other hand, the `enqueue` member function queues messages together and
2325 allows to maintain control over the moment they are sent to listeners. The
2326 signature of this method is more or less the same of `trigger`:
2327 
2328 ```cpp
2329 dispatcher.enqueue<AnEvent>(42);
2330 dispatcher.enqueue<AnotherEvent>();
2331 ```
2332 
2333 Events are stored aside until the `update` member function is invoked, then all
2334 the messages that are still pending are sent to the listeners at once:
2335 
2336 ```cpp
2337 dispatcher.update();
2338 ```
2339 
2340 This way users can embed the dispatcher in a loop and literally dispatch events
2341 once per tick to their systems.
2342 
2343 ## Event emitter
2344 
2345 A general purpose event emitter thought mainly for those cases where it comes to
2346 working with asynchronous stuff.<br/>
2347 Originally designed to fit the requirements of
2348 [`uvw`](https://github.com/skypjack/uvw) (a wrapper for `libuv` written in
2349 modern C++), it was adapted later to be included in this library.
2350 
2351 To create a custom emitter type, derived classes must inherit directly from the
2352 base class as:
2353 
2354 ```cpp
2355 struct MyEmitter: Emitter<MyEmitter> {
2356  // ...
2357 }
2358 ```
2359 
2360 The full list of accepted types of events isn't required. Handlers are created
2361 internally on the fly and thus each type of event is accepted by default.
2362 
2363 Whenever an event is published, an emitter provides the listeners with a
2364 reference to itself along with a const reference to the event. Therefore
2365 listeners have an handy way to work with it without incurring in the need of
2366 capturing a reference to the emitter itself.<br/>
2367 In addition, an opaque object is returned each time a connection is established
2368 between an emitter and a listener, allowing the caller to disconnect them at a
2369 later time.<br/>
2370 The opaque object used to handle connections is both movable and copyable. On
2371 the other side, an event emitter is movable but not copyable by default.
2372 
2373 To create new instances of an emitter, no arguments are required:
2374 
2375 ```cpp
2376 MyEmitter emitter{};
2377 ```
2378 
2379 Listeners must be movable and callable objects (free functions, lambdas,
2380 functors, `std::function`s, whatever) whose function type is:
2381 
2382 ```cpp
2383 void(const Event &, MyEmitter &)
2384 ```
2385 
2386 Where `Event` is the type of event they want to listen.<br/>
2387 There are two ways to attach a listener to an event emitter that differ
2388 slightly from each other:
2389 
2390 * To register a long-lived listener, use the `on` member function. It is meant
2391  to register a listener designed to be invoked more than once for the given
2392  event type.<br/>
2393  As an example:
2394 
2395  ```cpp
2396  auto conn = emitter.on<MyEvent>([](const MyEvent &event, MyEmitter &emitter) {
2397  // ...
2398  });
2399  ```
2400 
2401  The connection object can be freely discarded. Otherwise, it can be used later
2402  to disconnect the listener if required.
2403 
2404 * To register a short-lived listener, use the `once` member function. It is
2405  meant to register a listener designed to be invoked only once for the given
2406  event type. The listener is automatically disconnected after the first
2407  invocation.<br/>
2408  As an example:
2409 
2410  ```cpp
2411  auto conn = emitter.once<MyEvent>([](const MyEvent &event, MyEmitter &emitter) {
2412  // ...
2413  });
2414  ```
2415 
2416  The connection object can be freely discarded. Otherwise, it can be used later
2417  to disconnect the listener if required.
2418 
2419 In both cases, the connection object can be used with the `erase` member
2420 function:
2421 
2422 ```cpp
2423 emitter.erase(conn);
2424 ```
2425 
2426 There are also two member functions to use either to disconnect all the
2427 listeners for a given type of event or to clear the emitter:
2428 
2429 ```cpp
2430 // removes all the listener for the specific event
2431 emitter.clear<MyEvent>();
2432 
2433 // removes all the listeners registered so far
2434 emitter.clear();
2435 ```
2436 
2437 To send an event to all the listeners that are interested in it, the `publish`
2438 member function offers a convenient approach that relieves the user from having
2439 to create the event:
2440 
2441 ```cpp
2442 struct MyEvent { int i; };
2443 
2444 // ...
2445 
2446 emitter.publish<MyEvent>(42);
2447 ```
2448 
2449 Finally, the `empty` member function tests if there exists at least either a
2450 listener registered with the event emitter or to a given type of event:
2451 
2452 ```cpp
2453 bool empty;
2454 
2455 // checks if there is any listener registered for the specific event
2456 empty = emitter.empty<MyEvent>();
2457 
2458 // checks it there are listeners registered with the event emitter
2459 empty = emitter.empty();
2460 ```
2461 
2462 In general, the event emitter is a handy tool when the derived classes _wrap_
2463 asynchronous operations, because it introduces a _nice-to-have_ model based on
2464 events and listeners that kindly hides the complexity behind the scenes. However
2465 it is not limited to such uses.
2466 
2467 # Contributors
2468 
2469 If you want to contribute, please send patches as pull requests against the
2470 branch `master`.<br/>
2471 See the
2472 [contributors list](https://github.com/skypjack/entt/blob/master/AUTHORS) to
2473 know who has participated so far.
2474 
2475 # License
2476 
2477 Code and documentation Copyright (c) 2018 Michele Caini.<br/>
2478 Code released under
2479 [the MIT license](https://github.com/skypjack/entt/blob/master/LICENSE).
2480 Docs released under
2481 [Creative Commons](https://github.com/skypjack/entt/blob/master/docs/LICENSE).
2482 
2483 # Support
2484 
2485 ## Donation
2486 
2487 Developing and maintaining `EnTT` takes some time and lots of coffee. I'd like
2488 to add more and more functionalities in future and turn it in a full-featured
2489 framework.<br/>
2490 If you want to support this project, you can offer me an espresso. I'm from
2491 Italy, we're used to turning the best coffee ever in code. If you find that
2492 it's not enough, feel free to support me the way you prefer.<br/>
2493 Take a look at the donation button at the top of the page for more details or
2494 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).
2495 
2496 ## Hire me
2497 
2498 If you start using `EnTT` and need help, if you want a new feature and want me
2499 to give it the highest priority, if you have any other reason to contact me:
2500 do not hesitate. I'm available for hiring.<br/>
2501 Feel free to take a look at my [profile](https://github.com/skypjack) and
2502 contact me by mail.
+
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 # Table of Contents
9 
10 * [Introduction](#introduction)
11 * [Build Instructions](#build-instructions)
12 * [Crash Course: entity-component system](#crash-course-entity-component-system)
13  * [Design choices](#design-choices)
14  * [A bitset-free entity-component system](#a-bitset-free-entity-component-system)
15  * [Pay per use](#pay-per-use)
16  * [Vademecum](#vademecum)
17  * [The Registry, the Entity and the Component](#the-registry-the-entity-and-the-component)
18  * [Single instance components](#single-instance-components)
19  * [Observe changes](#observe-changes)
20  * [Who let the tags out?](#who-let-the-tags-out)
21  * [Runtime components](#runtime-components)
22  * [A journey through a plugin](#a-journey-through-a-plugin)
23  * [Sorting: is it possible?](#sorting-is-it-possible)
24  * [Snapshot: complete vs continuous](#snapshot-complete-vs-continuous)
25  * [Snapshot loader](#snapshot-loader)
26  * [Continuous loader](#continuous-loader)
27  * [Archives](#archives)
28  * [One example to rule them all](#one-example-to-rule-them-all)
29  * [Prototype](#prototype)
30  * [Helpers](#helpers)
31  * [Dependency function](#dependency-function)
32  * [View: to persist or not to persist?](#view-to-persist-or-not-to-persist)
33  * [Standard View](#standard-view)
34  * [Single component standard view](#single-component-standard-view)
35  * [Multi component standard view](#multi-component-standard-view)
36  * [Persistent View](#persistent-view)
37  * [Raw View](#raw-view)
38  * [Give me everything](#give-me-everything)
39  * [Side notes](#side-notes)
40 * [Crash Course: core functionalities](#crash-course-core-functionalities)
41  * [Compile-time identifiers](#compile-time-identifiers)
42  * [Runtime identifiers](#runtime-identifiers)
43  * [Hashed strings](#hashed-strings)
44 * [Crash Course: service locator](#crash-course-service-locator)
45 * [Crash Course: cooperative scheduler](#crash-course-cooperative-scheduler)
46  * [The process](#the-process)
47  * [The scheduler](#the-scheduler)
48 * [Crash Course: resource management](#crash-course-resource-management)
49  * [The resource, the loader and the cache](#the-resource-the-loader-and-the-cache)
50 * [Crash Course: events, signals and everything in between](#crash-course-events-signals-and-everything-in-between)
51  * [Signals](#signals)
52  * [Delegate](#delegate)
53  * [Event dispatcher](#event-dispatcher)
54  * [Event emitter](#event-emitter)
55 * [Packaging Tools](#packaging-tools)
56 * [EnTT in Action](#entt-in-action)
57 * [License](#license)
58 * [Support](#support)
59  * [Donation](#donation)
60  * [Hire me](#hire-me)
61 
62 # Introduction
63 
64 `EnTT` is a header-only, tiny and easy to use framework written in modern
65 C++.<br/>
66 It was originally designed entirely around an architectural pattern called _ECS_
67 that is used mostly in game development. For further details:
68 
69 * [Entity Systems Wiki](http://entity-systems.wikidot.com/)
70 * [Evolve Your Hierarchy](http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/)
71 * [ECS on Wikipedia](https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system)
72 
73 A long time ago, the sole entity-component system was part of the project. After
74 a while the codebase has grown and more and more classes have become part of the
75 repository.<br/>
76 That's why today it's called _the EnTT Framework_.
77 
78 Currently, `EnTT` is tested on Linux, Microsoft Windows and OS X. It has proven
79 to work also on both Android and iOS.<br/>
80 Most likely it will not be problematic on other systems as well, but has not
81 been sufficiently tested so far.
82 
83 ## The framework
84 
85 `EnTT` was written initially as a faster alternative to other well known and
86 open source entity-component systems. Nowadays the `EnTT` framework is moving
87 its first steps. Much more will come in the future and hopefully I'm going to
88 work on it for a long time.<br/>
89 Requests for feature, PR, suggestions ad feedback are highly appreciated.
90 
91 If you find you can help me and want to contribute to the `EnTT` framework with
92 your experience or you do want to get part of the project for some other
93 reasons, feel free to contact me directly (you can find the mail in the
94 [profile](https://github.com/skypjack)).<br/>
95 I can't promise that each and every contribution will be accepted, but I can
96 assure that I'll do my best to take them all seriously.
97 
98 ### State of the art
99 
100 Here is a brief list of what it offers today:
101 
102 * Statically generated integer identifiers for types (assigned either at
103  compile-time or at runtime).
104 * A constexpr utility for human readable resource identifiers.
105 * An incredibly fast entity-component system based on sparse sets, with its own
106  views and a _pay for what you use_ policy to adjust performance and memory
107  usage according to users' requirements.
108 * Actor class for those who aren't confident with entity-component systems.
109 * The smallest and most basic implementation of a service locator ever seen.
110 * A cooperative scheduler for processes of any type.
111 * All what is needed for resource management (cache, loaders, handles).
112 * Delegates, signal handlers (with built-in support for collectors) and a tiny
113  event dispatcher.
114 * A general purpose event emitter, that is a CRTP idiom based class template.
115 * An event dispatcher for immediate and delayed events to integrate in loops.
116 * ...
117 * Any other business.
118 
119 Consider it a work in progress. For more details and an updated list, please
120 refer to the [online documentation](https://skypjack.github.io/entt/). It
121 probably contains much more. Moreover, the whole API is fully documented in-code
122 for those who are brave enough to read it.<br/>
123 Continue reading to know how the different parts of the project work or follow
124 the link above to take a look at the API reference.
125 
126 ## Code Example
127 
128 ```cpp
129 #include <entt/entt.hpp>
130 #include <cstdint>
131 
132 struct Position {
133  float x;
134  float y;
135 };
136 
137 struct Velocity {
138  float dx;
139  float dy;
140 };
141 
142 void update(entt::DefaultRegistry &registry) {
143  auto view = registry.view<Position, Velocity>();
144 
145  for(auto entity: view) {
146  // gets only the components that are going to be used ...
147 
148  auto &velocity = view.get<Velocity>(entity);
149 
150  velocity.dx = 0.;
151  velocity.dy = 0.;
152 
153  // ...
154  }
155 }
156 
157 void update(std::uint64_t dt, entt::DefaultRegistry &registry) {
158  registry.view<Position, Velocity>().each([dt](auto entity, auto &position, auto &velocity) {
159  // gets all the components of the view at once ...
160 
161  position.x += velocity.dx * dt;
162  position.y += velocity.dy * dt;
163 
164  // ...
165  });
166 }
167 
168 int main() {
169  entt::DefaultRegistry registry;
170  std::uint64_t dt = 16;
171 
172  for(auto i = 0; i < 10; ++i) {
173  auto entity = registry.create();
174  registry.assign<Position>(entity, i * 1.f, i * 1.f);
175  if(i % 2 == 0) { registry.assign<Velocity>(entity, i * .1f, i * .1f); }
176  }
177 
178  update(dt, registry);
179  update(registry);
180 
181  // ...
182 }
183 ```
184 
185 ## Motivation
186 
187 I started working on `EnTT` because of the wrong reason: my goal was to design
188 an entity-component system that beated another well known open source solution
189 in terms of performance and used (possibly) less memory in the average
190 case.<br/>
191 In the end, I did it, but it wasn't much satisfying. Actually it wasn't
192 satisfying at all. The fastest and nothing more, fairly little indeed. When I
193 realized it, I tried hard to keep intact the great performance of `EnTT` and to
194 add all the features I wanted to see in *my own library* at the same time.
195 
196 Today `EnTT` is finally what I was looking for: still faster than its
197 _competitors_, lower memory usage in the average case, a really good API and an
198 amazing set of features. And even more, of course.
199 
200 ## Performance
201 
202 As it stands right now, `EnTT` is just fast enough for my requirements if
203 compared to my first choice (it was already amazingly fast actually).<br/>
204 Below is a comparison between the two (both of them compiled with GCC 7.3.0 on a
205 Dell XPS 13 out of the mid 2014):
206 
207 | Benchmark | EntityX (compile-time) | EnTT |
208 |-----------|-------------|-------------|
209 | Create 1M entities | 0.0147s | **0.0046s** |
210 | Destroy 1M entities | 0.0053s | **0.0045s** |
211 | Standard view, 1M entities, one component | 0.0012s | **1.9e-07s** |
212 | Standard view, 1M entities, two components | 0.0012s | **3.8e-07s** |
213 | Standard view, 1M entities, two components<br/>Half of the entities have all the components | 0.0009s | **3.8e-07s** |
214 | Standard view, 1M entities, two components<br/>One of the entities has all the components | 0.0008s | **1.0e-06s** |
215 | Persistent view, 1M entities, two components | 0.0012s | **2.8e-07s** |
216 | Standard view, 1M entities, five components | 0.0010s | **7.0e-07s** |
217 | Persistent view, 1M entities, five components | 0.0010s | **2.8e-07s** |
218 | Standard view, 1M entities, ten components | 0.0011s | **1.2e-06s** |
219 | Standard view, 1M entities, ten components<br/>Half of the entities have all the components | 0.0010s | **1.2e-06s** |
220 | Standard view, 1M entities, ten components<br/>One of the entities has all the components | 0.0008s | **1.2e-06s** |
221 | Persistent view, 1M entities, ten components | 0.0011s | **3.0e-07s** |
222 | Raw view, 1M entities | - | **2.2e-07s** |
223 | Sort 150k entities, one component<br/>Arrays are in reverse order | - | **0.0036s** |
224 | Sort 150k entities, enforce permutation<br/>Arrays are in reverse order | - | **0.0005s** |
225 | Sort 150k entities, one component<br/>Arrays are almost sorted, std::sort | - | **0.0035s** |
226 | Sort 150k entities, one component<br/>Arrays are almost sorted, insertion sort | - | **0.0007s** |
227 
228 Note: The default version of `EntityX` (`master` branch) wasn't added to the
229 comparison because it's already much slower than its compile-time counterpart.
230 
231 Pretty interesting, aren't them? In fact, these benchmarks are the same used by
232 `EntityX` to show _how fast it is_. To be honest, they aren't so good and these
233 results shouldn't be taken much seriously (they are completely unrealistic
234 indeed).<br/>
235 The proposed entity-component system is incredibly fast to iterate entities,
236 this is a fact. The compiler can make a lot of optimizations because of how
237 `EnTT` works, even more when components aren't used at all. This is exactly the
238 case for these benchmarks. On the other hand and if we consider real world
239 cases, `EnTT` is in the middle between a bit and much faster than the other
240 solutions around when users also access the components and not just the
241 entities, although it is not as fast as reported by these benchmarks.<br/>
242 This is why they are completely wrong and cannot be used to evaluate any of the
243 entity-component systems.
244 
245 If you decide to use `EnTT`, choose it because of its API, features and
246 performance, not because there is a benchmark somewhere that makes it seem the
247 fastest.
248 
249 Probably I'll try to get out of `EnTT` more features and even better performance
250 in the future, mainly for fun.<br/>
251 If you want to contribute and/or have any suggestion, feel free to make a PR or
252 open an issue to discuss your idea.
253 
254 # Build Instructions
255 
256 ## Requirements
257 
258 To be able to use `EnTT`, users must provide a full-featured compiler that
259 supports at least C++14.<br/>
260 The requirements below are mandatory to compile the tests and to extract the
261 documentation:
262 
263 * CMake version 3.2 or later.
264 * Doxygen version 1.8 or later.
265 
266 ## Library
267 
268 `EnTT` is a header-only library. This means that including the `entt.hpp`
269 header is enough to include the whole framework and use it. For those who are
270 interested only in the entity-component system, consider to include the sole
271 `entity/registry.hpp` header instead.<br/>
272 It's a matter of adding the following line to the top of a file:
273 
274 ```cpp
275 #include <entt/entt.hpp>
276 ```
277 
278 Use the line below to include only the entity-component system instead:
279 
280 ```cpp
281 #include <entt/entity/registry.hpp>
282 ```
283 
284 Then pass the proper `-I` argument to the compiler to add the `src` directory to
285 the include paths.
286 
287 ## Documentation
288 
289 The documentation is based on [doxygen](http://www.stack.nl/~dimitri/doxygen/).
290 To build it:
291 
292  $ cd build
293  $ cmake ..
294  $ make docs
295 
296 The API reference will be created in HTML format within the directory
297 `build/docs/html`. To navigate it with your favorite browser:
298 
299  $ cd build
300  $ your_favorite_browser docs/html/index.html
301 
302 The API reference is also available [online](https://skypjack.github.io/entt/)
303 for the latest version.
304 
305 ## Tests
306 
307 To compile and run the tests, `EnTT` requires *googletest*.<br/>
308 `cmake` will download and compile the library before to compile anything else.
309 
310 To build the most basic set of tests:
311 
312 * `$ cd build`
313 * `$ cmake ..`
314 * `$ make`
315 * `$ make test`
316 
317 Note that benchmarks are not part of this set.
318 
319 # Crash Course: entity-component system
320 
321 ## Design choices
322 
323 ### A bitset-free entity-component system
324 
325 `EnTT` is a _bitset-free_ entity-component system that doesn't require users to
326 specify the component set at compile-time.<br/>
327 This is why users can instantiate the core class simply like:
328 
329 ```cpp
330 entt::DefaultRegistry registry;
331 ```
332 
333 In place of its more annoying and error-prone counterpart:
334 
335 ```cpp
336 entt::DefaultRegistry<Comp0, Comp1, ..., CompN> registry;
337 ```
338 
339 ### Pay per use
340 
341 `EnTT` is entirely designed around the principle that users have to pay only for
342 what they want.
343 
344 When it comes to using an entity-component system, the tradeoff is usually
345 between performance and memory usage. The faster it is, the more memory it uses.
346 However, slightly worse performance along non-critical paths are the right price
347 to pay to reduce memory usage and I've always wondered why this kind of tools do
348 not leave me the choice.<br/>
349 `EnTT` follows a completely different approach. It squeezes the best from the
350 basic data structures and gives users the possibility to pay more for higher
351 performance where needed.<br/>
352 The disadvantage of this approach is that users need to know the systems they
353 are working on and the tools they are using. Otherwise, the risk to ruin the
354 performance along critical paths is high.
355 
356 So far, this choice has proven to be a good one and I really hope it can be for
357 many others besides me.
358 
359 ## Vademecum
360 
361 The `Registry` to store, the views to iterate. That's all.
362 
363 An entity (the _E_ of an _ECS_) is an opaque identifier that users should just
364 use as-is and store around if needed. Do not try to inspect an entity
365 identifier, its format can change in future and a registry offers all the
366 functionalities to query them out-of-the-box. The underlying type of an entity
367 (either `std::uint16_t`, `std::uint32_t` or `std::uint64_t`) can be specified
368 when defining a registry (actually the `DefaultRegistry` is nothing more than a
369 `Registry` where the type of the entities is `std::uint32_t`).<br/>
370 Components (the _C_ of an _ECS_) should be plain old data structures or more
371 complex and movable data structures with a proper constructor. Actually, the
372 sole requirement of a component type is that it must be both move constructible
373 and move assignable. They are list initialized by using the parameters provided
374 to construct the component itself. No need to register components or their types
375 neither with the registry nor with the entity-component system at all.<br/>
376 Systems (the _S_ of an _ECS_) are just plain functions, functors, lambdas or
377 whatever users want. They can accept a `Registry` or a view of any type and use
378 them the way they prefer. No need to register systems or their types neither
379 with the registry nor with the entity-component system at all.
380 
381 The following sections will explain in short how to use the entity-component
382 system, the core part of the whole framework.<br/>
383 In fact, the framework is composed of many other classes in addition to those
384 describe below. For more details, please refer to the inline documentation.
385 
386 ## The Registry, the Entity and the Component
387 
388 A registry can store and manage entities, as well as create views to iterate the
389 underlying data structures.<br/>
390 `Registry` is a class template that lets users decide what's the preferred type
391 to represent an entity. Because `std::uint32_t` is large enough for almost all
392 the cases, there exists also an alias named `DefaultRegistry` for
393 `Registry<std::uint32_t>`.
394 
395 Entities are represented by _entity identifiers_. An entity identifier is an
396 opaque type that users should not inspect or modify in any way. It carries
397 information about the entity itself and its version.
398 
399 A registry can be used both to construct and destroy entities, as well as to
400 clone already existing entities:
401 
402 ```cpp
403 // constructs a naked entity with no components and returns its identifier
404 auto entity = registry.create();
405 
406 // clones an entity and assigns all its components by copy to the newly created one
407 auto other = registry.clone(entity);
408 
409 // destroys an entity and all its components
410 registry.destroy(entity);
411 ```
412 
413 Be aware that cloning an entity can lead to unexpected results under certain
414 conditions. Please refer to the inline documentation for more details.<br/>
415 Once an entity is deleted, the registry can freely reuse it internally with a
416 slightly different identifier. In particular, the version of an entity is
417 increased each and every time it's destroyed.<br/>
418 In case entity identifiers are stored around, the registry offers all the
419 functionalities required to test them and get out of the them all the
420 information they carry:
421 
422 ```cpp
423 // returns true if the entity is still valid, false otherwise
424 bool b = registry.valid(entity);
425 
426 // gets the version contained in the entity identifier
427 auto version = registry.version(entity);
428 
429 // gets the actual version for the given entity
430 auto curr = registry.current(entity);
431 ```
432 
433 Finally, there is also a sort of _null identifier_ made available to users. It's
434 treated as if it were a _null pointer_ that doesn't identify any entity. A
435 registry will reject this identifier in all cases because it isn't considered
436 valid.<br/>
437 The rules that define a _null identifier_ are a bit tricky to explain. However,
438 being `Entity` the type of the entities (for example, `std::uint32_t`), users
439 can easily construct a _null identifier_ by flipping all the bits of the _zero_:
440 
441 ```cpp
442 using Entity = std::uint32_t;
443 const auto null = ~Entity{};
444 ```
445 
446 Components can be assigned to or removed from entities at any time with a few
447 calls to member functions of the registry. As for the entities, the registry
448 offers also a set of functionalities users can use to work with the components.
449 
450 The `assign` member function template creates, initializes and assigns to an
451 entity the given component. It accepts a variable number of arguments to
452 construct the component itself if present:
453 
454 ```cpp
455 registry.assign<Position>(entity, 0., 0.);
456 
457 // ...
458 
459 Velocity &velocity = registry.assign<Velocity>(entity);
460 velocity.dx = 0.;
461 velocity.dy = 0.;
462 ```
463 
464 If an entity already has the given component, the `replace` member function
465 template can be used to replace it:
466 
467 ```cpp
468 registry.replace<Position>(entity, 0., 0.);
469 
470 // ...
471 
472 Velocity &velocity = registry.replace<Velocity>(entity);
473 velocity.dx = 0.;
474 velocity.dy = 0.;
475 ```
476 
477 In case users want to assign a component to an entity, but it's unknown whether
478 the entity already has it or not, `accommodate` does the work in a single call
479 (there is a performance penalty to pay for this mainly due to the fact that it
480 has to check if the entity already has the given component or not):
481 
482 ```cpp
483 registry.accommodate<Position>(entity, 0., 0.);
484 
485 // ...
486 
487 Velocity &velocity = registry.accommodate<Velocity>(entity);
488 velocity.dx = 0.;
489 velocity.dy = 0.;
490 ```
491 
492 Note that `accommodate` is a slightly faster alternative for the following
493 `if/else` statement and nothing more:
494 
495 ```cpp
496 if(registry.has<Comp>(entity)) {
497  registry.replace<Comp>(entity, arg1, argN);
498 } else {
499  registry.assign<Comp>(entity, arg1, argN);
500 }
501 ```
502 
503 As already shown, if in doubt about whether or not an entity has one or more
504 components, the `has` member function template may be useful:
505 
506 ```cpp
507 bool b = registry.has<Position, Velocity>(entity);
508 ```
509 
510 On the other side, if the goal is to delete a single component, the `remove`
511 member function template is the way to go when it's certain that the entity owns
512 a copy of the component:
513 
514 ```cpp
515 registry.remove<Position>(entity);
516 ```
517 
518 Otherwise consider to use the `reset` member function. It behaves similarly to
519 `remove` but with a strictly defined behavior (and a performance penalty is the
520 price to pay for this). In particular it removes the component if and only if it
521 exists, otherwise it returns safely to the caller:
522 
523 ```cpp
524 registry.reset<Position>(entity);
525 ```
526 
527 There exist also two other _versions_ of the `reset` member function:
528 
529 * If no entity is passed to it, `reset` will remove the given component from
530  each entity that has it:
531 
532  ```cpp
533  registry.reset<Position>();
534  ```
535 
536 * If neither the entity nor the component are specified, all the entities still
537  in use and their components are destroyed:
538 
539  ```cpp
540  registry.reset();
541  ```
542 
543 Finally, references to components can be retrieved simply by doing this:
544 
545 ```cpp
546 const auto &cregistry = registry;
547 
548 // const and non-const reference
549 const Position &position = cregistry.get<Position>(entity);
550 Position &position = registry.get<Position>(entity);
551 
552 // const and non-const references
553 std::tuple<const Position &, const Velocity &> tup = cregistry.get<Position, Velocity>(entity);
554 std::tuple<Position &, Velocity &> tup = registry.get<Position, Velocity>(entity);
555 ```
556 
557 The `get` member function template gives direct access to the component of an
558 entity stored in the underlying data structures of the registry.
559 
560 ### Single instance components
561 
562 In those cases where all what is needed is a single instance component, tags are
563 the right tool to achieve the purpose.<br/>
564 Tags undergo the same requirements of components. They can be either plain old
565 data structures or more complex and movable data structures with a proper
566 constructor.<br/>
567 Actually, the same type can be used both as a tag and as a component and the
568 registry will not complain about it. It is up to users to properly manage their
569 own types. In some cases, the tag `tag_t` must also be used in order to
570 disambiguate overloads of member functions.
571 
572 Attaching tags to entities and removing them is trivial:
573 
574 ```cpp
575 auto player = registry.create();
576 auto camera = registry.create();
577 
578 // attaches a default-initialized tag to an entity
579 registry.assign<PlayingCharacter>(entt::tag_t{}, player);
580 
581 // attaches a tag to an entity and initializes it
582 registry.assign<Camera>(entt::tag_t{}, camera, player);
583 
584 // removes tags from their owners
585 registry.remove<PlayingCharacter>();
586 registry.remove<Camera>();
587 ```
588 
589 In case a tag already has an owner, its content can be updated by means of the
590 `replace` member function template and the ownership of the tag can be
591 transferred to another entity using the `move` member function template:
592 
593 ```
594 // replaces the content of the given tag
595 Point &point = registry.replace<Point>(entt::tag_t{}, 1.f, 1.f);
596 
597 // transfers the ownership of the tag to another entity
598 entity_type prev = registry.move<Point>(next);
599 ```
600 
601 If in doubt about whether or not a tag already has an owner, the `has` member
602 function template may be useful:
603 
604 ```cpp
605 bool b = registry.has<PlayingCharacter>();
606 ```
607 
608 References to tags can be retrieved simply by doing this:
609 
610 ```cpp
611 const auto &cregistry = registry;
612 
613 // either a non-const reference ...
614 PlayingCharacter &player = registry.get<PlayingCharacter>();
615 
616 // ... or a const one
617 const Camera &camera = cregistry.get<Camera>();
618 ```
619 
620 The `get` member function template gives direct access to the tag as stored in
621 the underlying data structures of the registry.
622 
623 As shown above, in almost all the cases the entity identifier isn't required.
624 Since a single instance component can have only one associated entity, it
625 doesn't make much sense to mention it explicitly.<br/>
626 To find out who the owner is, just do the following:
627 
628 ```cpp
629 auto player = registry.attachee<PlayingCharacter>();
630 ```
631 
632 Note that iterating tags isn't possible for obvious reasons. Tags give direct
633 access to single entities and nothing more.
634 
635 ### Observe changes
636 
637 Because of how the registry works internally, it stores a couple of signal
638 handlers for each pool in order to notify some of its data structures on the
639 construction and destruction of components.<br/>
640 These signal handlers are also exposed and made available to users. This is the
641 basic brick to build fancy things like dependencies and reactive systems.
642 
643 To get a sink to be used to connect and disconnect listeners so as to be
644 notified on the creation of a component, use the `construction` member function:
645 
646 ```cpp
647 // connects a free function
648 registry.construction<Position>().connect<&MyFreeFunction>();
649 
650 // connects a member function
651 registry.construction<Position>().connect<MyClass, &MyClass::member>(&instance);
652 
653 // disconnects a free function
654 registry.construction<Position>().disconnect<&MyFreeFunction>();
655 
656 // disconnects a member function
657 registry.construction<Position>().disconnect<MyClass, &MyClass::member>(&instance);
658 ```
659 
660 To be notified when components are destroyed, use the `destruction` member
661 function instead.
662 
663 The function type of a listener is the same in both cases:
664 
665 ```cpp
666 void(Registry<Entity> &, Entity);
667 ```
668 
669 In other terms, a listener is provided with the registry that triggered the
670 notification and the entity affected by the change. Note also that:
671 
672 * Listeners are invoked **after** components have been assigned to entities.
673 * Listeners are invoked **before** components have been removed from entities.
674 * The order of invocation of the listeners isn't guaranteed in any case.
675 
676 There are also some limitations on what a listener can and cannot do. In
677 particular:
678 
679 * Connecting and disconnecting other functions from within the body of a
680  listener should be avoided. It can lead to undefined behavior in some cases.
681 * Assigning and removing components and tags from within the body of a listener
682  that observes the destruction of instances of a given type should be avoided.
683  It can lead to undefined behavior in some cases. This type of listeners is
684  intended to provide users with an easy way to perform cleanup and nothing
685  more.
686 
687 To a certain extent, these limitations do not apply. However, it is risky to try
688 to force them and users should respect the limitations unless they know exactly
689 what they are doing. Subtle bugs are the price to pay in case of errors
690 otherwise.
691 
692 In general, events and therefore listeners must not be used as replacements for
693 systems. They should not contain much logic and interactions with a registry
694 should be kept to a minimum, if possible. Note also that the greater the number
695 of listeners, the greater the performance hit when components are created or
696 destroyed.
697 
698 #### Who let the tags out?
699 
700 As an extension, signals are also provided with tags. Although they are not
701 strictly required internally, it makes sense that a user expects signal support
702 even when it comes to tags actually.<br/>
703 Signals for tags undergo exactly the same requirements of those introduced for
704 components. Also the function type for a listener is the same and it's invoked
705 with the same guarantees discussed above.
706 
707 To get the sinks for a tag just use tag `tag_t` to disambiguate overloads of
708 member functions as in the following example:
709 
710 ```cpp
711 registry.construction<MyTag>(entt::tag_t{}).connect<&MyFreeFunction>();
712 registry.destruction<MyTag>(entt::tag_t{}).connect<MyClass, &MyClass::member>(&instance);
713 ```
714 
715 Listeners for tags and components are managed separately and do not influence
716 each other in any case. Therefore, note that the greater the number of listeners
717 for a type, the greater the performance hit when a tag of the given type is
718 created or destroyed.
719 
720 ### Runtime components
721 
722 Defining components at runtime is useful to support plugins and mods in general.
723 However, it seems impossible with a tool designed around a bunch of templates.
724 Indeed it's not that difficult.<br/>
725 Of course, some features cannot be easily exported into a runtime
726 environment. As an example, sorting a group of components defined at runtime
727 isn't for free if compared to most of the other operations. However, the basic
728 functionalities of an entity-component system such as `EnTT` fit the problem
729 perfectly and can also be used to manage runtime components if required.<br/>
730 All that is necessary to do it is to know the identifiers of the components. An
731 identifier is nothing more than a number or similar that can be used at runtime
732 to work with the type system.
733 
734 In `EnTT`, identifiers are easily accessible:
735 
736 ```cpp
737 entt::DefaultRegistry registry;
738 
739 // standard component identifier
740 auto ctype = registry.component<Position>();
741 
742 // single instance component identifier
743 auto ttype = registry.tag<PlayingCharacter>();
744 ```
745 
746 Once the identifiers are made available, almost everything becomes pretty
747 simple.
748 
749 #### A journey through a plugin
750 
751 `EnTT` comes with an example (actually a test) that shows how to integrate
752 compile-time and runtime components in a stack based JavaScript environment. It
753 uses [`Duktape`](https://github.com/svaarala/duktape) under the hood, mainly
754 because I wanted to learn how it works at the time I was writing the code.
755 
756 The code is not production-ready and overall performance can be highly improved.
757 However, I sacrificed optimizations in favor of a more readable piece of code. I
758 hope I succeeded.<br/>
759 Note also that this isn't neither the only nor (probably) the best way to do it.
760 In fact, the right way depends on the scripting language and the problem one is
761 facing in general.<br/>
762 That being said, feel free to use it at your own risk.
763 
764 The basic idea is that of creating a compile-time component aimed to map all the
765 runtime components assigned to an entity.<br/>
766 Identifiers come in use to address the right function from a map when invoked
767 from the runtime environment and to filter entities when iterating.<br/>
768 With a bit of gymnastic, one can narrow views and improve the performance to
769 some extent but it was not the goal of the example.
770 
771 ### Sorting: is it possible?
772 
773 It goes without saying that sorting entities and components is possible with
774 `EnTT`.<br/>
775 In fact, there are two functions that respond to slightly different needs:
776 
777 * Components can be sorted directly:
778 
779  ```cpp
780  registry.sort<Renderable>([](const auto &lhs, const auto &rhs) {
781  return lhs.z < rhs.z;
782 
783  });
784  ```
785 
786  There exists also the possibility to use a custom sort function object, as
787  long as it adheres to the requirements described in the inline
788  documentation.<br/>
789  This is possible mainly because users can get much more with a custom sort
790  function object if the pattern of usage is known. As an example, in case of an
791  almost sorted pool, quick sort could be much, much slower than insertion sort.
792 
793 * Components can be sorted according to the order imposed by another component:
794 
795  ```cpp
796  registry.sort<Movement, Physics>();
797  ```
798 
799  In this case, instances of `Movement` are arranged in memory so that cache
800  misses are minimized when the two components are iterated together.
801 
802 ### Snapshot: complete vs continuous
803 
804 The `Registry` class offers basic support to serialization.<br/>
805 It doesn't convert components and tags to bytes directly, there wasn't the need
806 of another tool for serialization out there. Instead, it accepts an opaque
807 object with a suitable interface (namely an _archive_) to serialize its internal
808 data structures and restore them later. The way types and instances are
809 converted to a bunch of bytes is completely in charge to the archive and thus to
810 final users.
811 
812 The goal of the serialization part is to allow users to make both a dump of the
813 entire registry or a narrower snapshot, that is to select only the components
814 and the tags in which they are interested.<br/>
815 Intuitively, the use cases are different. As an example, the first approach is
816 suitable for local save/restore functionalities while the latter is suitable for
817 creating client-server applications and for transferring somehow parts of the
818 representation side to side.
819 
820 To take a snapshot of the registry, use the `snapshot` member function. It
821 returns a temporary object properly initialized to _save_ the whole registry or
822 parts of it.
823 
824 Example of use:
825 
826 ```cpp
827 OutputArchive output;
828 
829 registry.snapshot()
830  .entities(output)
831  .destroyed(output)
832  .component<AComponent, AnotherComponent>(output)
833  .tag<MyTag>(output);
834 ```
835 
836 It isn't necessary to invoke all these functions each and every time. What
837 functions to use in which case mostly depends on the goal and there is not a
838 golden rule to do that.
839 
840 The `entities` member function asks the registry to serialize all the entities
841 that are still in use along with their versions. On the other side, the
842 `destroyed` member function tells to the registry to serialize the entities that
843 have been destroyed and are no longer in use.<br/>
844 These two functions can be used to save and restore the whole set of entities
845 with the versions they had during serialization.
846 
847 The `component` member function is a function template the aim of which is to
848 store aside components. The presence of a template parameter list is a
849 consequence of a couple of design choices from the past and in the present:
850 
851 * First of all, there is no reason to force a user to serialize all the
852  components at once and most of the times it isn't desiderable. As an example,
853  in case the stuff for the HUD in a game is put into the registry for some
854  reasons, its components can be freely discarded during a serialization step
855  because probably the software already knows how to reconstruct the HUD
856  correctly from scratch.
857 
858 * Furthermore, the registry makes heavy use of _type-erasure_ techniques
859  internally and doesn't know at any time what types of components it contains.
860  Therefore being explicit at the call point is mandatory.
861 
862 There exists also another version of the `component` member function that
863 accepts a range of entities to serialize. This version is a bit slower than the
864 other one, mainly because it iterates the range of entities more than once for
865 internal purposes. However, it can be used to filter out those entities that
866 shouldn't be serialized for some reasons.<br/>
867 As an example:
868 
869 ```cpp
870 const auto view = registry.view<Serialize>();
871 OutputArchive output;
872 
873 registry.snapshot()
874  .component<AComponent, AnotherComponent>(output, view.cbegin(), view.cend());
875 ```
876 
877 The `tag` member function is similar to the previous one, apart from the fact
878 that it works with tags and not with components.<br/>
879 Note also that both `component` and `tag` store items along with entities. It
880 means that they work properly without a call to the `entities` member function.
881 
882 Once a snapshot is created, there exist mainly two _ways_ to load it: as a whole
883 and in a kind of _continuous mode_.<br/>
884 The following sections describe both loaders and archives in details.
885 
886 #### Snapshot loader
887 
888 A snapshot loader requires that the destination registry be empty and loads all
889 the data at once while keeping intact the identifiers that the entities
890 originally had.<br/>
891 To do that, the registry offers a member function named `restore` that returns a
892 temporary object properly initialized to _restore_ a snapshot.
893 
894 Example of use:
895 
896 ```cpp
897 InputArchive input;
898 
899 registry.restore()
900  .entities(input)
901  .destroyed(input)
902  .component<AComponent, AnotherComponent>(input)
903  .tag<MyTag>(input)
904  .orphans();
905 ```
906 
907 It isn't necessary to invoke all these functions each and every time. What
908 functions to use in which case mostly depends on the goal and there is not a
909 golden rule to do that. For obvious reasons, what is important is that the data
910 are restored in exactly the same order in which they were serialized.
911 
912 The `entities` and `destroyed` member functions restore the sets of entities and
913 the versions that the entities originally had at the source.
914 
915 The `component` member function restores all and only the components specified
916 and assigns them to the right entities. Note that the template parameter list
917 must be exactly the same used during the serialization. The same applies to the
918 `tag` member function.
919 
920 The `orphans` member function literally destroys those entities that have
921 neither components nor tags. It's usually useless if the snapshot is a full dump
922 of the source. However, in case all the entities are serialized but only few
923 components and tags are saved, it could happen that some of the entities have
924 neither components nor tags once restored. The best users can do to deal with
925 them is to destroy those entities and thus update their versions.
926 
927 #### Continuous loader
928 
929 A continuous loader is designed to load data from a source registry to a
930 (possibly) non-empty destination. The loader can accommodate in a registry more
931 than one snapshot in a sort of _continuous loading_ that updates the
932 destination one step at a time.<br/>
933 Identifiers that entities originally had are not transferred to the target.
934 Instead, the loader maps remote identifiers to local ones while restoring a
935 snapshot. Because of that, this kind of loader offers a way to update
936 automatically identifiers that are part of components or tags (as an example, as
937 data members or gathered in a container).<br/>
938 Another difference with the snapshot loader is that the continuous loader does
939 not need to work with the private data structures of a registry. Furthermore, it
940 has an internal state that must persist over time. Therefore, there is no reason
941 to create it by means of a registry, or to limit its lifetime to that of a
942 temporary object.
943 
944 Example of use:
945 
946 ```cpp
947 entt::ContinuousLoader<entity_type> loader{registry};
948 InputArchive input;
949 
950 loader.entities(input)
951  .destroyed(input)
952  .component<AComponent, AnotherComponent, DirtyComponent>(input, &DirtyComponent::parent, &DirtyComponent::child)
953  .tag<MyTag, DirtyTag>(input, &DirtyTag::container)
954  .orphans()
955  .shrink();
956 ```
957 
958 It isn't necessary to invoke all these functions each and every time. What
959 functions to use in which case mostly depends on the goal and there is not a
960 golden rule to do that. For obvious reasons, what is important is that the data
961 are restored in exactly the same order in which they were serialized.
962 
963 The `entities` and `destroyed` member functions restore groups of entities and
964 map each entity to a local counterpart when required. In other terms, for each
965 remote entity identifier not yet registered by the loader, the latter creates a
966 local identifier so that it can keep the local entity in sync with the remote
967 one.
968 
969 The `component` and `tag` member functions restore all and only the components
970 and the tags specified and assign them to the right entities.<br/>
971 In case the component or the tag contains entities itself (either as data
972 members of type `entity_type` or as containers of entities), the loader can
973 update them automatically. To do that, it's enough to specify the data members
974 to update as shown in the example.
975 
976 The `orphans` member function literally destroys those entities that have
977 neither components nor tags after a restore. It has exactly the same purpose
978 described in the previous section and works the same way.
979 
980 Finally, `shrink` helps to purge local entities that no longer have a remote
981 conterpart. Users should invoke this member function after restoring each
982 snapshot, unless they know exactly what they are doing.
983 
984 #### Archives
985 
986 Archives must publicly expose a predefined set of member functions. The API is
987 straightforward and consists only of a group of function call operators that
988 are invoked by the snapshot class and the loaders.
989 
990 In particular:
991 
992 * An output archive, the one used when creating a snapshot, must expose a
993  function call operator with the following signature to store entities:
994 
995  ```cpp
996  void operator()(Entity);
997  ```
998 
999  Where `Entity` is the type of the entities used by the registry. Note that all
1000  the member functions of the snapshot class make also an initial call to this
1001  endpoint to save the _size_ of the set they are going to store.<br/>
1002  In addition, an archive must accept a pair of entity and either component or
1003  tag for each type to be serialized. Therefore, given a type `T`, the archive
1004  must contain a function call operator with the following signature:
1005 
1006  ```cpp
1007  void operator()(Entity, const T &);
1008  ```
1009 
1010  The output archive can freely decide how to serialize the data. The register
1011  is not affected at all by the decision.
1012 
1013 * An input archive, the one used when restoring a snapshot, must expose a
1014  function call operator with the following signature to load entities:
1015 
1016  ```cpp
1017  void operator()(Entity &);
1018  ```
1019 
1020  Where `Entity` is the type of the entities used by the registry. Each time the
1021  function is invoked, the archive must read the next element from the
1022  underlying storage and copy it in the given variable. Note that all the member
1023  functions of a loader class make also an initial call to this endpoint to read
1024  the _size_ of the set they are going to load.<br/>
1025  In addition, the archive must accept a pair of entity and either component or
1026  tag for each type to be restored. Therefore, given a type `T`, the archive
1027  must contain a function call operator with the following signature:
1028 
1029  ```cpp
1030  void operator()(Entity &, T &);
1031  ```
1032 
1033  Every time such an operator is invoked, the archive must read the next
1034  elements from the underlying storage and copy them in the given variables.
1035 
1036 #### One example to rule them all
1037 
1038 `EnTT` comes with some examples (actually some tests) that show how to integrate
1039 a well known library for serialization as an archive. It uses
1040 [`Cereal C++`](https://uscilab.github.io/cereal/) under the hood, mainly
1041 because I wanted to learn how it works at the time I was writing the code.
1042 
1043 The code is not production-ready and it isn't neither the only nor (probably)
1044 the best way to do it. However, feel free to use it at your own risk.
1045 
1046 The basic idea is to store everything in a group of queues in memory, then bring
1047 everything back to the registry with different loaders.
1048 
1049 ### Prototype
1050 
1051 A prototype defines a type of an application in terms of its parts. They can be
1052 used to assign components to entities of a registry at once.<br/>
1053 Roughly speaking, in most cases prototypes can be considered just as templates
1054 to use to initialize entities according to _concepts_. In fact, users can create
1055 how many prototypes they want, each one initialized differently from the others.
1056 
1057 The following is an example of use of a prototype:
1058 
1059 ```cpp
1060 entt::DefaultPrototype prototype;
1061 
1062 prototype.set<Position>(100.f, 100.f);
1063 prototype.set<Velocity>(0.f, 0.f);
1064 
1065 // ...
1066 
1067 entt::DefaultRegistry registry;
1068 
1069 const auto entity = prototype(registry);
1070 ```
1071 
1072 To assign and remove components from a prototype, it offers two dedicated member
1073 functions named `set` and `unset`. The `has` member function can be used to know
1074 if a given prototype contains one or more components and the `get` member
1075 function can be used to retrieve the components.
1076 
1077 Creating an entity from a prototype is straightforward:
1078 
1079 * To create a new entity from scratch and assign it a prototype, this is the way
1080  to go:
1081  ```cpp
1082  const auto entity = prototype(registry);
1083  ```
1084  It is equivalent to the following invokation:
1085  ```cpp
1086  const auto entity = prototype.create(registry);
1087  ```
1088 
1089 * In case we want to initialize an already existing entity, we can provide the
1090  `operator()` directly with the entity identifier:
1091  ```cpp
1092  prototype(registry, entity);
1093  ```
1094  It is equivalent to the following invokation:
1095  ```cpp
1096  prototype.assign(registry, entity);
1097  ```
1098  Note that existing components aren't overwritten in this case. Only those
1099  components that the entity doesn't own yet are copied over. All the other
1100  components remain unchanged.
1101 
1102 * Finally, to assign or replace all the components for an entity, thus
1103  overwriting existing ones:
1104  ```cpp
1105  prototype.accommodate(registry, entity);
1106  ```
1107 
1108 Prototypes are a very useful tool that can save a lot of typing sometimes.
1109 Furthermore, the codebase may be easier to maintain, since updating a prototype
1110 is much less error prone than jumping around in the codebase to update all the
1111 snippets copied and pasted around to initialize entities and components.
1112 
1113 ### Helpers
1114 
1115 The so called _helpers_ are small classes and functions mainly designed to offer
1116 built-in support for the most basic functionalities.<br/>
1117 The list of helpers will grow longer as time passes and new ideas come out.
1118 
1119 #### Dependency function
1120 
1121 A _dependency function_ is a predefined listener, actually a function template
1122 to use to automatically assign components to an entity when a type has a
1123 dependency on some other types.<br/>
1124 The following adds components `AType` and `AnotherType` whenever `MyType` is
1125 assigned to an entity:
1126 
1127 ```cpp
1128 entt::dependency<AType, AnotherType>(registry.construction<MyType>());
1129 ```
1130 
1131 A component is assigned to an entity and thus default initialized only in case
1132 the entity itself hasn't it yet. It means that already existent components won't
1133 be overriden.<br/>
1134 A dependency can easily be broken by means of the same function template:
1135 
1136 ```cpp
1137 entt::dependency<AType, AnotherType>(entt::break_t{}, registry.construction<MyType>());
1138 ```
1139 
1140 ## View: to persist or not to persist?
1141 
1142 First of all, it is worth answering an obvious question: why views?<br/>
1143 Roughly speaking, they are a good tool to enforce single responsibility. A
1144 system that has access to a registry can create and destroy entities, as well as
1145 assign and remove components. On the other side, a system that has access to a
1146 view can only iterate entities and their components, then read or update the
1147 data members of the latter.<br/>
1148 It is a subtle difference that can help designing a better software sometimes.
1149 
1150 There are mainly three kinds of views: standard (also known as `View`),
1151 persistent (also known as `PersistentView`) and raw (also known as
1152 `RawView`).<br/>
1153 All of them have pros and cons to take in consideration. In particular:
1154 
1155 * Standard views:
1156 
1157  Pros:
1158 
1159  * They work out-of-the-box and don't require any dedicated data structure.
1160  * Creating and destroying them isn't expensive at all because they don't have
1161  any type of initialization.
1162  * They are the best tool for iterating entities for a single component.
1163  * They are the best tool for iterating entities for multiple components when
1164  one of the components is assigned to a significantly low number of entities.
1165  * They don't affect any other operations of the registry.
1166 
1167  Cons:
1168 
1169  * Their performance tend to degenerate when the number of components to
1170  iterate grows up and the most of the entities have all of them.
1171 
1172 * Persistent views:
1173 
1174  Pros:
1175 
1176  * Once prepared, creating and destroying them isn't expensive at all because
1177  they don't have any type of initialization.
1178  * They are the best tool for iterating entities for multiple components when
1179  most entities have them all.
1180 
1181  Cons:
1182 
1183  * They have dedicated data structures and thus affect the memory usage to a
1184  minimal extent.
1185  * If not previously prepared, the first time they are used they go through an
1186  initialization step that could take a while.
1187  * They affect to a minimum the creation and destruction of entities and
1188  components. In other terms: the more persistent views there will be, the
1189  less performing will be creating and destroying entities and components.
1190 
1191 * Raw views:
1192 
1193  Pros:
1194 
1195  * They work out-of-the-box and don't require any dedicated data structure.
1196  * Creating and destroying them isn't expensive at all because they don't have
1197  any type of initialization.
1198  * They are the best tool for iterating components when it is not necessary to
1199  know which entities they belong to.
1200  * They don't affect any other operations of the registry.
1201 
1202  Cons:
1203 
1204  * They can be used to iterate only one type of component at a time.
1205  * They don't return the entity to which a component belongs to the caller.
1206 
1207 To sum up and as a rule of thumb:
1208 
1209 * Use a raw view to iterate components only (no entities) for a given type.
1210 * Use a standard view to iterate entities and components for a single type.
1211 * Use a standard view to iterate entities and components for multiple types when
1212  the number of types is low. Standard views are really optimized and persistent
1213  views won't add much in this case.
1214 * Use a standard view to iterate entities and components for multiple types when
1215  a significantly low number of entities have one of the components.
1216 * Use a standard view in all those cases where a persistent view would give a
1217  boost to performance but the iteration isn't performed frequently.
1218 * Prepare and use a persistent view when you want to iterate only entities for
1219  multiple components.
1220 * Prepare and use a persistent view when you want to iterate entities for
1221  multiple components and each component is assigned to a great number of
1222  entities but the intersection between the sets of entities is small.
1223 * Prepare and use a persistent view in all the cases where a standard view
1224  wouldn't fit well otherwise.
1225 
1226 To easily iterate entities and components, all the views offer the common
1227 `begin` and `end` member functions that allow users to use a view in a typical
1228 range-for loop. Almost all the views offer also a *more functional* `each`
1229 member function that accepts a callback for convenience.<br/>
1230 Continue reading for more details or refer to the inline documentation.
1231 
1232 ### Standard View
1233 
1234 A standard view behaves differently if it's constructed for a single component
1235 or if it has been requested to iterate multiple components. Even the API is
1236 different in the two cases.<br/>
1237 All that they share is the way they are created by means of a registry:
1238 
1239 ```cpp
1240 // single component standard view
1241 auto single = registry.view<Position>();
1242 
1243 // multi component standard view
1244 auto multi = registry.view<Position, Velocity>();
1245 ```
1246 
1247 For all that remains, it's worth discussing them separately.<br/>
1248 
1249 #### Single component standard view
1250 
1251 Single component standard views are specialized in order to give a boost in
1252 terms of performance in all the situation. This kind of views can access the
1253 underlying data structures directly and avoid superfluous checks.<br/>
1254 They offer a bunch of functionalities to get the number of entities they are
1255 going to return and a raw access to the entity list as well as to the component
1256 list. It's also possible to ask a view if it contains a given entity.<br/>
1257 Refer to the inline documentation for all the details.
1258 
1259 There is no need to store views around for they are extremely cheap to
1260 construct, even though they can be copied without problems and reused freely. In
1261 fact, they return newly created and correctly initialized iterators whenever
1262 `begin` or `end` are invoked.<br/>
1263 To iterate a single component standard view, either use it in range-for loop:
1264 
1265 ```cpp
1266 auto view = registry.view<Renderable>();
1267 
1268 for(auto entity: view) {
1269  Renderable &renderable = view.get(entity);
1270 
1271  // ...
1272 }
1273 ```
1274 
1275 Or rely on the `each` member function to iterate entities and get all their
1276 components at once:
1277 
1278 ```cpp
1279 registry.view<Renderable>().each([](auto entity, auto &renderable) {
1280  // ...
1281 });
1282 ```
1283 
1284 Performance are more or less the same. The best approach depends mainly on
1285 whether all the components have to be accessed or not.
1286 
1287 **Note**: prefer the `get` member function of a view instead of the `get` member
1288 function template of a registry during iterations, if possible. However, keep in
1289 mind that it works only with the components of the view itself.
1290 
1291 #### Multi component standard view
1292 
1293 Multi component standard views iterate entities that have at least all the given
1294 components in their bags. During construction, these views look at the number of
1295 entities available for each component and pick up a reference to the smallest
1296 set of candidates in order to speed up iterations.<br/>
1297 They offer fewer functionalities than their companion views for single
1298 component. In particular, a multi component standard view exposes utility
1299 functions to get the estimated number of entities it is going to return and to
1300 know whether it's empty or not. It's also possible to ask a view if it contains
1301 a given entity.<br/>
1302 Refer to the inline documentation for all the details.
1303 
1304 There is no need to store views around for they are extremely cheap to
1305 construct, even though they can be copied without problems and reused freely. In
1306 fact, they return newly created and correctly initialized iterators whenever
1307 `begin` or `end` are invoked.<br/>
1308 To iterate a multi component standard view, either use it in range-for loop:
1309 
1310 ```cpp
1311 auto view = registry.view<Position, Velocity>();
1312 
1313 for(auto entity: view) {
1314  // a component at a time ...
1315  Position &position = view.get<Position>(entity);
1316  Velocity &velocity = view.get<Velocity>(entity);
1317 
1318  // ... or multiple components at once
1319  std::tuple<Position &, Velocity &> tup = view.get<Position, Velocity>(entity);
1320 
1321  // ...
1322 }
1323 ```
1324 
1325 Or rely on the `each` member function to iterate entities and get all their
1326 components at once:
1327 
1328 ```cpp
1329 registry.view<Position, Velocity>().each([](auto entity, auto &position, auto &velocity) {
1330  // ...
1331 });
1332 ```
1333 
1334 Performance are more or less the same. The best approach depends mainly on
1335 whether all the components have to be accessed or not.
1336 
1337 **Note**: prefer the `get` member function of a view instead of the `get` member
1338 function template of a registry during iterations, if possible. However, keep in
1339 mind that it works only with the components of the view itself.
1340 
1341 ### Persistent View
1342 
1343 A persistent view returns all the entities and only the entities that have at
1344 least the given components. Moreover, it's guaranteed that the entity list is
1345 tightly packed in memory for fast iterations.<br/>
1346 In general, persistent views don't stay true to the order of any set of
1347 components unless users explicitly sort them.
1348 
1349 Persistent views can be used only to iterate multiple components. To create this
1350 kind of views, the tag `persistent_t` must also be used in order to disambiguate
1351 overloads of the `view` member function:
1352 
1353 ```cpp
1354 auto view = registry.view<Position, Velocity>(entt::persistent_t{});
1355 ```
1356 
1357 There is no need to store views around for they are extremely cheap to
1358 construct, even though they can be copied without problems and reused freely. In
1359 fact, they return newly created and correctly initialized iterators whenever
1360 `begin` or `end` are invoked.<br/>
1361 That being said, persistent views perform an initialization step the very first
1362 time they are constructed and this could be quite costly. To avoid it, consider
1363 asking to the registry to _prepare_ them when no entities have been created yet:
1364 
1365 ```cpp
1366 registry.prepare<Position, Velocity>();
1367 ```
1368 
1369 If the registry is empty, preparation is extremely fast. Moreover the `prepare`
1370 member function template is idempotent. Feel free to invoke it even more than
1371 once: if the view has been already prepared before, the function returns
1372 immediately and does nothing.
1373 
1374 A persistent view offers a bunch of functionalities to get the number of
1375 entities it's going to return, a raw access to the entity list and the
1376 possibility to sort the underlying data structures according to the order of one
1377 of the components for which it has been constructed. It's also possible to ask a
1378 view if it contains a given entity.<br/>
1379 Refer to the inline documentation for all the details.
1380 
1381 To iterate a persistent view, either use it in range-for loop:
1382 
1383 ```cpp
1384 auto view = registry.view<Position, Velocity>(entt::persistent_t{});
1385 
1386 for(auto entity: view) {
1387  // a component at a time ...
1388  Position &position = view.get<Position>(entity);
1389  Velocity &velocity = view.get<Velocity>(entity);
1390 
1391  // ... or multiple components at once
1392  std::tuple<Position &, Velocity &> tup = view.get<Position, Velocity>(entity);
1393 
1394  // ...
1395 }
1396 ```
1397 
1398 Or rely on the `each` member function to iterate entities and get all their
1399 components at once:
1400 
1401 ```cpp
1402 registry.view<Position, Velocity>(entt::persistent_t{}).each([](auto entity, auto &position, auto &velocity) {
1403  // ...
1404 });
1405 ```
1406 
1407 Performance are more or less the same. The best approach depends mainly on
1408 whether all the components have to be accessed or not.
1409 
1410 **Note**: prefer the `get` member function of a view instead of the `get` member
1411 function template of a registry during iterations, if possible. However, keep in
1412 mind that it works only with the components of the view itself.
1413 
1414 ### Raw View
1415 
1416 Raw views return all the components of a given type. This kind of views can
1417 access components directly and avoid extra indirections like when components are
1418 accessed via an entity identifier.<br/>
1419 They offer a bunch of functionalities to get the number of instances they are
1420 going to return and a raw access to the entity list as well as to the component
1421 list.<br/>
1422 Refer to the inline documentation for all the details.
1423 
1424 Raw views can be used only to iterate components for a single type. To create
1425 this kind of views, the tag `raw_t` must also be used in order to disambiguate
1426 overloads of the `view` member function:
1427 
1428 ```cpp
1429 auto view = registry.view<Renderable>(entt::raw_t{});
1430 ```
1431 
1432 There is no need to store views around for they are extremely cheap to
1433 construct, even though they can be copied without problems and reused freely. In
1434 fact, they return newly created and correctly initialized iterators whenever
1435 `begin` or `end` are invoked.<br/>
1436 To iterate a raw view, use it in range-for loop:
1437 
1438 ```cpp
1439 auto view = registry.view<Renderable>(entt::raw_t{});
1440 
1441 for(auto &&component: raw) {
1442  // ...
1443 }
1444 ```
1445 
1446 **Note**: raw views don't have the `each` nor the `get` member function for
1447 obvious reasons. The former would only return the components and therefore it
1448 would be redundant, the latter isn't required at all.
1449 
1450 ### Give me everything
1451 
1452 Views are narrow windows on the entire list of entities. They work by filtering
1453 entities according to their components.<br/>
1454 In some cases there may be the need to iterate all the entities still in use
1455 regardless of their components. The registry offers a specific member function
1456 to do that:
1457 
1458 ```cpp
1459 registry.each([](auto entity) {
1460  // ...
1461 });
1462 ```
1463 
1464 It returns to the caller all the entities that are still in use by means of the
1465 given function.<br/>
1466 As a rule of thumb, consider using a view if the goal is to iterate entities
1467 that have a determinate set of components. A view is usually much faster than
1468 combining this function with a bunch of custom tests.<br/>
1469 In all the other cases, this is the way to go.
1470 
1471 There exists also another member function to use to retrieve orphans. An orphan
1472 is an entity that is still in use and has neither assigned components nor
1473 tags.<br/>
1474 The signature of the function is the same of `each`:
1475 
1476 ```cpp
1477 registry.orphans([](auto entity) {
1478  // ...
1479 });
1480 ```
1481 
1482 To test the _orphanity_ of a single entity, use the member function `orphan`
1483 instead. It accepts a valid entity identifer as an argument and returns true in
1484 case the entity is an orphan, false otherwise.
1485 
1486 In general, all these functions can result in poor performance.<br/>
1487 `each` is fairly slow because of some checks it performs on each and every
1488 entity. For similar reasons, `orphans` can be even slower. Both functions should
1489 not be used frequently to avoid the risk of a performance hit.
1490 
1491 ## Side notes
1492 
1493 * Entity identifiers are numbers and nothing more. They are not classes and they
1494  have no member functions at all. As already mentioned, do no try to inspect or
1495  modify an entity descriptor in any way.
1496 
1497 * As shown in the examples above, the preferred way to get references to the
1498  components while iterating a view is by using the view itself. It's a faster
1499  alternative to the `get` member function template that is part of the API of
1500  the `Registry`. This is because the registry must ensure that a pool for the
1501  given component exists before to use it; on the other side, views force the
1502  construction of the pools for all their components and access them directly,
1503  thus avoiding all the checks.
1504 
1505 * Most of the _ECS_ available out there have some annoying limitations (at least
1506  from my point of view): entities and components cannot be created and/or
1507  destroyed during iterations.<br/>
1508  `EnTT` partially solves the problem with a few limitations:
1509 
1510  * Creating entities and components is allowed during iterations.
1511  * Deleting an entity or removing its components is allowed during iterations
1512  if it's the one currently returned by a view. For all the other entities,
1513  destroying them or removing their components isn't allowed and it can result
1514  in undefined behavior.
1515 
1516  Iterators are invalidated and the behavior is undefined if an entity is
1517  modified or destroyed and it's not the one currently returned by the
1518  view.<br/>
1519  To work around it, possible approaches are:
1520 
1521  * Store aside the entities and the components to be removed and perform the
1522  operations at the end of the iteration.
1523  * Mark entities and components with a proper tag component that indicates
1524  they must be purged, then perform a second iteration to clean them up one
1525  by one.
1526 
1527 * Views and thus their iterators aren't thread safe. Do no try to iterate a set
1528  of components and modify the same set concurrently.<br/>
1529  That being said, as long as a thread iterates the entities that have the
1530  component `X` or assign and removes that component from a set of entities,
1531  another thread can safely do the same with components `Y` and `Z` and
1532  everything will work like a charm.<br/>
1533  As a trivial example, users can freely execute the rendering system and
1534  iterate the renderable entities while updating a physic component concurrently
1535  on a separate thread.
1536 
1537 * In general, the entire registry isn't thread safe as it is. Thread safety
1538  isn't something that users should want out of the box for several reasons.
1539  Just to mention one of them: performance.<br/>
1540  This kind of entity-component systems can be used in single threaded
1541  applications as well as along with async stuff. Moreover, typical thread based
1542  models for ECS don't require a fully thread safe registry to work. Actually
1543  one could reach the goal with the registry as it is while working with most of
1544  the common models, after all.<br/>
1545  Because of the few reasons mentioned above and many others not mentioned,
1546  users are completely responsible for synchronization whether required.
1547 
1548 # Crash Course: core functionalities
1549 
1550 The `EnTT` framework comes with a bunch of core functionalities mostly used by
1551 the other parts of the library itself.<br/>
1552 Hardly users of the framework will include these features in their code, but
1553 it's worth describing what `EnTT` offers so as not to reinvent the wheel in case
1554 of need.
1555 
1556 ## Compile-time identifiers
1557 
1558 Sometimes it's useful to be able to give unique identifiers to types at
1559 compile-time.<br/>
1560 There are plenty of different solutions out there and I could have used one of
1561 them. However, I decided to spend my time to define a compact and versatile tool
1562 that fully embraces what the modern C++ has to offer.
1563 
1564 The _result of my efforts_ is the `ident` `constexpr` variable:
1565 
1566 ```cpp
1567 #include <ident.hpp>
1568 
1569 // defines the identifiers for the given types
1570 constexpr auto identifiers = entt::ident<AType, AnotherType>;
1571 
1572 // ...
1573 
1574 switch(aTypeIdentifier) {
1575 case identifers.get<AType>():
1576  // ...
1577  break;
1578 case identifers.get<AnotherType>():
1579  // ...
1580  break;
1581 default:
1582  // ...
1583 }
1584 ```
1585 
1586 This is all what the variable has to offer: a `get` member function that returns
1587 a numerical identifier for the given type. It can be used in any context where
1588 constant expressions are required.
1589 
1590 As long as the list remains unchanged, identifiers are also guaranteed to be the
1591 same for every run. In case they have been used in a production environment and
1592 a type has to be removed, one can just use a placeholder to left the other
1593 identifiers unchanged:
1594 
1595 ```cpp
1596 template<typename> struct IgnoreType {};
1597 
1598 constexpr auto identifiers = entt::ident<
1599  ATypeStillValid,
1600  IgnoreType<ATypeNoLongerValid>,
1601  AnotherTypeStillValid
1602 >;
1603 ```
1604 
1605 A bit ugly to see, but it works at least.
1606 
1607 ## Runtime identifiers
1608 
1609 Sometimes it's useful to be able to give unique identifiers to types at
1610 runtime.<br/>
1611 There are plenty of different solutions out there and I could have used one of
1612 them. In fact, I adapted the most common one to my requirements and used it
1613 extensively within the entire framework.
1614 
1615 It's the `Family` class. Here is an example of use directly from the
1616 entity-component system:
1617 
1618 ```cpp
1619 using component_family = entt::Family<struct InternalRegistryComponentFamily>;
1620 
1621 // ...
1622 
1623 template<typename Component>
1624 component_type component() const noexcept {
1625  return component_family::type<Component>();
1626 }
1627 ```
1628 
1629 This is all what a _family_ has to offer: a `type` member function that returns
1630 a numerical identifier for the given type.
1631 
1632 Please, note that identifiers aren't guaranteed to be the same for every run.
1633 Indeed it mostly depends on the flow of execution.
1634 
1635 ## Hashed strings
1636 
1637 A hashed string is a zero overhead resource identifier. Users can use
1638 human-readable identifiers in the codebase while using their numeric
1639 counterparts at runtime, thus without affecting performance.<br/>
1640 The class has an implicit `constexpr` constructor that chews a bunch of
1641 characters. Once created, all what one can do with it is getting back the
1642 original string or converting it into a number.<br/>
1643 The good part is that a hashed string can be used wherever a constant expression
1644 is required and no _string-to-number_ conversion will take place at runtime if
1645 used carefully.
1646 
1647 Example of use:
1648 
1649 ```cpp
1650 auto load(entt::HashedString::hash_type resource) {
1651  // uses the numeric representation of the resource to load and return it
1652 }
1653 
1654 auto resource = load(entt::HashedString{"gui/background"});
1655 ```
1656 
1657 ### Conflicts
1658 
1659 The hashed string class uses internally FNV-1a to compute the numeric
1660 counterpart of a string. Because of the _pigeonhole principle_, conflicts are
1661 possible. This is a fact.<br/>
1662 There is no silver bullet to solve the problem of conflicts when dealing with
1663 hashing functions. In this case, the best solution seemed to be to give up.
1664 That's all.<br/>
1665 After all, human-readable resource identifiers aren't something strictly defined
1666 and over which users have not the control. Choosing a slightly different
1667 identifier is probably the best solution to make the conflict disappear in this
1668 case.
1669 
1670 # Crash Course: service locator
1671 
1672 Usually service locators are tightly bound to the services they expose and it's
1673 hard to define a general purpose solution. This template based implementation
1674 tries to fill the gap and to get rid of the burden of defining a different
1675 specific locator for each application.<br/>
1676 This class is tiny, partially unsafe and thus risky to use. Moreover it doesn't
1677 fit probably most of the scenarios in which a service locator is required. Look
1678 at it as a small tool that can sometimes be useful if the user knows how to
1679 handle it.
1680 
1681 The API is straightforward. The basic idea is that services are implemented by
1682 means of interfaces and rely on polymorphism.<br/>
1683 The locator is instantiated with the base type of the service if any and a
1684 concrete implementation is provided along with all the parameters required to
1685 initialize it. As an example:
1686 
1687 ```cpp
1688 // the service has no base type, a locator is used to treat it as a kind of singleton
1689 entt::ServiceLocator<MyService>::set(params...);
1690 
1691 // sets up an opaque service
1692 entt::ServiceLocator<AudioInterface>::set<AudioImplementation>(params...);
1693 
1694 // resets (destroys) the service
1695 entt::ServiceLocator<AudioInterface>::reset();
1696 ```
1697 
1698 The locator can also be queried to know if an active service is currently set
1699 and to retrieve it if necessary (either as a pointer or as a reference):
1700 
1701 ```cpp
1702 // no service currently set
1703 auto empty = entt::ServiceLocator<AudioInterface>::empty();
1704 
1705 // gets a (possibly empty) shared pointer to the service ...
1706 std::shared_ptr<AudioInterface> ptr = entt::ServiceLocator<AudioInterface>::get();
1707 
1708 // ... or a reference, but it's undefined behaviour if the service isn't set yet
1709 AudioInterface &ref = entt::ServiceLocator<AudioInterface>::ref();
1710 ```
1711 
1712 A common use is to wrap the different locators in a container class, creating
1713 aliases for the various services:
1714 
1715 ```cpp
1716 struct Locator {
1717  using Camera = entt::ServiceLocator<CameraInterface>;
1718  using Audio = entt::ServiceLocator<AudioInterface>;
1719  // ...
1720 };
1721 
1722 // ...
1723 
1724 void init() {
1725  Locator::Camera::set<CameraNull>();
1726  Locator::Audio::set<AudioImplementation>(params...);
1727  // ...
1728 }
1729 ```
1730 
1731 # Crash Course: cooperative scheduler
1732 
1733 Sometimes processes are a useful tool to work around the strict definition of a
1734 system and introduce logic in a different way, usually without resorting to the
1735 introduction of other components.
1736 
1737 The `EnTT` framework offers a minimal support to this paradigm by introducing a
1738 few classes that users can use to define and execute cooperative processes.
1739 
1740 ## The process
1741 
1742 A typical process must inherit from the `Process` class template that stays true
1743 to the CRTP idiom. Moreover, derived classes must specify what's the intended
1744 type for elapsed times.
1745 
1746 A process should expose publicly the following member functions whether
1747 required (note that it isn't required to define a function unless the derived
1748 class wants to _override_ the default behavior):
1749 
1750 * `void update(Delta, void *);`
1751 
1752  It's invoked once per tick until a process is explicitly aborted or it
1753  terminates either with or without errors. Even though it's not mandatory to
1754  declare this member function, as a rule of thumb each process should at
1755  least define it to work properly. The `void *` parameter is an opaque pointer
1756  to user data (if any) forwarded directly to the process during an update.
1757 
1758 * `void init(void *);`
1759 
1760  It's invoked at the first tick, immediately before an update. The `void *`
1761  parameter is an opaque pointer to user data (if any) forwarded directly to the
1762  process during an update.
1763 
1764 * `void succeeded();`
1765 
1766  It's invoked in case of success, immediately after an update and during the
1767  same tick.
1768 
1769 * `void failed();`
1770 
1771  It's invoked in case of errors, immediately after an update and during the
1772  same tick.
1773 
1774 * `void aborted();`
1775 
1776  It's invoked only if a process is explicitly aborted. There is no guarantee
1777  that it executes in the same tick, this depends solely on whether the
1778  process is aborted immediately or not.
1779 
1780 Derived classes can also change the internal state of a process by invoking
1781 `succeed` and `fail`, as well as `pause` and `unpause` the process itself. All
1782 these are protected member functions made available to be able to manage the
1783 life cycle of a process from a derived class.
1784 
1785 Here is a minimal example for the sake of curiosity:
1786 
1787 ```cpp
1788 struct MyProcess: entt::Process<MyProcess, std::uint32_t> {
1789  using delta_type = std::uint32_t;
1790 
1791  void update(delta_type delta, void *) {
1792  remaining = delta > remaining ? delta_type{] : (remaining - delta);
1793 
1794  // ...
1795 
1796  if(!remaining) {
1797  succeed();
1798  }
1799  }
1800 
1801  void init(void *data) {
1802  remaining = *static_cast<delta_type *>(data);
1803  }
1804 
1805 private:
1806  delta_type remaining;
1807 };
1808 ```
1809 
1810 ### Adaptor
1811 
1812 Lambdas and functors can't be used directly with a scheduler for they are not
1813 properly defined processes with managed life cycles.<br/>
1814 This class helps in filling the gap and turning lambdas and functors into
1815 full featured processes usable by a scheduler.
1816 
1817 The function call operator has a signature similar to the one of the `update`
1818 function of a process but for the fact that it receives two extra arguments to
1819 call whenever a process is terminated with success or with an error:
1820 
1821 ```cpp
1822 void(Delta delta, void *data, auto succeed, auto fail);
1823 ```
1824 
1825 Parameters have the following meaning:
1826 
1827 * `delta` is the elapsed time.
1828 * `data` is an opaque pointer to user data if any, `nullptr` otherwise.
1829 * `succeed` is a function to call when a process terminates with success.
1830 * `fail` is a function to call when a process terminates with errors.
1831 
1832 Both `succeed` and `fail` accept no parameters at all.
1833 
1834 Note that usually users shouldn't worry about creating adaptors at all. A
1835 scheduler creates them internally each and every time a lambda or a functor is
1836 used as a process.
1837 
1838 ## The scheduler
1839 
1840 A cooperative scheduler runs different processes and helps managing their life
1841 cycles.
1842 
1843 Each process is invoked once per tick. If it terminates, it's removed
1844 automatically from the scheduler and it's never invoked again. Otherwise it's
1845 a good candidate to run once more the next tick.<br/>
1846 A process can also have a child. In this case, the process is replaced with
1847 its child when it terminates if it returns with success. In case of errors,
1848 both the process and its child are discarded. This way, it's easy to create
1849 chain of processes to run sequentially.
1850 
1851 Using a scheduler is straightforward. To create it, users must provide only the
1852 type for the elapsed times and no arguments at all:
1853 
1854 ```cpp
1855 Scheduler<std::uint32_t> scheduler;
1856 ```
1857 
1858 It has member functions to query its internal data structures, like `empty` or
1859 `size`, as well as a `clear` utility to reset it to a clean state:
1860 
1861 ```cpp
1862 // checks if there are processes still running
1863 bool empty = scheduler.empty();
1864 
1865 // gets the number of processes still running
1866 Scheduler<std::uint32_t>::size_type size = scheduler.size();
1867 
1868 // resets the scheduler to its initial state and discards all the processes
1869 scheduler.clear();
1870 ```
1871 
1872 To attach a process to a scheduler there are mainly two ways:
1873 
1874 * If the process inherits from the `Process` class template, it's enough to
1875  indicate its type and submit all the parameters required to construct it to
1876  the `attach` member function:
1877 
1878  ```cpp
1879  scheduler.attach<MyProcess>("foobar");
1880  ```
1881 
1882 * Otherwise, in case of a lambda or a functor, it's enough to provide an
1883  instance of the class to the `attach` member function:
1884 
1885  ```cpp
1886  scheduler.attach([](auto...){ /* ... */ });
1887  ```
1888 
1889 In both cases, the return value is an opaque object that offers a `then` member
1890 function to use to create chains of processes to run sequentially.<br/>
1891 As a minimal example of use:
1892 
1893 ```cpp
1894 // schedules a task in the form of a lambda function
1895 scheduler.attach([](auto delta, void *, auto succeed, auto fail) {
1896  // ...
1897 })
1898 // appends a child in the form of another lambda function
1899 .then([](auto delta, void *, auto succeed, auto fail) {
1900  // ...
1901 })
1902 // appends a child in the form of a process class
1903 .then<MyProcess>();
1904 ```
1905 
1906 To update a scheduler and thus all its processes, the `update` member function
1907 is the way to go:
1908 
1909 ```cpp
1910 // updates all the processes, no user data are provided
1911 scheduler.update(delta);
1912 
1913 // updates all the processes and provides them with custom data
1914 scheduler.update(delta, &data);
1915 ```
1916 
1917 In addition to these functions, the scheduler offers an `abort` member function
1918 that can be used to discard all the running processes at once:
1919 
1920 ```cpp
1921 // aborts all the processes abruptly ...
1922 scheduler.abort(true);
1923 
1924 // ... or gracefully during the next tick
1925 scheduler.abort();
1926 ```
1927 
1928 # Crash Course: resource management
1929 
1930 Resource management is usually one of the most critical part of a software like
1931 a game. Solutions are often tuned to the particular application. There exist
1932 several approaches and all of them are perfectly fine as long as they fit the
1933 requirements of the piece of software in which they are used.<br/>
1934 Examples are loading everything on start, loading on request, predictive
1935 loading, and so on.
1936 
1937 The `EnTT` framework doesn't pretend to offer a _one-fits-all_ solution for the
1938 different cases. Instead, it offers a minimal and perhaps trivial cache that can
1939 be useful most of the time during prototyping and sometimes even in a production
1940 environment.<br/>
1941 For those interested in the subject, the plan is to improve it considerably over
1942 time in terms of performance, memory usage and functionalities. Hoping to make
1943 it, of course, one step at a time.
1944 
1945 ## The resource, the loader and the cache
1946 
1947 There are three main actors in the model: the resource, the loader and the
1948 cache.
1949 
1950 The _resource_ is whatever the user wants it to be. An image, a video, an audio,
1951 whatever. There are no limits.<br/>
1952 As a minimal example:
1953 
1954 ```cpp
1955 struct MyResource { const int value; };
1956 ```
1957 
1958 A _loader_ is a class the aim of which is to load a specific resource. It has to
1959 inherit directly from the dedicated base class as in the following example:
1960 
1961 ```cpp
1962 struct MyLoader final: entt::ResourceLoader<MyLoader, MyResource> {
1963  // ...
1964 };
1965 ```
1966 
1967 Where `MyResource` is the type of resources it creates.<br/>
1968 A resource loader must also expose a public const member function named `load`
1969 that accepts a variable number of arguments and returns a shared pointer to a
1970 resource.<br/>
1971 As an example:
1972 
1973 ```cpp
1974 struct MyLoader: entt::ResourceLoader<MyLoader, MyResource> {
1975  std::shared_ptr<MyResource> load(int value) const {
1976  // ...
1977  return std::shared_ptr<MyResource>(new MyResource{ value });
1978  }
1979 };
1980 ```
1981 
1982 In general, resource loaders should not have a state or retain data of any type.
1983 They should let the cache manage their resources instead.<br/>
1984 As a side note, base class and CRTP idiom aren't strictly required with the
1985 current implementation. One could argue that a cache can easily work with
1986 loaders of any type. However, future changes won't be breaking ones by forcing
1987 the use of a base class today and that's why the model is already in its place.
1988 
1989 Finally, a cache is a specialization of a class template tailored to a specific
1990 resource:
1991 
1992 ```cpp
1993 using MyResourceCache = entt::ResourceCache<MyResource>;
1994 
1995 // ...
1996 
1997 MyResourceCache cache{};
1998 ```
1999 
2000 The idea is to create different caches for different types of resources and to
2001 manage each one independently and in the most appropriate way.<br/>
2002 As a (very) trivial example, audio tracks can survive in most of the scenes of
2003 an application while meshes can be associated with a single scene and then
2004 discarded when the user leaves it.
2005 
2006 A cache offers a set of basic functionalities to query its internal state and to
2007 _organize_ it:
2008 
2009 ```cpp
2010 // gets the number of resources managed by a cache
2011 auto size = cache.size();
2012 
2013 // checks if a cache contains at least a valid resource
2014 auto empty = cache.empty();
2015 
2016 // clears a cache and discards its content
2017 cache.clear();
2018 ```
2019 
2020 Besides these member functions, it contains what is needed to load, use and
2021 discard resources of the given type.<br/>
2022 Before to explore this part of the interface, it makes sense to mention how
2023 resources are identified. The type of the identifiers to use is defined as:
2024 
2025 ```cpp
2026 entt::ResourceCache<Resource>::resource_type
2027 ```
2028 
2029 Where `resource_type` is an alias for `entt::HashedString`. Therefore, resource
2030 identifiers are created explicitly as in the following example:
2031 
2032 ```cpp
2033 constexpr auto identifier = entt::ResourceCache<Resource>::resource_type{"my/resource/identifier"};
2034 // this is equivalent to the following
2035 constexpr auto hs = entt::HashedString{"my/resource/identifier"};
2036 ```
2037 
2038 The class `HashedString` is described in a dedicated section, so I won't do in
2039 details here.
2040 
2041 Resources are loaded and thus stored in a cache through the `load` member
2042 function. It accepts the loader to use as a template parameter, the resource
2043 identifier and the parameters used to construct the resource as arguments:
2044 
2045 ```cpp
2046 // uses the identifier declared above
2047 cache.load<MyLoader>(identifier, 0);
2048 
2049 // uses a const char * directly as an identifier
2050 cache.load<MyLoader>("another/identifier", 42);
2051 ```
2052 
2053 The return value can be used to know if the resource has been loaded correctly.
2054 In case the loader returns an invalid pointer or the resource already exists in
2055 the cache, a false value is returned:
2056 
2057 ```cpp
2058 if(!cache.load<MyLoader>("another/identifier", 42)) {
2059  // ...
2060 }
2061 ```
2062 
2063 Unfortunately, in this case there is no way to know what was the problem
2064 exactly. However, before trying to load a resource or after an error, one can
2065 use the `contains` member function to know if a cache already contains a
2066 specific resource:
2067 
2068 ```cpp
2069 auto exists = cache.contains("my/identifier");
2070 ```
2071 
2072 There exists also a member function to use to force a reload of an already
2073 existing resource if needed:
2074 
2075 ```cpp
2076 auto result = cache.reload<MyLoader>("another/identifier", 42);
2077 ```
2078 
2079 As above, the function returns true in case of success, false otherwise. The
2080 sole difference in this case is that an error necessarily means that the loader
2081 has failed for some reasons to load the resource.<br/>
2082 Note that the `reload` member function is a kind of alias of the following
2083 snippet:
2084 
2085 ```cpp
2086 cache.discard(identifier);
2087 cache.load<MyLoader>(identifier, 42);
2088 ```
2089 
2090 Where the `discard` member function is used to get rid of a resource if loaded.
2091 In case the cache doesn't contain a resource for the given identifier, the
2092 function does nothing and returns immediately.
2093 
2094 So far, so good. Resources are finally loaded and stored within the cache.<br/>
2095 They are returned to users in the form of handles. To get one of them:
2096 
2097 ```cpp
2098 auto handle = cache.handle("my/identifier");
2099 ```
2100 
2101 The idea behind a handle is the same of the flyweight pattern. In other terms,
2102 resources aren't copied around. Instead, instances are shared between handles.
2103 Users of a resource owns a handle and it guarantees that a resource isn't
2104 destroyed until all the handles are destroyed, even if the resource itself is
2105 removed from the cache.<br/>
2106 Handles are tiny objects both movable and copyable. They returns the contained
2107 resource as a const reference on request:
2108 
2109 * By means of the `get` member function:
2110 
2111  ```cpp
2112  const auto &resource = handle.get();
2113  ```
2114 
2115 * Using the proper cast operator:
2116 
2117  ```cpp
2118  const auto &resource = handle;
2119  ```
2120 
2121 * Through the dereference operator:
2122 
2123  ```cpp
2124  const auto &resource = *handle;
2125  ```
2126 
2127 The resource can also be accessed directly using the arrow operator if required:
2128 
2129 ```cpp
2130 auto value = handle->value;
2131 ```
2132 
2133 To test if a handle is still valid, the cast operator to `bool` allows users to
2134 use it in a guard:
2135 
2136 ```cpp
2137 if(handle) {
2138  // ...
2139 }
2140 ```
2141 
2142 Finally, in case there is the need to load a resource and thus to get a handle
2143 without storing the resource itself in the cache, users can rely on the `temp`
2144 member function template.<br/>
2145 The declaration is similar to the one of `load` but for the fact that it doesn't
2146 return a boolean value. Instead, it returns a (possibly invalid) handle for the
2147 resource:
2148 
2149 ```cpp
2150 auto handle = cache.temp<MyLoader>("another/identifier", 42);
2151 ```
2152 
2153 Do not forget to test the handle for validity. Otherwise, getting the reference
2154 to the resource it points may result in undefined behavior.
2155 
2156 # Crash Course: events, signals and everything in between
2157 
2158 Signals are usually a core part of games and software architectures in
2159 general.<br/>
2160 Roughly speaking, they help to decouple the various parts of a system while
2161 allowing them to communicate with each other somehow.
2162 
2163 The so called _modern C++_ comes with a tool that can be useful in these terms,
2164 the `std::function`. As an example, it can be used to create delegates.<br/>
2165 However, there is no guarantee that an `std::function` does not perform
2166 allocations under the hood and this could be problematic sometimes. Furthermore,
2167 it solves a problem but may not adapt well to other requirements that may arise
2168 from time to time.
2169 
2170 In case that the flexibility and potential of an `std::function` are not
2171 required or where you are looking for something different, the `EnTT` framework
2172 offers a full set of classes to solve completely different problems.
2173 
2174 ## Signals
2175 
2176 Signal handlers work with naked pointers, function pointers and pointers to
2177 member functions. Listeners can be any kind of objects and the user is in charge
2178 of connecting and disconnecting them from a signal to avoid crashes due to
2179 different lifetimes. On the other side, performance shouldn't be affected that
2180 much by the presence of such a signal handler.<br/>
2181 A signal handler can be used as a private data member without exposing any
2182 _publish_ functionality to the clients of a class. The basic idea is to impose a
2183 clear separation between the signal itself and its _sink_ class, that is a tool
2184 to be used to connect and disconnect listeners on the fly.
2185 
2186 The API of a signal handler is straightforward. The most important thing is that
2187 it comes in two forms: with and without a collector. In case a signal is
2188 associated with a collector, all the values returned by the listeners can be
2189 literally _collected_ and used later by the caller. Otherwise it works just like
2190 a plain signal that emits events from time to time.<br/>
2191 
2192 **Note**: collectors are allowed only in case of function types whose the return
2193 type isn't `void` for obvious reasons.
2194 
2195 To create instances of signal handlers there exist mainly two ways:
2196 
2197 ```cpp
2198 // no collector type
2199 entt::SigH<void(int, char)> signal;
2200 
2201 // explicit collector type
2202 entt::SigH<void(int, char), MyCollector<bool>> collector;
2203 ```
2204 
2205 As expected, they offer all the basic functionalities required to know how many
2206 listeners they contain (`size`) or if they contain at least a listener (`empty`)
2207 and even to swap two signal handlers (`swap`).
2208 
2209 Besides them, there are member functions to use both to connect and disconnect
2210 listeners in all their forms by means of a sink::
2211 
2212 ```cpp
2213 void foo(int, char) { /* ... */ }
2214 
2215 struct S {
2216  void bar(int, char) { /* ... */ }
2217 };
2218 
2219 // ...
2220 
2221 S instance;
2222 
2223 signal.sink().connect<&foo>();
2224 signal.sink().connect<S, &S::bar>(&instance);
2225 
2226 // ...
2227 
2228 // disconnects a free function
2229 signal.sink().disconnect<&foo>();
2230 
2231 // disconnect a specific member function of an instance ...
2232 signal.sink().disconnect<S, &S::bar>(&instance);
2233 
2234 // ... or an instance as a whole
2235 signal.sink().disconnect(&instance);
2236 
2237 // discards all the listeners at once
2238 signal.sink().disconnect();
2239 ```
2240 
2241 Once listeners are attached (or even if there are no listeners at all), events
2242 and data in general can be published through a signal by means of the `publish`
2243 member function:
2244 
2245 ```cpp
2246 signal.publish(42, 'c');
2247 ```
2248 
2249 To collect data, the `collect` member function should be used instead. Below is
2250 a minimal example to show how to use it:
2251 
2252 ```cpp
2253 struct MyCollector {
2254  std::vector<int> vec{};
2255 
2256  bool operator()(int v) noexcept {
2257  vec.push_back(v);
2258  return true;
2259  }
2260 };
2261 
2262 int f() { return 0; }
2263 int g() { return 1; }
2264 
2265 // ...
2266 
2267 entt::SigH<int(), MyCollector<int>> signal;
2268 
2269 signal.sink().connect<&f>();
2270 signal.sink().connect<&g>();
2271 
2272 MyCollector collector = signal.collect();
2273 
2274 assert(collector.vec[0] == 0);
2275 assert(collector.vec[1] == 1);
2276 ```
2277 
2278 As shown above, a collector must expose a function operator that accepts as an
2279 argument a type to which the return type of the listeners can be converted.
2280 Moreover, it has to return a boolean value that is false to stop collecting
2281 data, true otherwise. This way one can avoid calling all the listeners in case
2282 it isn't necessary.
2283 
2284 ## Delegate
2285 
2286 A delegate can be used as general purpose invoker with no memory overhead for
2287 free functions and member functions provided along with an instance on which
2288 to invoke them.<br/>
2289 It does not claim to be a drop-in replacement for an `std::function`, so do not
2290 expect to use it whenever an `std::function` fits well. However, it can be used
2291 to send opaque delegates around to be used to invoke functions as needed.
2292 
2293 The interface is trivial. It offers a default constructor to create empty
2294 delegates:
2295 
2296 ```cpp
2297 entt::Delegate<int(int)> delegate{};
2298 ```
2299 
2300 All what is needed to create an instance is to specify the type of the function
2301 the delegate will _contain_, that is the signature of the free function or the
2302 member function one wants to assign to it.
2303 
2304 Attempting to use an empty delegate by invoking its function call operator
2305 results in undefined behavior, most likely a crash actually. Before to use a
2306 delegate, it must be initialized.<br/>
2307 There exist two functions to do that, both named `connect`:
2308 
2309 ```cpp
2310 int f(int i) { return i; }
2311 
2312 struct MyStruct {
2313  int f(int i) { return i }
2314 };
2315 
2316 // bind a free function to the delegate
2317 delegate.connect<&f>();
2318 
2319 // bind a member function to the delegate
2320 MyStruct instance;
2321 delegate.connect<MyStruct, &MyStruct::f>(&instance);
2322 ```
2323 
2324 It hasn't a `disconnect` counterpart. Instead, there exists a `reset` member
2325 function to clear it.<br/>
2326 Finally, to invoke a delegate, the function call operator is the way to go as
2327 usual:
2328 
2329 ```cpp
2330 auto ret = delegate(42);
2331 ```
2332 
2333 Probably too much small and pretty poor of functionalities, but the delegate
2334 class can help in a lot of cases and it has shown that it is worth keeping it
2335 within the framework.
2336 
2337 ## Event dispatcher
2338 
2339 The event dispatcher class is designed so as to be used in a loop. It allows
2340 users both to trigger immediate events or to queue events to be published all
2341 together once per tick.<br/>
2342 This class shares part of its API with the one of the signal handler, but it
2343 doesn't require that all the types of events are specified when declared:
2344 
2345 ```cpp
2346 // define a general purpose dispatcher that works with naked pointers
2347 entt::Dispatcher dispatcher{};
2348 ```
2349 
2350 In order to register an instance of a class to a dispatcher, its type must
2351 expose one or more member functions of which the return types are `void` and the
2352 argument lists are `const E &`, for each type of event `E`.<br/>
2353 To ease the development, member functions that are named `receive` are
2354 automatically detected and have not to be explicitly specified when registered.
2355 In all the other cases, the name of the member function aimed to receive the
2356 event must be provided to the `connect` member function of the sink bound to the
2357 specific event:
2358 
2359 ```cpp
2360 struct AnEvent { int value; };
2361 struct AnotherEvent {};
2362 
2363 struct Listener
2364 {
2365  void receive(const AnEvent &) { /* ... */ }
2366  void method(const AnotherEvent &) { /* ... */ }
2367 };
2368 
2369 // ...
2370 
2371 Listener listener;
2372 dispatcher.sink<AnEvent>().connect(&listener);
2373 dispatcher.sink<AnotherEvent>().connect<Listener, &Listener::method>(&listener);
2374 ```
2375 
2376 The `disconnect` member function follows the same pattern and can be used to
2377 selectively remove listeners:
2378 
2379 ```cpp
2380 dispatcher.sink<AnEvent>().disconnect(&listener);
2381 dispatcher.sink<AnotherEvent>().disconnect<Listener, &Listener::method>(&listener);
2382 ```
2383 
2384 The `trigger` member function serves the purpose of sending an immediate event
2385 to all the listeners registered so far. It offers a convenient approach that
2386 relieves the user from having to create the event itself. Instead, it's enough
2387 to specify the type of event and provide all the parameters required to
2388 construct it.<br/>
2389 As an example:
2390 
2391 ```cpp
2392 dispatcher.trigger<AnEvent>(42);
2393 dispatcher.trigger<AnotherEvent>();
2394 ```
2395 
2396 Listeners are invoked immediately, order of execution isn't guaranteed. This
2397 method can be used to push around urgent messages like an _is terminating_
2398 notification on a mobile app.
2399 
2400 On the other hand, the `enqueue` member function queues messages together and
2401 allows to maintain control over the moment they are sent to listeners. The
2402 signature of this method is more or less the same of `trigger`:
2403 
2404 ```cpp
2405 dispatcher.enqueue<AnEvent>(42);
2406 dispatcher.enqueue<AnotherEvent>();
2407 ```
2408 
2409 Events are stored aside until the `update` member function is invoked, then all
2410 the messages that are still pending are sent to the listeners at once:
2411 
2412 ```cpp
2413 // emits all the events of the given type at once
2414 dispatcher.update<MyEvent>();
2415 
2416 // emits all the events queued so far at once
2417 dispatcher.update();
2418 ```
2419 
2420 This way users can embed the dispatcher in a loop and literally dispatch events
2421 once per tick to their systems.
2422 
2423 ## Event emitter
2424 
2425 A general purpose event emitter thought mainly for those cases where it comes to
2426 working with asynchronous stuff.<br/>
2427 Originally designed to fit the requirements of
2428 [`uvw`](https://github.com/skypjack/uvw) (a wrapper for `libuv` written in
2429 modern C++), it was adapted later to be included in this library.
2430 
2431 To create a custom emitter type, derived classes must inherit directly from the
2432 base class as:
2433 
2434 ```cpp
2435 struct MyEmitter: Emitter<MyEmitter> {
2436  // ...
2437 }
2438 ```
2439 
2440 The full list of accepted types of events isn't required. Handlers are created
2441 internally on the fly and thus each type of event is accepted by default.
2442 
2443 Whenever an event is published, an emitter provides the listeners with a
2444 reference to itself along with a const reference to the event. Therefore
2445 listeners have an handy way to work with it without incurring in the need of
2446 capturing a reference to the emitter itself.<br/>
2447 In addition, an opaque object is returned each time a connection is established
2448 between an emitter and a listener, allowing the caller to disconnect them at a
2449 later time.<br/>
2450 The opaque object used to handle connections is both movable and copyable. On
2451 the other side, an event emitter is movable but not copyable by default.
2452 
2453 To create new instances of an emitter, no arguments are required:
2454 
2455 ```cpp
2456 MyEmitter emitter{};
2457 ```
2458 
2459 Listeners must be movable and callable objects (free functions, lambdas,
2460 functors, `std::function`s, whatever) whose function type is:
2461 
2462 ```cpp
2463 void(const Event &, MyEmitter &)
2464 ```
2465 
2466 Where `Event` is the type of event they want to listen.<br/>
2467 There are two ways to attach a listener to an event emitter that differ
2468 slightly from each other:
2469 
2470 * To register a long-lived listener, use the `on` member function. It is meant
2471  to register a listener designed to be invoked more than once for the given
2472  event type.<br/>
2473  As an example:
2474 
2475  ```cpp
2476  auto conn = emitter.on<MyEvent>([](const MyEvent &event, MyEmitter &emitter) {
2477  // ...
2478  });
2479  ```
2480 
2481  The connection object can be freely discarded. Otherwise, it can be used later
2482  to disconnect the listener if required.
2483 
2484 * To register a short-lived listener, use the `once` member function. It is
2485  meant to register a listener designed to be invoked only once for the given
2486  event type. The listener is automatically disconnected after the first
2487  invocation.<br/>
2488  As an example:
2489 
2490  ```cpp
2491  auto conn = emitter.once<MyEvent>([](const MyEvent &event, MyEmitter &emitter) {
2492  // ...
2493  });
2494  ```
2495 
2496  The connection object can be freely discarded. Otherwise, it can be used later
2497  to disconnect the listener if required.
2498 
2499 In both cases, the connection object can be used with the `erase` member
2500 function:
2501 
2502 ```cpp
2503 emitter.erase(conn);
2504 ```
2505 
2506 There are also two member functions to use either to disconnect all the
2507 listeners for a given type of event or to clear the emitter:
2508 
2509 ```cpp
2510 // removes all the listener for the specific event
2511 emitter.clear<MyEvent>();
2512 
2513 // removes all the listeners registered so far
2514 emitter.clear();
2515 ```
2516 
2517 To send an event to all the listeners that are interested in it, the `publish`
2518 member function offers a convenient approach that relieves the user from having
2519 to create the event:
2520 
2521 ```cpp
2522 struct MyEvent { int i; };
2523 
2524 // ...
2525 
2526 emitter.publish<MyEvent>(42);
2527 ```
2528 
2529 Finally, the `empty` member function tests if there exists at least either a
2530 listener registered with the event emitter or to a given type of event:
2531 
2532 ```cpp
2533 bool empty;
2534 
2535 // checks if there is any listener registered for the specific event
2536 empty = emitter.empty<MyEvent>();
2537 
2538 // checks it there are listeners registered with the event emitter
2539 empty = emitter.empty();
2540 ```
2541 
2542 In general, the event emitter is a handy tool when the derived classes _wrap_
2543 asynchronous operations, because it introduces a _nice-to-have_ model based on
2544 events and listeners that kindly hides the complexity behind the scenes. However
2545 it is not limited to such uses.
2546 
2547 # Packaging Tools
2548 
2549 `EnTT` is available for some of the most known packaging tools. In particular:
2550 
2551 * [`vcpkg`](https://github.com/Microsoft/vcpkg/tree/master/ports/entt),
2552  Microsoft VC++ Packaging Tool.
2553 * [`Homebrew`](https://github.com/skypjack/homebrew-entt), the missing package
2554  manager for macOS.<br/>
2555  Available as a homebrew formula. Just type the following to install it:
2556  ```
2557  brew install skypjack/entt/entt
2558  ```
2559 
2560 Consider this list a work in progress and help me to make it longer.
2561 
2562 # EnTT in Action
2563 
2564 `EnTT` is widely used in private and commercial applications. I cannot even
2565 mention most of them because of some signatures I put on some documents time
2566 ago.<br/>
2567 Fortunately, there are also people who took the time to implement open source
2568 projects based on EnTT and did not hold back when it came to documenting them.
2569 
2570 Below an incomplete list of projects and articles:
2571 
2572 * [EnttPong](https://github.com/reworks/EnttPong): example game for `EnTT`
2573  framework.
2574 * [ECS_SpaceBattle](https://github.com/vblanco20-1/ECS_SpaceBattle): huge space
2575  battle built on `UE4`.
2576 * [Experimenting with ECS in UE4](http://victor.madtriangles.com/code%20experiment/2018/03/25/post-ue4-ecs-battle.html):
2577  interesting article about `UE4` and `EnTT`.
2578 * [Implementing ECS architecture in UE4](https://forums.unrealengine.com/development-discussion/c-gameplay-programming/1449913-implementing-ecs-architecture-in-ue4-giant-space-battle):
2579  giant space battle.
2580 * [MatchOneEntt](https://github.com/mhaemmerle/MatchOneEntt): port of
2581  [Match One](https://github.com/sschmid/Match-One) for `Entitas-CSharp`.
2582 * [Randballs](https://github.com/gale93/randballs): simple `SFML` and `EnTT`
2583  playground.
2584 * ...
2585 
2586 If you know of other resources out there that are about `EnTT`, feel free to
2587 open an issue or a PR and I'll be glad to add them to the list.
2588 
2589 # Contributors
2590 
2591 If you want to participate, please see the guidelines for
2592 [contributing](https://github.com/skypjack/entt/blob/master/CONTRIBUTING)
2593 before to create issues or pull requests.<br/>
2594 Take also a look at the
2595 [contributors list](https://github.com/skypjack/entt/blob/master/AUTHORS) to
2596 know who has participated so far.
2597 
2598 # License
2599 
2600 Code and documentation Copyright (c) 2018 Michele Caini.<br/>
2601 Code released under
2602 [the MIT license](https://github.com/skypjack/entt/blob/master/LICENSE).
2603 Docs released under
2604 [Creative Commons](https://github.com/skypjack/entt/blob/master/docs/LICENSE).
2605 
2606 # Support
2607 
2608 ## Donation
2609 
2610 Developing and maintaining `EnTT` takes some time and lots of coffee. I'd like
2611 to add more and more functionalities in future and turn it in a full-featured
2612 framework.<br/>
2613 If you want to support this project, you can offer me an espresso. I'm from
2614 Italy, we're used to turning the best coffee ever in code. If you find that
2615 it's not enough, feel free to support me the way you prefer.<br/>
2616 Take a look at the donation button at the top of the page for more details or
2617 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).
2618 
2619 ## Hire me
2620 
2621 If you start using `EnTT` and need help, if you want a new feature and want me
2622 to give it the highest priority, if you have any other reason to contact me:
2623 do not hesitate. I'm available for hiring.<br/>
2624 Feel free to take a look at my [profile](https://github.com/skypjack) and
2625 contact me by mail.