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

+Introduction

+

EnTT comes with a bunch of core functionalities mostly used by the other parts of the library itself.
+ Hardly users will include these features in their code, but it's worth describing what EnTT offers so as not to reinvent the wheel in case of need.

+

+Compile-time identifiers

+

Sometimes it's useful to be able to give unique identifiers to types at compile-time.
+ There are plenty of different solutions out there and I could have used one of them. However, I decided to spend my time to define a compact and versatile tool that fully embraces what the modern C++ has to offer.

+

The result of my efforts is the Identifier class template:

+
#include <ident.hpp>
// defines the identifiers for the given types
using ID = entt::Identifier<AType, AnotherType>;
// ...
switch(aTypeIdentifier) {
case ID::get<AType>():
// ...
break;
case ID::get<AnotherType>():
// ...
break;
default:
// ...
}

This is all what the class template has to offer: a static get member function that returns a numerical identifier for the given type. It can be used in any context where constant expressions are required.

+

As long as the list remains unchanged, identifiers are also guaranteed to be the same for every run. In case they have been used in a production environment and a type has to be removed, one can just use a placeholder to left the other identifiers unchanged:

+
template<typename> struct IgnoreType {};
using ID = entt::Identifier<
ATypeStillValid,
IgnoreType<ATypeNoLongerValid>,
AnotherTypeStillValid
>;

A bit ugly to see, but it works at least.

+

+Runtime identifiers

+

Sometimes it's useful to be able to give unique identifiers to types at runtime.
+ There are plenty of different solutions out there and I could have used one of them. In fact, I adapted the most common one to my requirements and used it extensively within the entire library.

+

It's the Family class. Here is an example of use directly from the entity-component system:

+
using component_family = entt::Family<struct InternalRegistryComponentFamily>;
// ...
template<typename Component>
component_type component() const noexcept {
return component_family::type<Component>();
}

This is all what a family has to offer: a type member function that returns a numerical identifier for the given type.

+

Please, note that identifiers aren't guaranteed to be the same for every run. Indeed it mostly depends on the flow of execution.

+

+Hashed strings

+

A hashed string is a zero overhead resource identifier. Users can use human-readable identifiers in the codebase while using their numeric counterparts at runtime, thus without affecting performance.
+ The class has an implicit constexpr constructor that chews a bunch of characters. Once created, all what one can do with it is getting back the original string or converting it into a number.
+ The good part is that a hashed string can be used wherever a constant expression is required and no string-to-number conversion will take place at runtime if used carefully.

+

Example of use:

+
auto load(entt::HashedString::hash_type resource) {
// uses the numeric representation of the resource to load and return it
}
auto resource = load(entt::HashedString{"gui/background"});

There is also a user defined literal dedicated to hashed strings to make them more user-friendly:

+
constexpr auto str = "text"_hs;

+Conflicts

+

The hashed string class uses internally FNV-1a to compute the numeric counterpart of a string. Because of the pigeonhole principle, conflicts are possible. This is a fact.
+ There is no silver bullet to solve the problem of conflicts when dealing with hashing functions. In this case, the best solution seemed to be to give up. That's all.
+ After all, human-readable resource identifiers aren't something strictly defined and over which users have not the control. Choosing a slightly different identifier is probably the best solution to make the conflict disappear in this case.

+

+Monostate

+

The monostate pattern is often presented as an alternative to a singleton based configuration system. This is exactly its purpose in EnTT. Moreover, this implementation is thread safe by design (hopefully).
+ Keys are represented by hashed strings, values are basic types like ints or bools. Values of different types can be associated to each key, even more than one at a time. Because of this, users must pay attention to use the same type both during an assignment and when they try to read back their data. Otherwise, they will probably incur in unexpected results.

+

Example of use:

+
entt::Monostate<entt::HashedString{"mykey"}>{} = true;
entt::Monostate<"mykey"_hs>{} = 42;
// ...
const bool b = entt::Monostate<"mykey"_hs>{};
const int i = entt::Monostate<entt::HashedString{"mykey"}>{};
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/autotoc_md41.html b/autotoc_md41.html new file mode 100644 index 000000000..9cf9e38a1 --- /dev/null +++ b/autotoc_md41.html @@ -0,0 +1,84 @@ + + + + + + + +EnTT: Crash Course: service locator + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.3 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ +
+
+
+
Crash Course: service locator
+
+
+

+Introduction

+

Usually service locators are tightly bound to the services they expose and it's hard to define a general purpose solution. This template based implementation tries to fill the gap and to get rid of the burden of defining a different specific locator for each application.
+ This class is tiny, partially unsafe and thus risky to use. Moreover it doesn't fit probably most of the scenarios in which a service locator is required. Look at it as a small tool that can sometimes be useful if users know how to handle it.

+

+Service locator

+

The API is straightforward. The basic idea is that services are implemented by means of interfaces and rely on polymorphism.
+ The locator is instantiated with the base type of the service if any and a concrete implementation is provided along with all the parameters required to initialize it. As an example:

+
// the service has no base type, a locator is used to treat it as a kind of singleton
entt::ServiceLocator<MyService>::set(params...);
// sets up an opaque service
entt::ServiceLocator<AudioInterface>::set<AudioImplementation>(params...);
// resets (destroys) the service
entt::ServiceLocator<AudioInterface>::reset();

The locator can also be queried to know if an active service is currently set and to retrieve it if necessary (either as a pointer or as a reference):

+
// no service currently set
auto empty = entt::ServiceLocator<AudioInterface>::empty();
// gets a (possibly empty) shared pointer to the service ...
std::shared_ptr<AudioInterface> ptr = entt::ServiceLocator<AudioInterface>::get();
// ... or a reference, but it's undefined behaviour if the service isn't set yet
AudioInterface &ref = entt::ServiceLocator<AudioInterface>::ref();

A common use is to wrap the different locators in a container class, creating aliases for the various services:

+
struct Locator {
using Camera = entt::ServiceLocator<CameraInterface>;
using Audio = entt::ServiceLocator<AudioInterface>;
// ...
};
// ...
void init() {
Locator::Camera::set<CameraNull>();
Locator::Audio::set<AudioImplementation>(params...);
// ...
}
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/autotoc_md44.html b/autotoc_md44.html new file mode 100644 index 000000000..b7c8c9452 --- /dev/null +++ b/autotoc_md44.html @@ -0,0 +1,133 @@ + + + + + + + +EnTT: Crash Course: cooperative scheduler + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.3 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ +
+
+
+
Crash Course: cooperative scheduler
+
+
+

+Introduction

+

Sometimes processes are a useful tool to work around the strict definition of a system and introduce logic in a different way, usually without resorting to the introduction of other components.

+

EnTT offers a minimal support to this paradigm by introducing a few classes that users can use to define and execute cooperative processes.

+

+The process

+

A typical process must inherit from the Process class template that stays true to the CRTP idiom. Moreover, derived classes must specify what's the intended type for elapsed times.

+

A process should expose publicly the following member functions whether required (note that it isn't required to define a function unless the derived class wants to override the default behavior):

+
    +

  • void update(Delta, void *);

    +

    It's invoked once per tick until a process is explicitly aborted or it terminates either with or without errors. Even though it's not mandatory to declare this member function, as a rule of thumb each process should at least define it to work properly. The void * parameter is an opaque pointer to user data (if any) forwarded directly to the process during an update.

    +
    • +

  • void init(void *);

    +

    It's invoked at the first tick, immediately before an update. The void * parameter is an opaque pointer to user data (if any) forwarded directly to the process during an update.

    +
    • +

  • void succeeded();

    +

    It's invoked in case of success, immediately after an update and during the same tick.

    +
    • +

  • void failed();

    +

    It's invoked in case of errors, immediately after an update and during the same tick.

    +
    • +

  • void aborted();

    +

    It's invoked only if a process is explicitly aborted. There is no guarantee that it executes in the same tick, this depends solely on whether the process is aborted immediately or not.

    +
    • +
+

Derived classes can also change the internal state of a process by invoking succeed and fail, as well as pause and unpause the process itself. All these are protected member functions made available to be able to manage the life cycle of a process from a derived class.

+

Here is a minimal example for the sake of curiosity:

+
struct MyProcess: entt::Process<MyProcess, std::uint32_t> {
using delta_type = std::uint32_t;
void update(delta_type delta, void *) {
remaining = delta > remaining ? delta_type{] : (remaining - delta);
// ...
if(!remaining) {
succeed();
}
}
void init(void *data) {
remaining = *static_cast<delta_type *>(data);
}
private:
delta_type remaining;
};

+Adaptor

+

Lambdas and functors can't be used directly with a scheduler for they are not properly defined processes with managed life cycles.
+ This class helps in filling the gap and turning lambdas and functors into full featured processes usable by a scheduler.

+

The function call operator has a signature similar to the one of the update function of a process but for the fact that it receives two extra arguments to call whenever a process is terminated with success or with an error:

+
void(Delta delta, void *data, auto succeed, auto fail);

Parameters have the following meaning:

+
    +
  • delta is the elapsed time.
    • +
  • data is an opaque pointer to user data if any, nullptr otherwise.
    • +
  • succeed is a function to call when a process terminates with success.
    • +
  • fail is a function to call when a process terminates with errors.
    • +
+

Both succeed and fail accept no parameters at all.

+

Note that usually users shouldn't worry about creating adaptors at all. A scheduler creates them internally each and every time a lambda or a functor is used as a process.

+

+The scheduler

+

A cooperative scheduler runs different processes and helps managing their life cycles.

+

Each process is invoked once per tick. If it terminates, it's removed automatically from the scheduler and it's never invoked again. Otherwise it's a good candidate to run once more the next tick.
+ A process can also have a child. In this case, the process is replaced with its child when it terminates if it returns with success. In case of errors, both the process and its child are discarded. This way, it's easy to create chain of processes to run sequentially.

+

Using a scheduler is straightforward. To create it, users must provide only the type for the elapsed times and no arguments at all:

+
Scheduler<std::uint32_t> scheduler;

It has member functions to query its internal data structures, like empty or size, as well as a clear utility to reset it to a clean state:

+
// checks if there are processes still running
const auto empty = scheduler.empty();
// gets the number of processes still running
Scheduler<std::uint32_t>::size_type size = scheduler.size();
// resets the scheduler to its initial state and discards all the processes
scheduler.clear();

To attach a process to a scheduler there are mainly two ways:

+
    +
  • If the process inherits from the Process class template, it's enough to indicate its type and submit all the parameters required to construct it to the attach member function:
    • +
+
scheduler.attach<MyProcess>("foobar");
    +
  • Otherwise, in case of a lambda or a functor, it's enough to provide an instance of the class to the attach member function:
    • +
+
scheduler.attach([](auto...){ /* ... */ });

In both cases, the return value is an opaque object that offers a then member function to use to create chains of processes to run sequentially.
+ As a minimal example of use:

+
// schedules a task in the form of a lambda function
scheduler.attach([](auto delta, void *, auto succeed, auto fail) {
// ...
})
// appends a child in the form of another lambda function
.then([](auto delta, void *, auto succeed, auto fail) {
// ...
})
// appends a child in the form of a process class
.then<MyProcess>();

To update a scheduler and thus all its processes, the update member function is the way to go:

+
// updates all the processes, no user data are provided
scheduler.update(delta);
// updates all the processes and provides them with custom data
scheduler.update(delta, &data);

In addition to these functions, the scheduler offers an abort member function that can be used to discard all the running processes at once:

+
// aborts all the processes abruptly ...
scheduler.abort(true);
// ... or gracefully during the next tick
scheduler.abort();
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/autotoc_md49.html b/autotoc_md49.html new file mode 100644 index 000000000..dc39051cc --- /dev/null +++ b/autotoc_md49.html @@ -0,0 +1,124 @@ + + + + + + + +EnTT: Crash Course: resource management + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.3 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ +
+
+
+
Crash Course: resource management
+
+
+

+Introduction

+

Resource management is usually one of the most critical part of a software like a game. Solutions are often tuned to the particular application. There exist several approaches and all of them are perfectly fine as long as they fit the requirements of the piece of software in which they are used.
+ Examples are loading everything on start, loading on request, predictive loading, and so on.

+

EnTT doesn't pretend to offer a one-fits-all solution for the different cases. Instead, it offers a minimal and perhaps trivial cache that can be useful most of the time during prototyping and sometimes even in a production environment.
+ For those interested in the subject, the plan is to improve it considerably over time in terms of performance, memory usage and functionalities. Hoping to make it, of course, one step at a time.

+

+The resource, the loader and the cache

+

There are three main actors in the model: the resource, the loader and the cache.

+

The resource is whatever users want it to be. An image, a video, an audio, whatever. There are no limits.
+ As a minimal example:

+
struct MyResource { const int value; };

A loader is a class the aim of which is to load a specific resource. It has to inherit directly from the dedicated base class as in the following example:

+
struct MyLoader final: entt::ResourceLoader<MyLoader, MyResource> {
// ...
};

Where MyResource is the type of resources it creates.
+ A resource loader must also expose a public const member function named load that accepts a variable number of arguments and returns a shared pointer to a resource.
+ As an example:

+
struct MyLoader: entt::ResourceLoader<MyLoader, MyResource> {
std::shared_ptr<MyResource> load(int value) const {
// ...
return std::shared_ptr<MyResource>(new MyResource{ value });
}
};

In general, resource loaders should not have a state or retain data of any type. They should let the cache manage their resources instead.
+ As a side note, base class and CRTP idiom aren't strictly required with the current implementation. One could argue that a cache can easily work with loaders of any type. However, future changes won't be breaking ones by forcing the use of a base class today and that's why the model is already in its place.

+

Finally, a cache is a specialization of a class template tailored to a specific resource:

+
using MyResourceCache = entt::ResourceCache<MyResource>;
// ...
MyResourceCache cache{};

The idea is to create different caches for different types of resources and to manage each one independently and in the most appropriate way.
+ As a (very) trivial example, audio tracks can survive in most of the scenes of an application while meshes can be associated with a single scene and then discarded when users leave it.

+

A cache offers a set of basic functionalities to query its internal state and to organize it:

+
// gets the number of resources managed by a cache
const auto size = cache.size();
// checks if a cache contains at least a valid resource
const auto empty = cache.empty();
// clears a cache and discards its content
cache.clear();

Besides these member functions, it contains what is needed to load, use and discard resources of the given type.
+ Before to explore this part of the interface, it makes sense to mention how resources are identified. The type of the identifiers to use is defined as:

+
entt::ResourceCache<Resource>::resource_type

Where resource_type is an alias for entt::HashedString. Therefore, resource identifiers are created explicitly as in the following example:

+
constexpr auto identifier = entt::ResourceCache<Resource>::resource_type{"my/resource/identifier"};
// this is equivalent to the following
constexpr auto hs = entt::HashedString{"my/resource/identifier"};

The class HashedString is described in a dedicated section, so I won't do in details here.

+

Resources are loaded and thus stored in a cache through the load member function. It accepts the loader to use as a template parameter, the resource identifier and the parameters used to construct the resource as arguments:

+
// uses the identifier declared above
cache.load<MyLoader>(identifier, 0);
// uses a const char * directly as an identifier
cache.load<MyLoader>("another/identifier", 42);

The return value can be used to know if the resource has been loaded correctly. In case the loader returns an invalid pointer or the resource already exists in the cache, a false value is returned:

+
if(!cache.load<MyLoader>("another/identifier", 42)) {
// ...
}

Unfortunately, in this case there is no way to know what was the problem exactly. However, before trying to load a resource or after an error, one can use the contains member function to know if a cache already contains a specific resource:

+
auto exists = cache.contains("my/identifier");

There exists also a member function to use to force a reload of an already existing resource if needed:

+
auto result = cache.reload<MyLoader>("another/identifier", 42);

As above, the function returns true in case of success, false otherwise. The sole difference in this case is that an error necessarily means that the loader has failed for some reasons to load the resource.
+ Note that the reload member function is a kind of alias of the following snippet:

+
cache.discard(identifier);
cache.load<MyLoader>(identifier, 42);

Where the discard member function is used to get rid of a resource if loaded. In case the cache doesn't contain a resource for the given identifier, the function does nothing and returns immediately.

+

So far, so good. Resources are finally loaded and stored within the cache.
+ They are returned to users in the form of handles. To get one of them:

+
auto handle = cache.handle("my/identifier");

The idea behind a handle is the same of the flyweight pattern. In other terms, resources aren't copied around. Instead, instances are shared between handles. Users of a resource owns a handle and it guarantees that a resource isn't destroyed until all the handles are destroyed, even if the resource itself is removed from the cache.
+ Handles are tiny objects both movable and copyable. They returns the contained resource as a const reference on request:

+
    +
  • By means of the get member function:
    • +
+
const auto &resource = handle.get();
    +
  • Using the proper cast operator:
    • +
+
const auto &resource = handle;
    +
  • Through the dereference operator:
    • +
+
const auto &resource = *handle;

The resource can also be accessed directly using the arrow operator if required:

+
auto value = handle->value;

To test if a handle is still valid, the cast operator to bool allows users to use it in a guard:

+
if(handle) {
// ...
}

Finally, in case there is the need to load a resource and thus to get a handle without storing the resource itself in the cache, users can rely on the temp member function template.
+ The declaration is similar to the one of load but for the fact that it doesn't return a boolean value. Instead, it returns a (possibly invalid) handle for the resource:

+
auto handle = cache.temp<MyLoader>("another/identifier", 42);

Do not forget to test the handle for validity. Otherwise, getting the reference to the resource it points may result in undefined behavior.

+
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/autotoc_md52.html b/autotoc_md52.html new file mode 100644 index 000000000..f6fb54a2e --- /dev/null +++ b/autotoc_md52.html @@ -0,0 +1,84 @@ + + + + + + + +EnTT: EnTT and shared libraries + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.3 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ +
+
+
+
EnTT and shared libraries
+
+
+

To make sure that an application and a shared library that use both EnTT can interact correctly when symbols are hidden by default, there are some tricks to follow.
+ In particular and in order to avoid undefined behaviors, all the instantiation of the Family class template shall be made explicit along with the system-wide specifier to use to export them.

+

At the time I'm writing this document, the classes that use internally the above mentioned class template are Dispatcher, Emitter and Registry. Therefore and as an example, if you use the Registry class template in your shared library and want to set symbols visibility to hidden by default, the following lines are required to allow it to function properly with a client that also uses the Registry somehow:

+
    +
  • On GNU/Linux:
    • +
+
namespace entt {
template class __attribute__((visibility("default"))) Family<struct InternalRegistryTagFamily>;
template class __attribute__((visibility("default"))) Family<struct InternalRegistryComponentFamily>;
template class __attribute__((visibility("default"))) Family<struct InternalRegistryHandlerFamily>;
}
    +
  • On Windows:
    • +
+
namespace entt {
template class __declspec(dllexport) Family<struct InternalRegistryTagFamily>;
template class __declspec(dllexport) Family<struct InternalRegistryComponentFamily>;
template class __declspec(dllexport) Family<struct InternalRegistryHandlerFamily>;
}

Otherwise, the risk is that type identifiers are different between the shared library and the application and this will prevent the whole thing from functioning correctly for obvious reasons.

+
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/autotoc_md53.html b/autotoc_md53.html new file mode 100644 index 000000000..66fc871f2 --- /dev/null +++ b/autotoc_md53.html @@ -0,0 +1,147 @@ + + + + + + + +EnTT: Crash Course: events, signals and everything in between + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.3 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ +
+
+
+
Crash Course: events, signals and everything in between
+
+
+

+Introduction

+

Signals are usually a core part of games and software architectures in general.
+ Roughly speaking, they help to decouple the various parts of a system while allowing them to communicate with each other somehow.

+

The so called _modern C++_ comes with a tool that can be useful in these terms, the std::function. As an example, it can be used to create delegates.
+ However, there is no guarantee that an std::function does not perform allocations under the hood and this could be problematic sometimes. Furthermore, it solves a problem but may not adapt well to other requirements that may arise from time to time.

+

In case that the flexibility and potential of an std::function are not required or where you are looking for something different, EnTT offers a full set of classes to solve completely different problems.

+

+Signals

+

Signal handlers work with naked pointers, function pointers and pointers to member functions. Listeners can be any kind of objects and users are in charge of connecting and disconnecting them from a signal to avoid crashes due to different lifetimes. On the other side, performance shouldn't be affected that much by the presence of such a signal handler.
+ A signal handler can be used as a private data member without exposing any publish functionality to the clients of a class. The basic idea is to impose a clear separation between the signal itself and its sink class, that is a tool to be used to connect and disconnect listeners on the fly.

+

The API of a signal handler is straightforward. The most important thing is that it comes in two forms: with and without a collector. In case a signal is associated with a collector, all the values returned by the listeners can be literally collected and used later by the caller. Otherwise it works just like a plain signal that emits events from time to time.
+

+

Note: collectors are allowed only in case of function types whose the return type isn't void for obvious reasons.

+

To create instances of signal handlers there exist mainly two ways:

+
// no collector type
entt::SigH<void(int, char)> signal;
// explicit collector type
entt::SigH<void(int, char), MyCollector<bool>> collector;

As expected, they offer all the basic functionalities required to know how many listeners they contain (size) or if they contain at least a listener (empty) and even to swap two signal handlers (swap).

+

Besides them, there are member functions to use both to connect and disconnect listeners in all their forms by means of a sink:

+
void foo(int, char) { /* ... */ }
struct S {
void bar(int, char) { /* ... */ }
};
// ...
S instance;
signal.sink().connect<&foo>();
signal.sink().connect<S, &S::bar>(&instance);
// ...
// disconnects a free function
signal.sink().disconnect<&foo>();
// disconnect a specific member function of an instance ...
signal.sink().disconnect<S, &S::bar>(&instance);
// ... or an instance as a whole
signal.sink().disconnect(&instance);
// discards all the listeners at once
signal.sink().disconnect();

Once listeners are attached (or even if there are no listeners at all), events and data in general can be published through a signal by means of the publish member function:

+
signal.publish(42, 'c');

To collect data, the collect member function should be used instead. Below is a minimal example to show how to use it:

+
struct MyCollector {
std::vector<int> vec{};
bool operator()(int v) noexcept {
vec.push_back(v);
return true;
}
};
int f() { return 0; }
int g() { return 1; }
// ...
entt::SigH<int(), MyCollector<int>> signal;
signal.sink().connect<&f>();
signal.sink().connect<&g>();
MyCollector collector = signal.collect();
assert(collector.vec[0] == 0);
assert(collector.vec[1] == 1);

As shown above, a collector must expose a function operator that accepts as an argument a type to which the return type of the listeners can be converted. Moreover, it has to return a boolean value that is false to stop collecting data, true otherwise. This way one can avoid calling all the listeners in case it isn't necessary.

+

+Delegate

+

A delegate can be used as general purpose invoker with no memory overhead for free functions and member functions provided along with an instance on which to invoke them.
+ It does not claim to be a drop-in replacement for an std::function, so do not expect to use it whenever an std::function fits well. However, it can be used to send opaque delegates around to be used to invoke functions as needed.

+

The interface is trivial. It offers a default constructor to create empty delegates:

+
entt::Delegate<int(int)> delegate{};

All what is needed to create an instance is to specify the type of the function the delegate will contain, that is the signature of the free function or the member function one wants to assign to it.

+

Attempting to use an empty delegate by invoking its function call operator results in undefined behavior, most likely a crash actually. Before to use a delegate, it must be initialized.
+ There exist two functions to do that, both named connect:

+
int f(int i) { return i; }
struct MyStruct {
int f(int i) { return i }
};
// bind a free function to the delegate
delegate.connect<&f>();
// bind a member function to the delegate
MyStruct instance;
delegate.connect<MyStruct, &MyStruct::f>(&instance);

It hasn't a disconnect counterpart. Instead, there exists a reset member function to clear it.
+ The empty member function can be used to know if a delegate is empty:

+
const auto empty = delegate.empty();

Finally, to invoke a delegate, the function call operator is the way to go as usual:

+
auto ret = delegate(42);

Probably too much small and pretty poor of functionalities, but the delegate class can help in a lot of cases and it has shown that it is worth keeping it within the library.

+

+Event dispatcher

+

The event dispatcher class is designed so as to be used in a loop. It allows users both to trigger immediate events or to queue events to be published all together once per tick.
+ This class shares part of its API with the one of the signal handler, but it doesn't require that all the types of events are specified when declared:

+
// define a general purpose dispatcher that works with naked pointers
entt::Dispatcher dispatcher{};

In order to register an instance of a class to a dispatcher, its type must expose one or more member functions of which the return types are void and the argument lists are const E &, for each type of event E.
+ To ease the development, member functions that are named receive are automatically detected and have not to be explicitly specified when registered. In all the other cases, the name of the member function aimed to receive the event must be provided to the connect member function of the sink bound to the specific event:

+
struct AnEvent { int value; };
struct AnotherEvent {};
struct Listener
{
void receive(const AnEvent &) { /* ... */ }
void method(const AnotherEvent &) { /* ... */ }
};
// ...
Listener listener;
dispatcher.sink<AnEvent>().connect(&listener);
dispatcher.sink<AnotherEvent>().connect<Listener, &Listener::method>(&listener);

The disconnect member function follows the same pattern and can be used to selectively remove listeners:

+
dispatcher.sink<AnEvent>().disconnect(&listener);
dispatcher.sink<AnotherEvent>().disconnect<Listener, &Listener::method>(&listener);

The trigger member function serves the purpose of sending an immediate event to all the listeners registered so far. It offers a convenient approach that relieves users from having to create the event itself. Instead, it's enough to specify the type of event and provide all the parameters required to construct it.
+ As an example:

+
dispatcher.trigger<AnEvent>(42);
dispatcher.trigger<AnotherEvent>();

Listeners are invoked immediately, order of execution isn't guaranteed. This method can be used to push around urgent messages like an is terminating notification on a mobile app.

+

On the other hand, the enqueue member function queues messages together and allows to maintain control over the moment they are sent to listeners. The signature of this method is more or less the same of trigger:

+
dispatcher.enqueue<AnEvent>(42);
dispatcher.enqueue<AnotherEvent>();

Events are stored aside until the update member function is invoked, then all the messages that are still pending are sent to the listeners at once:

+
// emits all the events of the given type at once
dispatcher.update<MyEvent>();
// emits all the events queued so far at once
dispatcher.update();

This way users can embed the dispatcher in a loop and literally dispatch events once per tick to their systems.

+

+Event emitter

+

A general purpose event emitter thought mainly for those cases where it comes to working with asynchronous stuff.
+ Originally designed to fit the requirements of uvw (a wrapper for libuv written in modern C++), it was adapted later to be included in this library.

+

To create a custom emitter type, derived classes must inherit directly from the base class as:

+
struct MyEmitter: Emitter<MyEmitter> {
// ...
}

The full list of accepted types of events isn't required. Handlers are created internally on the fly and thus each type of event is accepted by default.

+

Whenever an event is published, an emitter provides the listeners with a reference to itself along with a const reference to the event. Therefore listeners have an handy way to work with it without incurring in the need of capturing a reference to the emitter itself.
+ In addition, an opaque object is returned each time a connection is established between an emitter and a listener, allowing the caller to disconnect them at a later time.
+ The opaque object used to handle connections is both movable and copyable. On the other side, an event emitter is movable but not copyable by default.

+

To create new instances of an emitter, no arguments are required:

+
MyEmitter emitter{};

Listeners must be movable and callable objects (free functions, lambdas, functors, std::functions, whatever) whose function type is:

+
void(const Event &, MyEmitter &)

Where Event is the type of event they want to listen.
+ There are two ways to attach a listener to an event emitter that differ slightly from each other:

+
    +
  • To register a long-lived listener, use the on member function. It is meant to register a listener designed to be invoked more than once for the given event type.
    + As an example:
    • +
+
auto conn = emitter.on<MyEvent>([](const MyEvent &event, MyEmitter &emitter) {
// ...
});

The connection object can be freely discarded. Otherwise, it can be used later to disconnect the listener if required.

+
    +
  • To register a short-lived listener, use the once member function. It is meant to register a listener designed to be invoked only once for the given event type. The listener is automatically disconnected after the first invocation.
    + As an example:
    • +
+
auto conn = emitter.once<MyEvent>([](const MyEvent &event, MyEmitter &emitter) {
// ...
});

The connection object can be freely discarded. Otherwise, it can be used later to disconnect the listener if required.

+

In both cases, the connection object can be used with the erase member function:

+
emitter.erase(conn);

There are also two member functions to use either to disconnect all the listeners for a given type of event or to clear the emitter:

+
// removes all the listener for the specific event
emitter.clear<MyEvent>();
// removes all the listeners registered so far
emitter.clear();

To send an event to all the listeners that are interested in it, the publish member function offers a convenient approach that relieves users from having to create the event:

+
struct MyEvent { int i; };
// ...
emitter.publish<MyEvent>(42);

Finally, the empty member function tests if there exists at least either a listener registered with the event emitter or to a given type of event:

+
bool empty;
// checks if there is any listener registered for the specific event
empty = emitter.empty<MyEvent>();
// checks it there are listeners registered with the event emitter
empty = emitter.empty();

In general, the event emitter is a handy tool when the derived classes wrap asynchronous operations, because it introduces a nice-to-have model based on events and listeners that kindly hides the complexity behind the scenes. However it is not limited to such uses.

+
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/autotoc_md8.html b/autotoc_md8.html new file mode 100644 index 000000000..699d95ad5 --- /dev/null +++ b/autotoc_md8.html @@ -0,0 +1,461 @@ + + + + + + + +EnTT: Crash Course: entity-component system + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.3 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ +
+
+
+
Crash Course: entity-component system
+
+
+

+Introduction

+

EnTT is a header-only, tiny and easy to use entity-component system (and much more) written in modern C++.
+ The entity-component-system (also known as ECS) is an architectural pattern used mostly in game development.

+

+Design choices

+

+A bitset-free entity-component system

+

EnTT is a bitset-free entity-component system that doesn't require users to specify the component set at compile-time.
+ This is why users can instantiate the core class simply like:

+
entt::DefaultRegistry registry;

In place of its more annoying and error-prone counterpart:

+
entt::DefaultRegistry<Comp0, Comp1, ..., CompN> registry;

+Pay per use

+

EnTT is entirely designed around the principle that users have to pay only for what they want.

+

When it comes to using an entity-component system, the tradeoff is usually between performance and memory usage. The faster it is, the more memory it uses. However, slightly worse performance along non-critical paths are the right price to pay to reduce memory usage and I've always wondered why this kind of tools do not leave me the choice.
+ EnTT follows a completely different approach. It squeezes the best from the basic data structures and gives users the possibility to pay more for higher performance where needed.
+ The disadvantage of this approach is that users need to know the systems they are working on and the tools they are using. Otherwise, the risk to ruin the performance along critical paths is high.

+

So far, this choice has proven to be a good one and I really hope it can be for many others besides me.

+

+Vademecum

+

The Registry to store, the views to iterate. That's all.

+

An entity (the E of an ECS) is an opaque identifier that users should just use as-is and store around if needed. Do not try to inspect an entity identifier, its format can change in future and a registry offers all the functionalities to query them out-of-the-box. The underlying type of an entity (either std::uint16_t, std::uint32_t or std::uint64_t) can be specified when defining a registry (actually the DefaultRegistry is nothing more than a Registry where the type of the entities is std::uint32_t).
+ Components (the C of an ECS) should be plain old data structures or more complex and movable data structures with a proper constructor. Actually, the sole requirement of a component type is that it must be both move constructible and move assignable. They are list initialized by using the parameters provided to construct the component itself. No need to register components or their types neither with the registry nor with the entity-component system at all.
+ Systems (the S of an ECS) are just plain functions, functors, lambdas or whatever users want. They can accept a Registry or a view of any type and use them the way they prefer. No need to register systems or their types neither with the registry nor with the entity-component system at all.

+

The following sections will explain in short how to use the entity-component system, the core part of the whole library.
+ In fact, the project is composed of many other classes in addition to those describe below. For more details, please refer to the inline documentation.

+

+The Registry, the Entity and the Component

+

A registry can store and manage entities, as well as create views to iterate the underlying data structures.
+ Registry is a class template that lets users decide what's the preferred type to represent an entity. Because std::uint32_t is large enough for almost all the cases, there exists also an alias named DefaultRegistry for Registry<std::uint32_t>.

+

Entities are represented by entity identifiers. An entity identifier is an opaque type that users should not inspect or modify in any way. It carries information about the entity itself and its version.

+

A registry can be used both to construct and destroy entities:

+
// constructs a naked entity with no components and returns its identifier
auto entity = registry.create();
// destroys an entity and all its components
registry.destroy(entity);

Entities can also be destroyed by type, that is by specifying the types of the tags or components that identify them:

+
// destroys the entity that owns the given tag, if any
registry.destroy<MyTag>(entt::tag_t{});
// destroys the entities that own the given components, if any
registry.destroy<AComponent, AnotherComponent>();

When an entity is destroyed, the registry can freely reuse it internally with a slightly different identifier. In particular, the version of an entity is increased each and every time it's discarded.
+ In case entity identifiers are stored around, the registry offers all the functionalities required to test them and get out of the them all the information they carry:

+
// returns true if the entity is still valid, false otherwise
bool b = registry.valid(entity);
// gets the version contained in the entity identifier
auto version = registry.version(entity);
// gets the actual version for the given entity
auto curr = registry.current(entity);

Components can be assigned to or removed from entities at any time with a few calls to member functions of the registry. As for the entities, the registry offers also a set of functionalities users can use to work with the components.

+

The assign member function template creates, initializes and assigns to an entity the given component. It accepts a variable number of arguments to construct the component itself if present:

+
registry.assign<Position>(entity, 0., 0.);
// ...
Velocity &velocity = registry.assign<Velocity>(entity);
velocity.dx = 0.;
velocity.dy = 0.;

If an entity already has the given component, the replace member function template can be used to replace it:

+
registry.replace<Position>(entity, 0., 0.);
// ...
Velocity &velocity = registry.replace<Velocity>(entity);
velocity.dx = 0.;
velocity.dy = 0.;

In case users want to assign a component to an entity, but it's unknown whether the entity already has it or not, accommodate does the work in a single call (there is a performance penalty to pay for this mainly due to the fact that it has to check if the entity already has the given component or not):

+
registry.accommodate<Position>(entity, 0., 0.);
// ...
Velocity &velocity = registry.accommodate<Velocity>(entity);
velocity.dx = 0.;
velocity.dy = 0.;

Note that accommodate is a slightly faster alternative for the following if/else statement and nothing more:

+
if(registry.has<Comp>(entity)) {
registry.replace<Comp>(entity, arg1, argN);
} else {
registry.assign<Comp>(entity, arg1, argN);
}

As already shown, if in doubt about whether or not an entity has one or more components, the has member function template may be useful:

+
bool b = registry.has<Position, Velocity>(entity);

On the other side, if the goal is to delete a single component, the remove member function template is the way to go when it's certain that the entity owns a copy of the component:

+
registry.remove<Position>(entity);

Otherwise consider to use the reset member function. It behaves similarly to remove but with a strictly defined behavior (and a performance penalty is the price to pay for this). In particular it removes the component if and only if it exists, otherwise it returns safely to the caller:

+
registry.reset<Position>(entity);

There exist also two other versions of the reset member function:

+
    +
  • If no entity is passed to it, reset will remove the given component from each entity that has it:
    • +
+
registry.reset<Position>();
    +
  • If neither the entity nor the component are specified, all the entities still in use and their components are destroyed:
    • +
+
registry.reset();

Finally, references to components can be retrieved simply by doing this:

+
const auto &cregistry = registry;
// const and non-const reference
const Position &position = cregistry.get<Position>(entity);
Position &position = registry.get<Position>(entity);
// const and non-const references
std::tuple<const Position &, const Velocity &> tup = cregistry.get<Position, Velocity>(entity);
std::tuple<Position &, Velocity &> tup = registry.get<Position, Velocity>(entity);

The get member function template gives direct access to the component of an entity stored in the underlying data structures of the registry.

+

+Single instance components

+

In those cases where all what is needed is a single instance component, tags are the right tool to achieve the purpose.
+ Tags undergo the same requirements of components. They can be either plain old data structures or more complex and movable data structures with a proper constructor.
+ Actually, the same type can be used both as a tag and as a component and the registry will not complain about it. It is up to users to properly manage their own types. In some cases, the tag tag_t must also be used in order to disambiguate overloads of member functions.

+

Attaching tags to entities and removing them is trivial:

+
auto player = registry.create();
auto camera = registry.create();
// attaches a default-initialized tag to an entity
registry.assign<PlayingCharacter>(entt::tag_t{}, player);
// attaches a tag to an entity and initializes it
registry.assign<Camera>(entt::tag_t{}, camera, player);
// removes tags from their owners
registry.remove<PlayingCharacter>();
registry.remove<Camera>();

In case a tag already has an owner, its content can be updated by means of the replace member function template and the ownership of the tag can be transferred to another entity using the move member function template:

+
// replaces the content of the given tag
Point &point = registry.replace<Point>(entt::tag_t{}, 1.f, 1.f);
// transfers the ownership of the tag to another entity
entity_type prev = registry.move<Point>(next);

If in doubt about whether or not a tag already has an owner, the has member function template may be useful:

+
bool b = registry.has<PlayingCharacter>();

References to tags can be retrieved simply by doing this:

+
const auto &cregistry = registry;
// either a non-const reference ...
PlayingCharacter &player = registry.get<PlayingCharacter>();
// ... or a const one
const Camera &camera = cregistry.get<Camera>();

The get member function template gives direct access to the tag as stored in the underlying data structures of the registry.

+

As shown above, in almost all the cases the entity identifier isn't required. Since a single instance component can have only one associated entity, it doesn't make much sense to mention it explicitly.
+ To find out who the owner is, just do the following:

+
auto player = registry.attachee<PlayingCharacter>();

Note that iterating tags isn't possible for obvious reasons. Tags give direct access to single entities and nothing more.

+

+Observe changes

+

Because of how the registry works internally, it stores a couple of signal handlers for each pool in order to notify some of its data structures on the construction and destruction of components.
+ These signal handlers are also exposed and made available to users. This is the basic brick to build fancy things like dependencies and reactive systems.

+

To get a sink to be used to connect and disconnect listeners so as to be notified on the creation of a component, use the construction member function:

+
// connects a free function
registry.construction<Position>().connect<&MyFreeFunction>();
// connects a member function
registry.construction<Position>().connect<MyClass, &MyClass::member>(&instance);
// disconnects a free function
registry.construction<Position>().disconnect<&MyFreeFunction>();
// disconnects a member function
registry.construction<Position>().disconnect<MyClass, &MyClass::member>(&instance);

To be notified when components are destroyed, use the destruction member function instead.

+

The function type of a listener is the same in both cases:

+
void(Registry<Entity> &, Entity);

In other terms, a listener is provided with the registry that triggered the notification and the entity affected by the change. Note also that:

+
    +
  • Listeners are invoked after components have been assigned to entities.
    • +
  • Listeners are invoked before components have been removed from entities.
    • +
  • The order of invocation of the listeners isn't guaranteed in any case.
    • +
+

There are also some limitations on what a listener can and cannot do. In particular:

+
    +
  • Connecting and disconnecting other functions from within the body of a listener should be avoided. It can lead to undefined behavior in some cases.
    • +
  • Assigning and removing components and tags from within the body of a listener that observes the destruction of instances of a given type should be avoided. It can lead to undefined behavior in some cases. This type of listeners is intended to provide users with an easy way to perform cleanup and nothing more.
    • +
+

To a certain extent, these limitations do not apply. However, it is risky to try to force them and users should respect the limitations unless they know exactly what they are doing. Subtle bugs are the price to pay in case of errors otherwise.

+

In general, events and therefore listeners must not be used as replacements for systems. They should not contain much logic and interactions with a registry should be kept to a minimum, if possible. Note also that the greater the number of listeners, the greater the performance hit when components are created or destroyed.

+

+Who let the tags out?

+

As an extension, signals are also provided with tags. Although they are not strictly required internally, it makes sense that a user expects signal support even when it comes to tags actually.
+ Signals for tags undergo exactly the same requirements of those introduced for components. Also the function type for a listener is the same and it's invoked with the same guarantees discussed above.

+

To get the sinks for a tag just use tag tag_t to disambiguate overloads of member functions as in the following example:

+
registry.construction<MyTag>(entt::tag_t{}).connect<&MyFreeFunction>();
registry.destruction<MyTag>(entt::tag_t{}).connect<MyClass, &MyClass::member>(&instance);

Listeners for tags and components are managed separately and do not influence each other in any case. Therefore, note that the greater the number of listeners for a type, the greater the performance hit when a tag of the given type is created or destroyed.

+

+Runtime components

+

Defining components at runtime is useful to support plugin systems and mods in general. However, it seems impossible with a tool designed around a bunch of templates. Indeed it's not that difficult.
+ Of course, some features cannot be easily exported into a runtime environment. As an example, sorting a group of components defined at runtime isn't for free if compared to most of the other operations. However, the basic functionalities of an entity-component system such as EnTT fit the problem perfectly and can also be used to manage runtime components if required.
+ All that is necessary to do it is to know the identifiers of the components. An identifier is nothing more than a number or similar that can be used at runtime to work with the type system.

+

In EnTT, identifiers are easily accessible:

+
entt::DefaultRegistry registry;
// standard component identifier
auto ctype = registry.type<Position>();
// single instance component identifier
auto ttype = registry.type<PlayingCharacter>(entt::tag_t{});

Once the identifiers are made available, almost everything becomes pretty simple.

+

+A journey through a plugin

+

EnTT comes with an example (actually a test) that shows how to integrate compile-time and runtime components in a stack based JavaScript environment. It uses Duktape under the hood, mainly because I wanted to learn how it works at the time I was writing the code.

+

The code is not production-ready and overall performance can be highly improved. However, I sacrificed optimizations in favor of a more readable piece of code. I hope I succeeded.
+ Note also that this isn't neither the only nor (probably) the best way to do it. In fact, the right way depends on the scripting language and the problem one is facing in general.
+ That being said, feel free to use it at your own risk.

+

The basic idea is that of creating a compile-time component aimed to map all the runtime components assigned to an entity.
+ Identifiers come in use to address the right function from a map when invoked from the runtime environment and to filter entities when iterating.
+ With a bit of gymnastic, one can narrow views and improve the performance to some extent but it was not the goal of the example.

+

+Sorting: is it possible?

+

It goes without saying that sorting entities and components is possible with EnTT.
+ In fact, there are two functions that respond to slightly different needs:

+
    +
  • Components can be sorted directly:
    • +
+
registry.sort<Renderable>([](const auto &lhs, const auto &rhs) {
return lhs.z < rhs.z;
});

There exists also the possibility to use a custom sort function object, as long as it adheres to the requirements described in the inline documentation.
+ This is possible mainly because users can get much more with a custom sort function object if the pattern of usage is known. As an example, in case of an almost sorted pool, quick sort could be much, much slower than insertion sort.

+
    +
  • Components can be sorted according to the order imposed by another component:
    • +
+
registry.sort<Movement, Physics>();

In this case, instances of Movement are arranged in memory so that cache misses are minimized when the two components are iterated together.

+

+Snapshot: complete vs continuous

+

The Registry class offers basic support to serialization.
+ It doesn't convert components and tags to bytes directly, there wasn't the need of another tool for serialization out there. Instead, it accepts an opaque object with a suitable interface (namely an archive) to serialize its internal data structures and restore them later. The way types and instances are converted to a bunch of bytes is completely in charge to the archive and thus to final users.

+

The goal of the serialization part is to allow users to make both a dump of the entire registry or a narrower snapshot, that is to select only the components and the tags in which they are interested.
+ Intuitively, the use cases are different. As an example, the first approach is suitable for local save/restore functionalities while the latter is suitable for creating client-server applications and for transferring somehow parts of the representation side to side.

+

To take a snapshot of the registry, use the snapshot member function. It returns a temporary object properly initialized to save the whole registry or parts of it.

+

Example of use:

+
OutputArchive output;
registry.snapshot()
.entities(output)
.destroyed(output)
.component<AComponent, AnotherComponent>(output)
.tag<MyTag>(output);

It isn't necessary to invoke all these functions each and every time. What functions to use in which case mostly depends on the goal and there is not a golden rule to do that.

+

The entities member function asks the registry to serialize all the entities that are still in use along with their versions. On the other side, the destroyed member function tells to the registry to serialize the entities that have been destroyed and are no longer in use.
+ These two functions can be used to save and restore the whole set of entities with the versions they had during serialization.

+

The component member function is a function template the aim of which is to store aside components. The presence of a template parameter list is a consequence of a couple of design choices from the past and in the present:

+
    +
  • First of all, there is no reason to force a user to serialize all the components at once and most of the times it isn't desiderable. As an example, in case the stuff for the HUD in a game is put into the registry for some reasons, its components can be freely discarded during a serialization step because probably the software already knows how to reconstruct the HUD correctly from scratch.
    • +
  • Furthermore, the registry makes heavy use of type-erasure techniques internally and doesn't know at any time what types of components it contains. Therefore being explicit at the call point is mandatory.
    • +
+

There exists also another version of the component member function that accepts a range of entities to serialize. This version is a bit slower than the other one, mainly because it iterates the range of entities more than once for internal purposes. However, it can be used to filter out those entities that shouldn't be serialized for some reasons.
+ As an example:

+
const auto view = registry.view<Serialize>();
OutputArchive output;
registry.snapshot()
.component<AComponent, AnotherComponent>(output, view.cbegin(), view.cend());

The tag member function is similar to the previous one, apart from the fact that it works with tags and not with components.
+ Note also that both component and tag store items along with entities. It means that they work properly without a call to the entities member function.

+

Once a snapshot is created, there exist mainly two ways to load it: as a whole and in a kind of continuous mode.
+ The following sections describe both loaders and archives in details.

+

+Snapshot loader

+

A snapshot loader requires that the destination registry be empty and loads all the data at once while keeping intact the identifiers that the entities originally had.
+ To do that, the registry offers a member function named restore that returns a temporary object properly initialized to restore a snapshot.

+

Example of use:

+
InputArchive input;
registry.restore()
.entities(input)
.destroyed(input)
.component<AComponent, AnotherComponent>(input)
.tag<MyTag>(input)
.orphans();

It isn't necessary to invoke all these functions each and every time. What functions to use in which case mostly depends on the goal and there is not a golden rule to do that. For obvious reasons, what is important is that the data are restored in exactly the same order in which they were serialized.

+

The entities and destroyed member functions restore the sets of entities and the versions that the entities originally had at the source.

+

The component member function restores all and only the components specified and assigns them to the right entities. Note that the template parameter list must be exactly the same used during the serialization. The same applies to the tag member function.

+

The orphans member function literally destroys those entities that have neither components nor tags. It's usually useless if the snapshot is a full dump of the source. However, in case all the entities are serialized but only few components and tags are saved, it could happen that some of the entities have neither components nor tags once restored. The best users can do to deal with them is to destroy those entities and thus update their versions.

+

+Continuous loader

+

A continuous loader is designed to load data from a source registry to a (possibly) non-empty destination. The loader can accommodate in a registry more than one snapshot in a sort of continuous loading that updates the destination one step at a time.
+ Identifiers that entities originally had are not transferred to the target. Instead, the loader maps remote identifiers to local ones while restoring a snapshot. Because of that, this kind of loader offers a way to update automatically identifiers that are part of components or tags (as an example, as data members or gathered in a container).
+ Another difference with the snapshot loader is that the continuous loader does not need to work with the private data structures of a registry. Furthermore, it has an internal state that must persist over time. Therefore, there is no reason to create it by means of a registry, or to limit its lifetime to that of a temporary object.

+

Example of use:

+
entt::ContinuousLoader<entity_type> loader{registry};
InputArchive input;
loader.entities(input)
.destroyed(input)
.component<AComponent, AnotherComponent, DirtyComponent>(input, &DirtyComponent::parent, &DirtyComponent::child)
.tag<MyTag, DirtyTag>(input, &DirtyTag::container)
.orphans()
.shrink();

It isn't necessary to invoke all these functions each and every time. What functions to use in which case mostly depends on the goal and there is not a golden rule to do that. For obvious reasons, what is important is that the data are restored in exactly the same order in which they were serialized.

+

The entities and destroyed member functions restore groups of entities and map each entity to a local counterpart when required. In other terms, for each remote entity identifier not yet registered by the loader, the latter creates a local identifier so that it can keep the local entity in sync with the remote one.

+

The component and tag member functions restore all and only the components and the tags specified and assign them to the right entities.
+ In case the component or the tag contains entities itself (either as data members of type entity_type or as containers of entities), the loader can update them automatically. To do that, it's enough to specify the data members to update as shown in the example.

+

The orphans member function literally destroys those entities that have neither components nor tags after a restore. It has exactly the same purpose described in the previous section and works the same way.

+

Finally, shrink helps to purge local entities that no longer have a remote conterpart. Users should invoke this member function after restoring each snapshot, unless they know exactly what they are doing.

+

+Archives

+

Archives must publicly expose a predefined set of member functions. The API is straightforward and consists only of a group of function call operators that are invoked by the snapshot class and the loaders.

+

In particular:

+
    +
  • An output archive, the one used when creating a snapshot, must expose a function call operator with the following signature to store entities:
    • +
+
void operator()(Entity);

Where Entity is the type of the entities used by the registry. Note that all the member functions of the snapshot class make also an initial call to this endpoint to save the size of the set they are going to store.
+ In addition, an archive must accept a pair of entity and either component or tag for each type to be serialized. Therefore, given a type T, the archive must contain a function call operator with the following signature:

+
void operator()(Entity, const T &);

The output archive can freely decide how to serialize the data. The register is not affected at all by the decision.

+
    +
  • An input archive, the one used when restoring a snapshot, must expose a function call operator with the following signature to load entities:
    • +
+
void operator()(Entity &);

Where Entity is the type of the entities used by the registry. Each time the function is invoked, the archive must read the next element from the underlying storage and copy it in the given variable. Note that all the member functions of a loader class make also an initial call to this endpoint to read the size of the set they are going to load.
+ In addition, the archive must accept a pair of entity and either component or tag for each type to be restored. Therefore, given a type T, the archive must contain a function call operator with the following signature:

+
void operator()(Entity &, T &);

Every time such an operator is invoked, the archive must read the next elements from the underlying storage and copy them in the given variables.

+

+One example to rule them all

+

EnTT comes with some examples (actually some tests) that show how to integrate a well known library for serialization as an archive. It uses Cereal C++ under the hood, mainly because I wanted to learn how it works at the time I was writing the code.

+

The code is not production-ready and it isn't neither the only nor (probably) the best way to do it. However, feel free to use it at your own risk.

+

The basic idea is to store everything in a group of queues in memory, then bring everything back to the registry with different loaders.

+

+Prototype

+

A prototype defines a type of an application in terms of its parts. They can be used to assign components to entities of a registry at once.
+ Roughly speaking, in most cases prototypes can be considered just as templates to use to initialize entities according to concepts. In fact, users can create how many prototypes they want, each one initialized differently from the others.

+

The following is an example of use of a prototype:

+
entt::DefaultRegistry registry;
entt::DefaultPrototype prototype{registry};
prototype.set<Position>(100.f, 100.f);
prototype.set<Velocity>(0.f, 0.f);
// ...
const auto entity = prototype();

To assign and remove components from a prototype, it offers two dedicated member functions named set and unset. The has member function can be used to know if a given prototype contains one or more components and the get member function can be used to retrieve the components.

+

Creating an entity from a prototype is straightforward:

+
    +
  • To create a new entity from scratch and assign it a prototype, this is the way to go:
    const auto entity = prototype();
    It is equivalent to the following invokation:
    const auto entity = prototype.create();
    • +
  • In case we want to initialize an already existing entity, we can provide the operator() directly with the entity identifier:
    prototype(entity);
    It is equivalent to the following invokation:
    prototype.assign(entity);
    Note that existing components aren't overwritten in this case. Only those components that the entity doesn't own yet are copied over. All the other components remain unchanged.
    • +
  • Finally, to assign or replace all the components for an entity, thus overwriting existing ones:
    prototype.accommodate(entity);
    • +
+

In the examples above, the prototype uses its underlying registry to create entities and components both for its purposes and when it's cloned. To use a different repository to clone a prototype, all the member functions accept also a reference to a valid registry as a first argument.

+

Prototypes are a very useful tool that can save a lot of typing sometimes. Furthermore, the codebase may be easier to maintain, since updating a prototype is much less error prone than jumping around in the codebase to update all the snippets copied and pasted around to initialize entities and components.

+

+Helpers

+

The so called helpers are small classes and functions mainly designed to offer built-in support for the most basic functionalities.
+ The list of helpers will grow longer as time passes and new ideas come out.

+

+Dependency function

+

A dependency function is a predefined listener, actually a function template to use to automatically assign components to an entity when a type has a dependency on some other types.
+ The following adds components AType and AnotherType whenever MyType is assigned to an entity:

+
entt::connnect<AType, AnotherType>(registry.construction<MyType>());

A component is assigned to an entity and thus default initialized only in case the entity itself hasn't it yet. It means that already existent components won't be overriden.
+ A dependency can easily be broken by means of the following function template:

+
entt::disconnect<AType, AnotherType>(registry.construction<MyType>());

+Labels

+

There's nothing magical about the way labels can be assigned to entities while avoiding a performance hit at runtime. Nonetheless, the syntax can be annoying and that's why a more user-friendly shortcut is provided to do it.
+ This shortcut is the alias template entt::label.

+

If used in combination with hashed strings, it helps to use labels where types would be required otherwise. As an example:

+
registry.assign<entt::label<"enemy"_hs>>(entity);

+Null entity

+

In EnTT, there exists a sort of null entity made available to users that is accessible via the entt::null variable.
+ The library guarantees that the following expression always returns false:

+
registry.valid(entt::null);

In other terms, a registry will reject the null entity in all cases because it isn't considered valid. It means that the null entity cannot own components or tags for obvious reasons.
+ The type of the null entity is internal and should not be used for any purpose other than defining the null entity itself. However, there exist implicit conversions from the null entity to identifiers of any allowed type:

+
typename entt::DefaultRegistry::entity_type null = entt::null;

Similarly, the null entity can be compared to any other identifier:

+
const auto entity = registry.create();
const bool null = (entity == entt::null);

+View: to persist or not to persist?

+

First of all, it is worth answering an obvious question: why views?
+ Roughly speaking, they are a good tool to enforce single responsibility. A system that has access to a registry can create and destroy entities, as well as assign and remove components. On the other side, a system that has access to a view can only iterate entities and their components, then read or update the data members of the latter.
+ It is a subtle difference that can help designing a better software sometimes.

+

There are mainly four kinds of views: standard (also known as View), persistent (also known as PersistentView), raw (also known as RawView) and runtime (also known as RuntimeView).
+ All of them have pros and cons to take in consideration. In particular:

+
    +

  • Standard views:

    +

    Pros:

      +
    • They work out-of-the-box and don't require any dedicated data structure.
      • +
    • Creating and destroying them isn't expensive at all because they don't have any type of initialization.
      • +
    • They are the best tool for iterating entities for a single component.
      • +
    • They are the best tool for iterating entities for multiple components when one of the components is assigned to a significantly low number of entities.
      • +
    • They don't affect any other operations of the registry.
      • +
    +

    Cons:

      +
    • Their performance tend to degenerate when the number of components to iterate grows up and the most of the entities have all of them.
      • +
    +
    • +

  • Persistent views:

    +

    Pros:

      +
    • Once prepared, creating and destroying them isn't expensive at all because they don't have any type of initialization.
      • +
    • They are the best tool for iterating entities for multiple components when most entities have them all.
      • +
    +

    Cons:

      +
    • They have dedicated data structures and thus affect the memory usage to a minimal extent.
      • +
    • If not previously prepared, the first time they are used they go through an initialization step that could take a while.
      • +
    • They affect to a minimum the creation and destruction of entities and components. In other terms: the more persistent views there will be, the less performing will be creating and destroying entities and components.
      • +
    +
    • +

  • Raw views:

    +

    Pros:

      +
    • They work out-of-the-box and don't require any dedicated data structure.
      • +
    • Creating and destroying them isn't expensive at all because they don't have any type of initialization.
      • +
    • They are the best tool for iterating components when it is not necessary to know which entities they belong to.
      • +
    • They don't affect any other operations of the registry.
      • +
    +

    Cons:

      +
    • They can be used to iterate only one type of component at a time.
      • +
    • They don't return the entity to which a component belongs to the caller.
      • +
    +
    • +

  • Runtime views:

    +

    Pros:

      +
    • Their lists of components are defined at runtime and not at compile-time.
      • +
    • Creating and destroying them isn't expensive at all because they don't have any type of initialization.
      • +
    • They are the best tool for things like plugin systems and mods in general.
      • +
    • They don't affect any other operations of the registry.
      • +
    +

    Cons:

      +
    • Their performances are definitely lower than those of all the other views, although they are still usable and sufficient for most of the purposes.
      • +
    +
    • +
+

To sum up and as a rule of thumb:

+
    +
  • Use a raw view to iterate components only (no entities) for a given type.
    • +
  • Use a standard view to iterate entities and components for a single type.
    • +
  • Use a standard view to iterate entities and components for multiple types when the number of types is low. Standard views are really optimized and persistent views won't add much in this case.
    • +
  • Use a standard view to iterate entities and components for multiple types when a significantly low number of entities have one of the components.
    • +
  • Use a standard view in all those cases where a persistent view would give a boost to performance but the iteration isn't performed frequently.
    • +
  • Prepare and use a persistent view when you want to iterate only entities for multiple components.
    • +
  • Prepare and use a persistent view when you want to iterate entities for multiple components and each component is assigned to a great number of entities but the intersection between the sets of entities is small.
    • +
  • Prepare and use a persistent view in all the cases where a standard view wouldn't fit well otherwise.
    • +
  • Finally, in case you don't know at compile-time what are the components to use, choose a runtime view and set them during execution.
    • +
+

To easily iterate entities and components, all the views offer the common begin and end member functions that allow users to use a view in a typical range-for loop. Almost all the views offer also a more functional each member function that accepts a callback for convenience.
+ Continue reading for more details or refer to the inline documentation.

+

+Standard View

+

A standard view behaves differently if it's constructed for a single component or if it has been requested to iterate multiple components. Even the API is different in the two cases.
+ All that they share is the way they are created by means of a registry:

+
// single component standard view
auto single = registry.view<Position>();
// multi component standard view
auto multi = registry.view<Position, Velocity>();

For all that remains, it's worth discussing them separately.
+

+

+Single component standard view

+

Single component standard views are specialized in order to give a boost in terms of performance in all the situation. This kind of views can access the underlying data structures directly and avoid superfluous checks.
+ They offer a bunch of functionalities to get the number of entities they are going to return and a raw access to the entity list as well as to the component list. It's also possible to ask a view if it contains a given entity.
+ Refer to the inline documentation for all the details.

+

There is no need to store views around for they are extremely cheap to construct, even though they can be copied without problems and reused freely. In fact, they return newly created and correctly initialized iterators whenever begin or end are invoked.
+ To iterate a single component standard view, either use it in a range-for loop:

+
auto view = registry.view<Renderable>();
for(auto entity: view) {
Renderable &renderable = view.get(entity);
// ...
}

Or rely on the each member function to iterate entities and get all their components at once:

+
registry.view<Renderable>().each([](auto entity, auto &renderable) {
// ...
});

The each member function is highly optimized. Unless users want to iterate only entities, using each should be the preferred approach.

+

Note: prefer the get member function of a view instead of the get member function template of a registry during iterations, if possible. However, keep in mind that it works only with the components of the view itself.

+

+Multi component standard view

+

Multi component standard views iterate entities that have at least all the given components in their bags. During construction, these views look at the number of entities available for each component and pick up a reference to the smallest set of candidates in order to speed up iterations.
+ They offer fewer functionalities than their companion views for single component. In particular, a multi component standard view exposes utility functions to get the estimated number of entities it is going to return and to know whether it's empty or not. It's also possible to ask a view if it contains a given entity.
+ Refer to the inline documentation for all the details.

+

There is no need to store views around for they are extremely cheap to construct, even though they can be copied without problems and reused freely. In fact, they return newly created and correctly initialized iterators whenever begin or end are invoked.
+ To iterate a multi component standard view, either use it in a range-for loop:

+
auto view = registry.view<Position, Velocity>();
for(auto entity: view) {
// a component at a time ...
Position &position = view.get<Position>(entity);
Velocity &velocity = view.get<Velocity>(entity);
// ... or multiple components at once
std::tuple<Position &, Velocity &> tup = view.get<Position, Velocity>(entity);
// ...
}

Or rely on the each member function to iterate entities and get all their components at once:

+
registry.view<Position, Velocity>().each([](auto entity, auto &position, auto &velocity) {
// ...
});

The each member function is highly optimized. Unless users want to iterate only entities or get only some of the components, using each should be the preferred approach.

+

Note: prefer the get member function of a view instead of the get member function template of a registry during iterations, if possible. However, keep in mind that it works only with the components of the view itself.

+

+Persistent View

+

A persistent view returns all the entities and only the entities that have at least the given components. Moreover, it's guaranteed that the entity list is tightly packed in memory for fast iterations.
+ In general, persistent views don't stay true to the order of any set of components unless users explicitly sort them.

+

Persistent views can be used only to iterate multiple components. To create this kind of views, the tag persistent_t must also be used in order to disambiguate overloads of the view member function:

+
auto view = registry.view<Position, Velocity>(entt::persistent_t{});

There is no need to store views around for they are extremely cheap to construct, even though they can be copied without problems and reused freely. In fact, they return newly created and correctly initialized iterators whenever begin or end are invoked.
+ That being said, persistent views perform an initialization step the very first time they are constructed and this could be quite costly. To avoid it, consider asking to the registry to prepare them when no entities have been created yet:

+
registry.prepare<Position, Velocity>();

If the registry is empty, preparation is extremely fast. Moreover the prepare member function template is idempotent. Feel free to invoke it even more than once: if the view has been already prepared before, the function returns immediately and does nothing.

+

A persistent view offers a bunch of functionalities to get the number of entities it's going to return, a raw access to the entity list and the possibility to sort the underlying data structures according to the order of one of the components for which it has been constructed. It's also possible to ask a view if it contains a given entity.
+ Refer to the inline documentation for all the details.

+

To iterate a persistent view, either use it in a range-for loop:

+
auto view = registry.view<Position, Velocity>(entt::persistent_t{});
for(auto entity: view) {
// a component at a time ...
Position &position = view.get<Position>(entity);
Velocity &velocity = view.get<Velocity>(entity);
// ... or multiple components at once
std::tuple<Position &, Velocity &> tup = view.get<Position, Velocity>(entity);
// ...
}

Or rely on the each member function to iterate entities and get all their components at once:

+
registry.view<Position, Velocity>(entt::persistent_t{}).each([](auto entity, auto &position, auto &velocity) {
// ...
});

Performance are more or less the same. The best approach depends mainly on whether all the components have to be accessed or not.

+

Note: prefer the get member function of a view instead of the get member function template of a registry during iterations, if possible. However, keep in mind that it works only with the components of the view itself.

+

+Raw View

+

Raw views return all the components of a given type. This kind of views can access components directly and avoid extra indirections like when components are accessed via an entity identifier.
+ They offer a bunch of functionalities to get the number of instances they are going to return and a raw access to the entity list as well as to the component list.
+ Refer to the inline documentation for all the details.

+

Raw views can be used only to iterate components for a single type. To create this kind of views, the tag raw_t must also be used in order to disambiguate overloads of the view member function:

+
auto view = registry.view<Renderable>(entt::raw_t{});

There is no need to store views around for they are extremely cheap to construct, even though they can be copied without problems and reused freely. In fact, they return newly created and correctly initialized iterators whenever begin or end are invoked.
+ To iterate a raw view, use it in a range-for loop:

+
auto view = registry.view<Renderable>(entt::raw_t{});
for(auto &&component: raw) {
// ...
}

Or rely on the each member function:

+
registry.view<Renderable>(entt::raw_t{}).each([](auto &renderable) {
// ...
});

Performance are exactly the same in both cases.

+

Note: raw views don't have a get member function for obvious reasons.

+

+Runtime View

+

Runtime views iterate entities that have at least all the given components in their bags. During construction, these views look at the number of entities available for each component and pick up a reference to the smallest set of candidates in order to speed up iterations.
+ They offer more or less the same functionalities of a multi component standard view. However, they don't expose a get member function and users should refer to the registry that generated the view to access components. In particular, a runtime view exposes utility functions to get the estimated number of entities it is going to return and to know whether it's empty or not. It's also possible to ask a view if it contains a given entity.
+ Refer to the inline documentation for all the details.

+

Runtime view are extremely cheap to construct and should not be stored around in any case. They should be used immediately after creation and then they should be thrown away. The reasons for this go far beyond the scope of this document.
+ To iterate a runtime view, either use it in a range-for loop:

+
using component_type = typename decltype(registry)::component_type;
component_type types[] = { registry.type<Position>(), registry.type<Velocity>() };
auto view = registry.view(std::cbegin(types), std::cend(types));
for(auto entity: view) {
// a component at a time ...
Position &position = registry.get<Position>(entity);
Velocity &velocity = registry.get<Velocity>(entity);
// ... or multiple components at once
std::tuple<Position &, Velocity &> tup = view.get<Position, Velocity>(entity);
// ...
}

Or rely on the each member function to iterate entities:

+
using component_type = typename decltype(registry)::component_type;
component_type types[] = { registry.type<Position>(), registry.type<Velocity>() };
auto view = registry.view(std::cbegin(types), std::cend(types)).each([](auto entity) {
// ...
});

Performance are exactly the same in both cases.

+

Note: runtime views are meant for all those cases where users don't know at compile-time what components to use to iterate entities. This is particularly well suited to plugin systems and mods in general. Where possible, don't use runtime views, as their performance are slightly inferior to those of the other views.

+

+Give me everything

+

Views are narrow windows on the entire list of entities. They work by filtering entities according to their components.
+ In some cases there may be the need to iterate all the entities still in use regardless of their components. The registry offers a specific member function to do that:

+
registry.each([](auto entity) {
// ...
});

It returns to the caller all the entities that are still in use by means of the given function.
+ As a rule of thumb, consider using a view if the goal is to iterate entities that have a determinate set of components. A view is usually much faster than combining this function with a bunch of custom tests.
+ In all the other cases, this is the way to go.

+

There exists also another member function to use to retrieve orphans. An orphan is an entity that is still in use and has neither assigned components nor tags.
+ The signature of the function is the same of each:

+
registry.orphans([](auto entity) {
// ...
});

To test the orphanity of a single entity, use the member function orphan instead. It accepts a valid entity identifer as an argument and returns true in case the entity is an orphan, false otherwise.

+

In general, all these functions can result in poor performance.
+ each is fairly slow because of some checks it performs on each and every entity. For similar reasons, orphans can be even slower. Both functions should not be used frequently to avoid the risk of a performance hit.

+

+Iterations: what is allowed and what is not

+

Most of the ECS available out there have some annoying limitations (at least from my point of view): entities and components cannot be created nor destroyed during iterations.
+ EnTT partially solves the problem with a few limitations:

+
    +
  • Creating entities and components is allowed during iterations.
    • +
  • Deleting an entity or removing its components is allowed during iterations if it's the one currently returned by the view. For all the other entities, destroying them or removing their components isn't allowed and it can result in undefined behavior.
    • +
+

Iterators are invalidated and the behavior is undefined if an entity is modified or destroyed and it's not the one currently returned by the view nor a newly created one.
+ To work around it, possible approaches are:

+
    +
  • Store aside the entities and the components to be removed and perform the operations at the end of the iteration.
    • +
  • Mark entities and components with a proper tag component that indicates they must be purged, then perform a second iteration to clean them up one by one.
    • +
+

A notable side effect of this feature is that the number of required allocations is further reduced in most of the cases.

+

+Multithreading

+

In general, the entire registry isn't thread safe as it is. Thread safety isn't something that users should want out of the box for several reasons. Just to mention one of them: performance.
+ Views and consequently the approach adopted by EnTT are the great exception to the rule. It's true that views and thus their iterators aren't thread safe by themselves. Because of this users shouldn't try to iterate a set of components and modify the same set concurrently. However:

+
    +
  • As long as a thread iterates the entities that have the component X or assign and removes that component from a set of entities, another thread can safely do the same with components Y and Z and everything will work like a charm. As a trivial example, users can freely execute the rendering system and iterate the renderable entities while updating a physic component concurrently on a separate thread.
    • +
  • Similarly, a single set of components can be iterated by multiple threads as long as the components are neither assigned nor removed in the meantime. In other words, a hypothetical movement system can start multiple threads, each of which will access the components that carry information about velocity and position for its entities.
    • +
+

This kind of entity-component systems can be used in single threaded applications as well as along with async stuff or multiple threads. Moreover, typical thread based models for ECS don't require a fully thread safe registry to work. Actually, users can reach the goal with the registry as it is while working with most of the common models.

+

Because of the few reasons mentioned above and many others not mentioned, users are completely responsible for synchronization whether required. On the other hand, they could get away with it without having to resort to particular expedients.

+
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/cache_8hpp_source.html b/cache_8hpp_source.html index 0c28e23d4..d81aec370 100644 --- a/cache_8hpp_source.html +++ b/cache_8hpp_source.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1Attachee.html b/classentt_1_1Attachee.html new file mode 100644 index 000000000..95b8ffe61 --- /dev/null +++ b/classentt_1_1Attachee.html @@ -0,0 +1,94 @@ + + + + + + + +EnTT: entt::Attachee<... > Class Template Reference + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.3 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+
entt::Attachee<... > Class Template Reference
+
+
+ +

Attachee. + More...

+ +

#include <attachee.hpp>

+

Detailed Description

+

template<typename...>
+class entt::Attachee<... >

+ +

Attachee.

+

Primary template isn't defined on purpose. All the specializations give a compile-time error, but for a few reasonable cases.

+ +

Definition at line 22 of file attachee.hpp.

+
The documentation for this class was generated from the following file: +
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1Attachee_3_01Entity_00_01Type_01_4-members.html b/classentt_1_1Attachee_3_01Entity_00_01Type_01_4-members.html new file mode 100644 index 000000000..535a49068 --- /dev/null +++ b/classentt_1_1Attachee_3_01Entity_00_01Type_01_4-members.html @@ -0,0 +1,95 @@ + + + + + + + +EnTT: Member List + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.3 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+
entt::Attachee< Entity, Type > Member List
+
+
+ +

This is the complete list of members for entt::Attachee< Entity, Type >, including all inherited members.

+ + + + + + + + + + + + + + + +
Attachee() ENTT_NOEXCEPT=defaultentt::Attachee< Entity, Type >
Attachee(const Attachee &)=deleteentt::Attachee< Entity, Type >
Attachee(Attachee &&)=deleteentt::Attachee< Entity, Type >
construct(entity_type entity, Args &&... args) ENTT_NOEXCEPTentt::Attachee< Entity, Type >inline
entt::Attachee< Entity >::construct(const entity_type entity) ENTT_NOEXCEPTentt::Attachee< Entity >inline
destroy() ENTT_NOEXCEPT overrideentt::Attachee< Entity, Type >inlinevirtual
entity_type typedefentt::Attachee< Entity, Type >
get() const ENTT_NOEXCEPTentt::Attachee< Entity, Type >inline
get() ENTT_NOEXCEPTentt::Attachee< Entity, Type >inline
move(const entity_type entity) ENTT_NOEXCEPTentt::Attachee< Entity, Type >inline
object_type typedefentt::Attachee< Entity, Type >
operator=(const Attachee &)=deleteentt::Attachee< Entity, Type >
operator=(Attachee &&)=deleteentt::Attachee< Entity, Type >
~Attachee()entt::Attachee< Entity, Type >inlinevirtual
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1Attachee_3_01Entity_00_01Type_01_4.html b/classentt_1_1Attachee_3_01Entity_00_01Type_01_4.html new file mode 100644 index 000000000..f865cf463 --- /dev/null +++ b/classentt_1_1Attachee_3_01Entity_00_01Type_01_4.html @@ -0,0 +1,472 @@ + + + + + + + +EnTT: entt::Attachee< Entity, Type > Class Template Reference + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.3 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+Public Types | +Public Member Functions | +List of all members
+
+
entt::Attachee< Entity, Type > Class Template Reference
+
+
+ +

Extended attachee implementation. + More...

+ +

#include <attachee.hpp>

+
+Inheritance diagram for entt::Attachee< Entity, Type >:
+
+
Inheritance graph
+ + + +
[legend]
+
+Collaboration diagram for entt::Attachee< Entity, Type >:
+
+
Collaboration graph
+ + + +
[legend]
+ + + + + + + + + + + + +

+Public Types

+using object_type = Type
 Type of the object associated to the attachee.
 
+using entity_type = typename underlying_type::entity_type
 Underlying entity identifier.
 
- Public Types inherited from entt::Attachee< Entity >
+using entity_type = Entity
 Underlying entity identifier.
 
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+Public Member Functions

+ Attachee () ENTT_NOEXCEPT=default
 Default constructor.
 
+ Attachee (const Attachee &)=delete
 Copying an attachee isn't allowed.
 
+ Attachee (Attachee &&)=delete
 Moving an attachee isn't allowed.
 
Attachee & operator= (const Attachee &)=delete
 Copying an attachee isn't allowed. More...
 
Attachee & operator= (Attachee &&)=delete
 Moving an attachee isn't allowed. More...
 
+ ~Attachee ()
 Default destructor.
 
const Type & get () const ENTT_NOEXCEPT
 Returns the object associated to an attachee. More...
 
Type & get () ENTT_NOEXCEPT
 Returns the object associated to an attachee. More...
 
template<typename... Args>
Type & construct (entity_type entity, Args &&... args) ENTT_NOEXCEPT
 Assigns an entity to an attachee and constructs its object. More...
 
void destroy () ENTT_NOEXCEPT override
 Removes an entity from an attachee and destroies its object. More...
 
void move (const entity_type entity) ENTT_NOEXCEPT
 Changes the owner of an attachee. More...
 
- Public Member Functions inherited from entt::Attachee< Entity >
+ Attachee () ENTT_NOEXCEPT
 Default constructor.
 
+ Attachee (const Attachee &)=default
 Default copy constructor.
 
+ Attachee (Attachee &&)=default
 Default move constructor.
 
Attachee & operator= (const Attachee &)=default
 Default copy assignment operator. More...
 
Attachee & operator= (Attachee &&)=default
 Default move assignment operator. More...
 
entity_type get () const ENTT_NOEXCEPT
 Returns the owner of an attachee. More...
 
void construct (const entity_type entity) ENTT_NOEXCEPT
 Assigns an entity to an attachee. More...
 
+

Detailed Description

+

template<typename Entity, typename Type>
+class entt::Attachee< Entity, Type >

+ +

Extended attachee implementation.

+

This specialization of an attachee associates an object to an entity. The main purpose of this class is to use attachees to store tags in a Registry. It guarantees fast access both to the element and to the entity.

+
See also
Attachee<Entity>
+
Template Parameters
+ + + +
EntityA valid entity type (see entt_traits for more details).
TypeType of object assigned to the entity.
+
+
+ +

Definition at line 112 of file attachee.hpp.

+

Member Function Documentation

+ +

◆ construct()

+ +
+
+
+template<typename Entity , typename Type >
+
+template<typename... Args>
+ + + + + +
+ + + + + + + + + + + + + + + + + + +
Type& entt::Attachee< Entity, Type >::construct (entity_type entity,
Args &&... args 
)
+ 		+inline
+
+ +

Assigns an entity to an attachee and constructs its object.

+
Warning
Attempting to assigns an entity to an attachee that already has an owner results in undefined behavior.
+ An assertion will abort the execution at runtime in debug mode in case the attachee already has an owner.
+
Template Parameters
+ + +
ArgsTypes of arguments to use to construct the object.
+
+
+
Parameters
+ + + +
entityA valid entity identifier.
argsParameters to use to construct an object for the entity.
+
+
+
Returns
The object associated to the attachee.
+ +

Definition at line 185 of file attachee.hpp.

+ +
+
+ +

◆ destroy()

+ +
+
+
+template<typename Entity , typename Type >
+ + + + + +
+ + + + + + + +
void entt::Attachee< Entity, Type >::destroy ()
+ 		+inlineoverridevirtual
+
+ +

Removes an entity from an attachee and destroies its object.

+
Warning
Attempting to free an empty attachee results in undefined behavior.
+ An assertion will abort the execution at runtime in debug mode if the attachee is already empty.
+ +

Reimplemented from entt::Attachee< Entity >.

+ +

Definition at line 199 of file attachee.hpp.

+ +
+
+ +

◆ get() [1/2]

+ +
+
+
+template<typename Entity , typename Type >
+ + + + + +
+ + + + + + + +
const Type& entt::Attachee< Entity, Type >::get () const
+ 		+inline
+
+ +

Returns the object associated to an attachee.

+
Warning
Attempting to query an empty attachee results in undefined behavior.
+ An assertion will abort the execution at runtime in debug mode if the attachee is empty.
+
Returns
The object associated to the attachee.
+ +

Definition at line 151 of file attachee.hpp.

+ +
+
+ +

◆ get() [2/2]

+ +
+
+
+template<typename Entity , typename Type >
+ + + + + +
+ + + + + + + +
Type& entt::Attachee< Entity, Type >::get ()
+ 		+inline
+
+ +

Returns the object associated to an attachee.

+
Warning
Attempting to query an empty attachee results in undefined behavior.
+ An assertion will abort the execution at runtime in debug mode if the attachee is empty.
+
Returns
The object associated to the attachee.
+ +

Definition at line 166 of file attachee.hpp.

+ +
+
+ +

◆ move()

+ +
+
+
+template<typename Entity , typename Type >
+ + + + + +
+ + + + + + + + +
void entt::Attachee< Entity, Type >::move (const entity_type entity)
+ 		+inline
+
+ +

Changes the owner of an attachee.

+

The ownership of the attachee is transferred from one entity to another.

+
Warning
Attempting to transfer the ownership of an attachee that hasn't an owner results in undefined behavior.
+ An assertion will abort the execution at runtime in debug mode in case the attachee hasn't an owner yet.
+
Parameters
+ + +
entityA valid entity identifier.
+
+
+ +

Definition at line 217 of file attachee.hpp.

+ +
+
+ +

◆ operator=() [1/2]

+ +
+
+
+template<typename Entity , typename Type >
+ + + + + +
+ + + + + + + + +
Attachee& entt::Attachee< Entity, Type >::operator= (const Attachee< Entity, Type > & )
+ 		+delete
+
+ +

Copying an attachee isn't allowed.

+
Returns
This attachee.
+ +
+
+ +

◆ operator=() [2/2]

+ +
+
+
+template<typename Entity , typename Type >
+ + + + + +
+ + + + + + + + +
Attachee& entt::Attachee< Entity, Type >::operator= (Attachee< Entity, Type > && )
+ 		+delete
+
+ +

Moving an attachee isn't allowed.

+
Returns
This attachee.
+ +
+
+
The documentation for this class was generated from the following file: +
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1Attachee_3_01Entity_00_01Type_01_4__coll__graph.map b/classentt_1_1Attachee_3_01Entity_00_01Type_01_4__coll__graph.map new file mode 100644 index 000000000..d082ee3e2 --- /dev/null +++ b/classentt_1_1Attachee_3_01Entity_00_01Type_01_4__coll__graph.map @@ -0,0 +1,3 @@ + + + diff --git a/classentt_1_1Attachee_3_01Entity_00_01Type_01_4__coll__graph.md5 b/classentt_1_1Attachee_3_01Entity_00_01Type_01_4__coll__graph.md5 new file mode 100644 index 000000000..8ad7cbd0c --- /dev/null +++ b/classentt_1_1Attachee_3_01Entity_00_01Type_01_4__coll__graph.md5 @@ -0,0 +1 @@ +2fd30cf67acfb8c69efa7822cb51703e \ No newline at end of file diff --git a/classentt_1_1Attachee_3_01Entity_00_01Type_01_4__coll__graph.png b/classentt_1_1Attachee_3_01Entity_00_01Type_01_4__coll__graph.png new file mode 100644 index 0000000000000000000000000000000000000000..c94746720b998a1d4a3c0992f014778e5686d002 GIT binary patch literal 4751 zcmc&&_dndvw_YWP5>_uCgs4mO8a1pMElP+bdh}kB5OuXBBt)+vdW*7%ZuNYK7DP+* zPV{KOcjR^N{o&p};O@S5-?Q_YIWuR@nddyuqI9%WNC@c(ArJ_OnkrluJj=l+kN^*S zXFgT11rI#SM=Eg0_09W3OW}J6gdDC0f2jX5V<*#3NB{VucaDb!%3lus@FC=TWqd+0 zRHHdQSww|6Uml;Bis~SVT=*pmnzqyHT^0FbdMJgCz*=(BgXk~@1JMX zKokGO+%$Tkh=hcM-1g=lDt2|4b1f_`hB(jEeYvmqV3eAMW@&q>MuwUaiBWp~oCAzY zNaA6%mr_+%-<$}dCD!CMYc*N%5G%CVyTf6Ow`-pJUyXH&+#mI>%(&QCt*498Oo!ZL z1n;u5=d7+iTh2Q)#)D@5F>x>kj?mG8JbLtKu$3=E(i6|e$4A0*RiplFz1-T``a^TG zNwK|xAdNx}83u!aIk%7uBA)$-(T6D+7*N@oA%6X6iohpjnm<_Sck}dAbaCP9dCUCC zkhz5pm^4Blwwkjn`FMGG$(WcbMki*5`{SOl#@%IO!@Z{x+ZD~<8rj}1kFKl3wv!8E z=j81C^5r&I$?xRXEr^7a6b>Yul)0jslq}!!w86o zzQLF`ol1&IN)+_;C<;v}rdQiMU8tPX#hg3RL>;YXoSdAx+JkZSXI$GhWS*7Zy#*Fi z?Y689jfi+35rI!dL-Vc0@1*a`7gU|=oYwW&=4ccZPf66jM@McBj_?|7xXAMX+NjuA4%XaEsTZS;pIUkvG`j;#O&L>DQb1ssFOR>QQ8F`Y zL)JIG6?)CLW2K4Mldmi<4}+!bHphz5R=szo8X@aHUd-i(hvTVhX>maG4Gi)HfiIa2 z-dogX=jZXj+qDSmnE<#Dlyd9FCcRQ@Z2OlC6@aNPl!k2Pqq8womVBX}jquZcqARBPL z!Rg`YdC%6?_TcdFeYZH6l6q=@6$CmHe?QWb{p`f3!ewS=b`By`JAFMUJ03G4dR=lr zNk%3g92^XSpmce0Qn(B_C^Rseb+XHCb)*7Z{fN zpbh>oUfzV`-Ps1@kleM2i+=?IzIlMLsX?Q=cs@0UFo?U{m62f-6%~E(Je0wIIq>XY zMO8~n+0v4=Ks!4YdQaKTq%b!Z`($@cMNRE?fktWw77m{Di+_T$__~^#o5?6CLqQJA zwgoarQ{V4c=!~c}uFuH{t}!z-j9BV@Te@ACpPvH^{QUWoR>JK=8SrLdf2r4l=C+9} zJp;qY*ch&rm6eF7sKrp03?%6M+_%iQmXL*o1zZyhI36f1Ef?ov#VWFYb$y*6PBnCS z*;?B7h=77aqkX#8F)lN+e8SMih8+fjC8X7Ht%monZf-`^)rp0Mg;|W37-VdbK`Tre zLTvhzFjG@>;M_JgHco#v?V4Ly4T_q%CYDS9~sV3{LWTR{KW|?C`sRY`aOI7BRMGSD z5&#j8c6Q6G@>8ETHqTw|DJmK+$Gtf5ZcXEr{njSW3iYRs!r@w;_Aj zL#tHtN^0$iK~`j>nA4;@04IGz!$Kh@)?ClE!MNyXqD)!;G-CupvezEx`;q+KP;8&7 zhDK;%AtxoZFflIlAuO?@udi=7$9!!tlZ%(Pt5~m4qF0rToR(p0?RTJxeXeC{8HR~Z z0IhhJjMk*`{{8!0_wRS3C^+5DkL+u$j@ga8k5JP%$|oL&tD4RGJq)LNouq<}6TFHM zov~=*uLCK9INDj#f?l*jlW|EHsT4c9W+duwqX`uiW&9OMYZ`K>z$++N#ksWZ`TAnV z>ZNZiCJ1ZWxV|(YA)zS1r0f)(vxK5`GPWnD3-T8>0Wb@13`9Ed8j^8WnMPt9(|8Gamm-)qdy1N&;P!xM7C%qTDZFBcz zZHKaAPETJ>PEOh}&Bh42#igZ{e5+G`^k`vcr~J@Y=HVyF(WJygi;dCz41ZHH6uh#o zE?kvuQ;fMK5!8*ll9EsV5*;KSNl0>XvU+;XhG;H3>)6DE$M4#ew{lnVj~_!rLPFl9 zr$@)fleb)~e4GS z{zUJ`B_-j>$;t5=RYJ0|vZ_BO=)=0}=K_edwY5JtHQkez{wF3T#-p{Sre0Z6r zO&KkSnw~aBqtR~DqB+htSTsUSMHLnqNiZdro}ON1j=^4DS@D+SGhL@1;b3F?ke7$6 z68q0XYiqWE>&q8iU0r?KtZ@VpcNjZ*Vi=$d4AB73UmuSfLV^H-VFl?j+sQ?3PgWso z=BjoiJy#)+=L0D$oW`26Su%d%m6ZY#5)yZ1Wtp}n%5ON?=GGPffv0)-`4-n#ml7}c z?nXsNyKjzhOU}{J(Mk9oamk)7Q*`z8m5lps~!GTn^bJ3clzul6cvXn1O) zHxO6w=Y{f!7~rRQg@uZ+L~O|Dw{I3!R!H}y9`~Mn?Zy>_?a};460c7M!tXE=0t$M1 zaj~@ZsV!+Lna?yT7zf|->d#qZWTd>mf6J2@QE~BJsomzzsld}c78nnYATSIGDlO$% zTwK&KG9vKv^NX1g7Ztq$R&yJhu&c`ptI0}>zs2nj092!TmrN%qz>7~0hvZf!PL7U3 zQ&Z^*v|R&V&kPR-u_%TYeT{gKZp7PD>-ha$d^|P^9s>A@`QhqU0b${#S$q)H#D1y3 zS50ZxcQ`cDZVKpZgD1XTfd*#0)KJj%r*vlBzO+}g9S;vrmD7|^gAGW}_)BLC3oM9$ zkkDwUS)3}{g`3p-w6rKN!O>)Ha*~#ciYoHW8@Qg{`;1{87|h(!k!R~Iy(r;F<(POx zn^hYwcJQo+_t|{4jjgTKT&sV|18gwu@+5%dpy~9Zu!VS&*4Sd2%Ch@1`-VGX-XI_B&r=_I@ z1dGQEqg;Trle6;;rj7K@V~|zPztZ2(qT|i+%Bm_1$QdXlC9bQhYxCJ^IsqY}g1PzK zva+)I-QDZiv*83DkjPFy8mS7kGDBKgWMnUo^!{9)%w@Dw8}5IZE*I)mVy8m z_=pF>y0Ezk6PIOW#Rhbe-rt7`3mVsm1!(Ht(b0CIw(?ap88os8QDD^Q@#oY%AvyUT z8yno^49HaXt3R)r_d19kIP;5$P$nfM(Qi4Bw5<_mk`dtI(UckSDnETn$7k9YsuWGl zJ;lh#=uKV5Com%9wTeOF-+*~X7?I$s18a6aAU^BQci-OXK4&z(8 zdU{Z5>K^;IC=_P0%F0iGHJnugP1t-qfvEOHR#yw*;^OuhsFBbKb?M{?UIn9`VCm`U zrKF`{pPsbli5cj=$wHb&ZbUW`7RLTt1hVh+{Ji7G55~B-II`$&2>R2y?@#rL);kpC zv37b32^kr0Kp`exSXk)$_umd6%&_dtMiN2ZlFFV!07i|U7taLV<}ha5Fj>Hrw+Z_O zLJ4jh5x7jJXJ-qWLy3l9%b(~I360RAkA>QGQROq+bF z5H98_(|jY37mk2Tff-0(wF7}1vollwvAFoQ=jy=C&alviUP>w|_XGsUEURe06=>=` zz4QUQWn*J&2geMIhF1w*q&(=X&cS0~U>Mx21Cj3pSOZA1dR-V1jpaf|n0mjah6WiK zSx`_Aq&A>XGri!TzuhiElhg~Y7xrFu_{34wp9CEGW5We&7nh2o0D8si%8lUIqEa_< z!m!CkZ%0y#DZm4_r5=)&TixbGR?B^H zZtm`nrIbI~(Y^VJm;O!YB|gP{ + + diff --git a/classentt_1_1Attachee_3_01Entity_00_01Type_01_4__inherit__graph.md5 b/classentt_1_1Attachee_3_01Entity_00_01Type_01_4__inherit__graph.md5 new file mode 100644 index 000000000..42196e769 --- /dev/null +++ b/classentt_1_1Attachee_3_01Entity_00_01Type_01_4__inherit__graph.md5 @@ -0,0 +1 @@ +cd0c4f7a89b236495fb5929f2aa13015 \ No newline at end of file diff --git a/classentt_1_1Attachee_3_01Entity_00_01Type_01_4__inherit__graph.png b/classentt_1_1Attachee_3_01Entity_00_01Type_01_4__inherit__graph.png new file mode 100644 index 0000000000000000000000000000000000000000..c94746720b998a1d4a3c0992f014778e5686d002 GIT binary patch literal 4751 zcmc&&_dndvw_YWP5>_uCgs4mO8a1pMElP+bdh}kB5OuXBBt)+vdW*7%ZuNYK7DP+* zPV{KOcjR^N{o&p};O@S5-?Q_YIWuR@nddyuqI9%WNC@c(ArJ_OnkrluJj=l+kN^*S zXFgT11rI#SM=Eg0_09W3OW}J6gdDC0f2jX5V<*#3NB{VucaDb!%3lus@FC=TWqd+0 zRHHdQSww|6Uml;Bis~SVT=*pmnzqyHT^0FbdMJgCz*=(BgXk~@1JMX zKokGO+%$Tkh=hcM-1g=lDt2|4b1f_`hB(jEeYvmqV3eAMW@&q>MuwUaiBWp~oCAzY zNaA6%mr_+%-<$}dCD!CMYc*N%5G%CVyTf6Ow`-pJUyXH&+#mI>%(&QCt*498Oo!ZL z1n;u5=d7+iTh2Q)#)D@5F>x>kj?mG8JbLtKu$3=E(i6|e$4A0*RiplFz1-T``a^TG zNwK|xAdNx}83u!aIk%7uBA)$-(T6D+7*N@oA%6X6iohpjnm<_Sck}dAbaCP9dCUCC zkhz5pm^4Blwwkjn`FMGG$(WcbMki*5`{SOl#@%IO!@Z{x+ZD~<8rj}1kFKl3wv!8E z=j81C^5r&I$?xRXEr^7a6b>Yul)0jslq}!!w86o zzQLF`ol1&IN)+_;C<;v}rdQiMU8tPX#hg3RL>;YXoSdAx+JkZSXI$GhWS*7Zy#*Fi z?Y689jfi+35rI!dL-Vc0@1*a`7gU|=oYwW&=4ccZPf66jM@McBj_?|7xXAMX+NjuA4%XaEsTZS;pIUkvG`j;#O&L>DQb1ssFOR>QQ8F`Y zL)JIG6?)CLW2K4Mldmi<4}+!bHphz5R=szo8X@aHUd-i(hvTVhX>maG4Gi)HfiIa2 z-dogX=jZXj+qDSmnE<#Dlyd9FCcRQ@Z2OlC6@aNPl!k2Pqq8womVBX}jquZcqARBPL z!Rg`YdC%6?_TcdFeYZH6l6q=@6$CmHe?QWb{p`f3!ewS=b`By`JAFMUJ03G4dR=lr zNk%3g92^XSpmce0Qn(B_C^Rseb+XHCb)*7Z{fN zpbh>oUfzV`-Ps1@kleM2i+=?IzIlMLsX?Q=cs@0UFo?U{m62f-6%~E(Je0wIIq>XY zMO8~n+0v4=Ks!4YdQaKTq%b!Z`($@cMNRE?fktWw77m{Di+_T$__~^#o5?6CLqQJA zwgoarQ{V4c=!~c}uFuH{t}!z-j9BV@Te@ACpPvH^{QUWoR>JK=8SrLdf2r4l=C+9} zJp;qY*ch&rm6eF7sKrp03?%6M+_%iQmXL*o1zZyhI36f1Ef?ov#VWFYb$y*6PBnCS z*;?B7h=77aqkX#8F)lN+e8SMih8+fjC8X7Ht%monZf-`^)rp0Mg;|W37-VdbK`Tre zLTvhzFjG@>;M_JgHco#v?V4Ly4T_q%CYDS9~sV3{LWTR{KW|?C`sRY`aOI7BRMGSD z5&#j8c6Q6G@>8ETHqTw|DJmK+$Gtf5ZcXEr{njSW3iYRs!r@w;_Aj zL#tHtN^0$iK~`j>nA4;@04IGz!$Kh@)?ClE!MNyXqD)!;G-CupvezEx`;q+KP;8&7 zhDK;%AtxoZFflIlAuO?@udi=7$9!!tlZ%(Pt5~m4qF0rToR(p0?RTJxeXeC{8HR~Z z0IhhJjMk*`{{8!0_wRS3C^+5DkL+u$j@ga8k5JP%$|oL&tD4RGJq)LNouq<}6TFHM zov~=*uLCK9INDj#f?l*jlW|EHsT4c9W+duwqX`uiW&9OMYZ`K>z$++N#ksWZ`TAnV z>ZNZiCJ1ZWxV|(YA)zS1r0f)(vxK5`GPWnD3-T8>0Wb@13`9Ed8j^8WnMPt9(|8Gamm-)qdy1N&;P!xM7C%qTDZFBcz zZHKaAPETJ>PEOh}&Bh42#igZ{e5+G`^k`vcr~J@Y=HVyF(WJygi;dCz41ZHH6uh#o zE?kvuQ;fMK5!8*ll9EsV5*;KSNl0>XvU+;XhG;H3>)6DE$M4#ew{lnVj~_!rLPFl9 zr$@)fleb)~e4GS z{zUJ`B_-j>$;t5=RYJ0|vZ_BO=)=0}=K_edwY5JtHQkez{wF3T#-p{Sre0Z6r zO&KkSnw~aBqtR~DqB+htSTsUSMHLnqNiZdro}ON1j=^4DS@D+SGhL@1;b3F?ke7$6 z68q0XYiqWE>&q8iU0r?KtZ@VpcNjZ*Vi=$d4AB73UmuSfLV^H-VFl?j+sQ?3PgWso z=BjoiJy#)+=L0D$oW`26Su%d%m6ZY#5)yZ1Wtp}n%5ON?=GGPffv0)-`4-n#ml7}c z?nXsNyKjzhOU}{J(Mk9oamk)7Q*`z8m5lps~!GTn^bJ3clzul6cvXn1O) zHxO6w=Y{f!7~rRQg@uZ+L~O|Dw{I3!R!H}y9`~Mn?Zy>_?a};460c7M!tXE=0t$M1 zaj~@ZsV!+Lna?yT7zf|->d#qZWTd>mf6J2@QE~BJsomzzsld}c78nnYATSIGDlO$% zTwK&KG9vKv^NX1g7Ztq$R&yJhu&c`ptI0}>zs2nj092!TmrN%qz>7~0hvZf!PL7U3 zQ&Z^*v|R&V&kPR-u_%TYeT{gKZp7PD>-ha$d^|P^9s>A@`QhqU0b${#S$q)H#D1y3 zS50ZxcQ`cDZVKpZgD1XTfd*#0)KJj%r*vlBzO+}g9S;vrmD7|^gAGW}_)BLC3oM9$ zkkDwUS)3}{g`3p-w6rKN!O>)Ha*~#ciYoHW8@Qg{`;1{87|h(!k!R~Iy(r;F<(POx zn^hYwcJQo+_t|{4jjgTKT&sV|18gwu@+5%dpy~9Zu!VS&*4Sd2%Ch@1`-VGX-XI_B&r=_I@ z1dGQEqg;Trle6;;rj7K@V~|zPztZ2(qT|i+%Bm_1$QdXlC9bQhYxCJ^IsqY}g1PzK zva+)I-QDZiv*83DkjPFy8mS7kGDBKgWMnUo^!{9)%w@Dw8}5IZE*I)mVy8m z_=pF>y0Ezk6PIOW#Rhbe-rt7`3mVsm1!(Ht(b0CIw(?ap88os8QDD^Q@#oY%AvyUT z8yno^49HaXt3R)r_d19kIP;5$P$nfM(Qi4Bw5<_mk`dtI(UckSDnETn$7k9YsuWGl zJ;lh#=uKV5Com%9wTeOF-+*~X7?I$s18a6aAU^BQci-OXK4&z(8 zdU{Z5>K^;IC=_P0%F0iGHJnugP1t-qfvEOHR#yw*;^OuhsFBbKb?M{?UIn9`VCm`U zrKF`{pPsbli5cj=$wHb&ZbUW`7RLTt1hVh+{Ji7G55~B-II`$&2>R2y?@#rL);kpC zv37b32^kr0Kp`exSXk)$_umd6%&_dtMiN2ZlFFV!07i|U7taLV<}ha5Fj>Hrw+Z_O zLJ4jh5x7jJXJ-qWLy3l9%b(~I360RAkA>QGQROq+bF z5H98_(|jY37mk2Tff-0(wF7}1vollwvAFoQ=jy=C&alviUP>w|_XGsUEURe06=>=` zz4QUQWn*J&2geMIhF1w*q&(=X&cS0~U>Mx21Cj3pSOZA1dR-V1jpaf|n0mjah6WiK zSx`_Aq&A>XGri!TzuhiElhg~Y7xrFu_{34wp9CEGW5We&7nh2o0D8si%8lUIqEa_< z!m!CkZ%0y#DZm4_r5=)&TixbGR?B^H zZtm`nrIbI~(Y^VJm;O!YB|gP{ + + + + + + +EnTT: Member List + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.3 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+
entt::Attachee< Entity > Member List
+
+
+ +

This is the complete list of members for entt::Attachee< Entity >, including all inherited members.

+ + + + + + + + + + + +
Attachee() ENTT_NOEXCEPTentt::Attachee< Entity >inline
Attachee(const Attachee &)=defaultentt::Attachee< Entity >
Attachee(Attachee &&)=defaultentt::Attachee< Entity >
construct(const entity_type entity) ENTT_NOEXCEPTentt::Attachee< Entity >inline
destroy() ENTT_NOEXCEPTentt::Attachee< Entity >inlinevirtual
entity_type typedefentt::Attachee< Entity >
get() const ENTT_NOEXCEPTentt::Attachee< Entity >inline
operator=(const Attachee &)=defaultentt::Attachee< Entity >
operator=(Attachee &&)=defaultentt::Attachee< Entity >
~Attachee() ENTT_NOEXCEPT=defaultentt::Attachee< Entity >virtual
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1Attachee_3_01Entity_01_4.html b/classentt_1_1Attachee_3_01Entity_01_4.html new file mode 100644 index 000000000..741967c57 --- /dev/null +++ b/classentt_1_1Attachee_3_01Entity_01_4.html @@ -0,0 +1,324 @@ + + + + + + + +EnTT: entt::Attachee< Entity > Class Template Reference + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.3 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+Public Types | +Public Member Functions | +List of all members
+
+
entt::Attachee< Entity > Class Template Reference
+
+
+ +

Basic attachee implementation. + More...

+ +

#include <attachee.hpp>

+
+Inheritance diagram for entt::Attachee< Entity >:
+
+
Inheritance graph
+ + + +
[legend]
+ + + + + +

+Public Types

+using entity_type = Entity
 Underlying entity identifier.
 
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+Public Member Functions

+ Attachee () ENTT_NOEXCEPT
 Default constructor.
 
+ Attachee (const Attachee &)=default
 Default copy constructor.
 
+ Attachee (Attachee &&)=default
 Default move constructor.
 
Attachee & operator= (const Attachee &)=default
 Default copy assignment operator. More...
 
Attachee & operator= (Attachee &&)=default
 Default move assignment operator. More...
 
+virtual ~Attachee () ENTT_NOEXCEPT=default
 Default destructor.
 
entity_type get () const ENTT_NOEXCEPT
 Returns the owner of an attachee. More...
 
void construct (const entity_type entity) ENTT_NOEXCEPT
 Assigns an entity to an attachee. More...
 
virtual void destroy () ENTT_NOEXCEPT
 Removes an entity from an attachee. More...
 
+

Detailed Description

+

template<typename Entity>
+class entt::Attachee< Entity >

+ +

Basic attachee implementation.

+

Convenience data structure used to store single instance components.

+
Template Parameters
+ + +
EntityA valid entity type (see entt_traits for more details).
+
+
+ +

Definition at line 33 of file attachee.hpp.

+

Member Function Documentation

+ +

◆ construct()

+ +
+
+
+template<typename Entity >
+ + + + + +
+ + + + + + + + +
void entt::Attachee< Entity >::construct (const entity_type entity)
+ 		+inline
+
+ +

Assigns an entity to an attachee.

+
Warning
Attempting to assigns an entity to an attachee that already has an owner results in undefined behavior.
+ An assertion will abort the execution at runtime in debug mode in case the attachee already has an owner.
+
Parameters
+ + +
entityA valid entity identifier.
+
+
+ +

Definition at line 76 of file attachee.hpp.

+ +
+
+ +

◆ destroy()

+ +
+
+
+template<typename Entity >
+ + + + + +
+ + + + + + + +
virtual void entt::Attachee< Entity >::destroy ()
+ 		+inlinevirtual
+
+ +

Removes an entity from an attachee.

+
Warning
Attempting to free an empty attachee results in undefined behavior.
+ An assertion will abort the execution at runtime in debug mode if the attachee is already empty.
+ +

Reimplemented in entt::Attachee< Entity, Type >.

+ +

Definition at line 89 of file attachee.hpp.

+ +
+
+ +

◆ get()

+ +
+
+
+template<typename Entity >
+ + + + + +
+ + + + + + + +
entity_type entt::Attachee< Entity >::get () const
+ 		+inline
+
+ +

Returns the owner of an attachee.

+
Returns
A valid entity identifier if an owner exists, the null entity identifier otherwise.
+ +

Definition at line 61 of file attachee.hpp.

+ +
+
+ +

◆ operator=() [1/2]

+ +
+
+
+template<typename Entity >
+ + + + + +
+ + + + + + + + +
Attachee& entt::Attachee< Entity >::operator= (const Attachee< Entity > & )
+ 		+default
+
+ +

Default copy assignment operator.

+
Returns
This attachee.
+ +
+
+ +

◆ operator=() [2/2]

+ +
+
+
+template<typename Entity >
+ + + + + +
+ + + + + + + + +
Attachee& entt::Attachee< Entity >::operator= (Attachee< Entity > && )
+ 		+default
+
+ +

Default move assignment operator.

+
Returns
This attachee.
+ +
+
+
The documentation for this class was generated from the following file: +
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1Attachee_3_01Entity_01_4__inherit__graph.map b/classentt_1_1Attachee_3_01Entity_01_4__inherit__graph.map new file mode 100644 index 000000000..ef4fa59fd --- /dev/null +++ b/classentt_1_1Attachee_3_01Entity_01_4__inherit__graph.map @@ -0,0 +1,3 @@ + + + diff --git a/classentt_1_1Attachee_3_01Entity_01_4__inherit__graph.md5 b/classentt_1_1Attachee_3_01Entity_01_4__inherit__graph.md5 new file mode 100644 index 000000000..a89cd2b56 --- /dev/null +++ b/classentt_1_1Attachee_3_01Entity_01_4__inherit__graph.md5 @@ -0,0 +1 @@ +8c21d26f3e6d0119d1531c2ad74b3eaf \ No newline at end of file diff --git a/classentt_1_1Attachee_3_01Entity_01_4__inherit__graph.png b/classentt_1_1Attachee_3_01Entity_01_4__inherit__graph.png new file mode 100644 index 0000000000000000000000000000000000000000..67ca68fa01a4412d8e5b2b438cead017de118a0e GIT binary patch literal 4768 zcmd6rhf|YHyT$_|9WgZNp%W=e??oU~kq!bP(g{tFX6Ps_geC}xbVBb{n$p_~C>VMX zL{ZvHks`gE<;*u{&iN0{WRmP8Pj)A}*LB^$`-#@mQKukfB!xgA6q*_c1Mpr6o*~49 z;5Exk*%7=E+B{T8K(4MIxoyR7ArLBKO@xvWDswB#PmgB$aG-Z0__PlQ$ErXxJj(BGa)C(DS|3|37?n- z!4|q%_vQ1+MOOkz{peEXSCpc06J~zZH)lNRzI@YJHY*B&uo9B$WeXzev_g_m3x;_K z;Y6f}t_So(&;R-7pUzh|hz_7+VeC;cF=Pr?=U%05o>)Oa!M+x+)uok{DaTjB^q7B! zhYg#b>NGqJkBmGt5g?CLgO9UijQ?k%|Ctfq23@A&)y+n@x(b|MTcCvUw#j| zv%9-n)6lR<9WrF2r{?TjW-{P^xXBP07}&6=3tQXLdSYoA&;2kJzU313fGxD8MVbI# zsrqECnpwu1cyMsg^ASs33%!IZ{in7z+PPCEe`-N!UVFQx(=)?tg&<5)5*5MCo9v2; zFnfD@nIl||u&{6!8p`=AUB=E!IPln`;z^TEUS&rfH4cN|=PzI+;><5Mp9t2qf?Tr%rnIU{&4ZDB;1Z!dJhPEEylZ%&aVH zH#fn*yG79n4Gm%yX7z;otD{lx-o5+9$4wXW;{5mp%FoYweXJ0TMnCZKs!!gjs1P_l zInm5|*BV$-cNg2<&g$mornR;4RqSfPi{B+CKE8jkEr5H#)y=K%{A6EWPcL^LC9cGa zeWb08Ff(Jg#Uc}4QUX6eSqQ#K+^{Y79opP1B_<*9GYS?Afn+L%utI*F zK3Fxjn{RZ}I(s^BIT~_#1Cl20lA4U1JVEXLyxHB|ZRPHsaD0rac-Fy+!{LywuD#%> z-=wBS$_E@S0Xe|I;g=c~7X&)m*)9E($T`yVH{&#zy<=1RaeJSY2>2NG%>M_DT@ zS`4-m3S}!RD@ik4<0pQ1$ks_nN=g*qIqq*Tqi^MMXt5H8pQ~U!LsQ zS6H?&N=Qi5eE6X1;UUD#!cus6w72)VwpQ3-B$EV!bapn#pfqlbkH2N{(U$@b4{xR; zL=jx}V&yYKEVH!1y7cwYlF7iLgFq_58o^|ZET-~QHe0|tW)Ue?)cDH|&!&&tTiSlQZ!efwsiohF25+aH^F z+7rUyop?1{@5m`9$2>JP1@;)D_OraQQdLuvq^zuLX=y2R+A?6Pa2et)Chzg`<-m`g zD18tX*On(D;?Ly2i!Cfvb-L<{xkCjVJcP-iLg(hpn?HW+0g4#=wy>aYV#4F|Hutmo z!-r&Z^YhkLR-uiJ61{zWn&+RhWbc5afb;PwgVn&ki)H7R4n>K~AMY-|Sn9+JkBZ7~ zXrO6tZ=Y#$hwbg}8=sbym#etBRa%VG%zlH{OG`^D3D7O~MpJ7Q6Fyk&;}R96{vNnb zfsc>RMi&ERVTr5mxMb{!qMVkxXS{}J;5Vtb&NloTH)@^6c}&gBta~CU_>O98YC`k# z^MBnkZlv_SRBrwL!FPv@0AEU0wx_ojvC&M;s}r7*LTg}XIC+X%j+3nM-7*i4h_D8# z0ioKPDeZNehK2xawRVOCg_4pIF*$ko`}YjMP|sw5VeP@5k1Cvz7wcrbj*Fx4-I|N& zxVn5&S{=tE*$w1bRjQ)jZaj;UV|DnF9^vl<^kz_F2XH?@&j)|Z@?mKNw=Uq+3KYJGE&8z>`C0p>WG zoibN-r7dLCy}WyHZwA;c`Q5wap%i}8W{1qBAtL~C`g|T z+00k^LOp9wGcz+i*2lPmqS#+Obz;a2i%#v5PD5S~8sC+ayBI5?ah%DE=!NDN`IJ5M zD2t9u{CbDB_^vS8`+r3y42_KoJz7jlkuSIACd=_C>|+Uw|-&si}?K zr6pC>&}c3%MicUY$+@IY6l7!ya@eSRp1vCXOY`5?s>`ADFjy=fWG|sDE|%P5*T&>K zk@y2^>?HKgeFy75R()i#EG!&cJeRt~JC_|pLbwe`ZJNjSx1fe5{wx3dj;rS&Bl?2w zOh6)|O^Cj=ozYBAmOXBd1#|tte}epa6Rga}%}oZO3?pLlbs;neN<_a&O1hb+SFz(E zO&OrBO{D!^gpi$m%)RvTs6)|q-M~>hTi_x^)yL<)kaP0$cIg%42xGs$RH>;sKmJ%N z3RqTLH9aO`boK9C0((Y2(uElQ|1w}Lhy<=vUR4~hc@%S49rA^plT);9pzFiR`g*BO zQo-((g@(5Fgf~14#|etCIAd`w^49thUy3HA&!YHI51>}y!h2;T2_(PtwJQYqz7oST=I2$-mMvi$Ln?d|yU z^FZxPDg9!FQ&C{Um6a9q9o`HwLqkIZ0s#lVwQLz9jZh8`54YN!sil|pgqQj2o9*SiV9#Q3Q)!9-(yFR>8yg#9$mGO?o|4k5WZ0|%R6i(4zOT0z zzC{gjhG9havuKbMzDAo3xXnTK2R z>V`$yd7xqq4G!k5j~9xv8z5z?wppE1*|f^gSrH@#NiyXaonNyuTO;0X_$Z zd9w%m)@;4HlSMkV6d7Qz^Tgbo6o6f+8xIdpQV!@D@F0a{oifwBMkPnbB{R_gmA? zLLw3pD6cEQ+8PoRwMTB}5IsG;P!ejM66XE76POtCww#>Yo6JmdUS3{{j$oE3O4v58 z*8f+Br|8$O@%2_yn06m^K!7b{H#)C>%$fMapsK%AZh?ndjy&y#UD{cjyMF zbIu)!?5wpNpg9~L8`Cp0BLStGoJGcH40JcUzXqvGGYISz(lat}00UK2R2mu@tX4;| zAff&JYR9Li99&!kEiElzRuwC&++=h>I;Fh?*al((d@f$z<=y3hG%+Wtsmdo&01#8! z0Yrf%?oNxTN=Od5R#jEqjz$oZk%d)PS5GwC4#el>3MPqIv__R~fxk|xbq`^>qfjXttnZ zhu^+K^{L}y^T?^s>EdMK;^O}Mqg4$eTs%Bw6{$lbBU3NY)pDC!{5_x*gO_6X`1oGO z#Kah-ByV=#%-^xbrgY8B(D(QELoWU9&Au(WtG3fsL}ZRF>n<%9*#ODq;q845ZPy_@ zHAVPfA5-AvW6#tS-F%b#G-`4yMR{REMc1U4kQBrB z#mHF7CvJ3bFfkUGwIG_Bmnv}sbI&YWK0pm(XVqb=1Iho36y$iwLrP7C*x>FfJef*t4bO3_ RF1Y0c(NxtzR4H4%{x6~Z5BLB8 literal 0 HcmV?d00001 diff --git a/classentt_1_1ContinuousLoader-members.html b/classentt_1_1ContinuousLoader-members.html index 972d2f3b7..53c15591f 100644 --- a/classentt_1_1ContinuousLoader-members.html +++ b/classentt_1_1ContinuousLoader-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1ContinuousLoader.html b/classentt_1_1ContinuousLoader.html index 531379873..da9dc4cbc 100644 --- a/classentt_1_1ContinuousLoader.html +++ b/classentt_1_1ContinuousLoader.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -147,7 +147,7 @@ class entt::ContinuousLoader< Entity > -

Definition at line 430 of file snapshot.hpp.

+

Definition at line 434 of file snapshot.hpp.

Constructor & Destructor Documentation

◆ ContinuousLoader()

@@ -183,7 +183,7 @@ template<typename Entity > -

Definition at line 529 of file snapshot.hpp.

+

Definition at line 533 of file snapshot.hpp.

@@ -247,7 +247,7 @@ template<typename... Component, typename Archive , typename... Type, typename
Returns
A non-const reference to this loader.
-

Definition at line 595 of file snapshot.hpp.

+

Definition at line 599 of file snapshot.hpp.

@@ -295,7 +295,7 @@ template<typename Archive >
Returns
A non-const reference to this loader.
-

Definition at line 570 of file snapshot.hpp.

+

Definition at line 574 of file snapshot.hpp.

@@ -343,7 +343,7 @@ template<typename Archive >
Returns
A non-const reference to this loader.
-

Definition at line 554 of file snapshot.hpp.

+

Definition at line 558 of file snapshot.hpp.

@@ -382,7 +382,7 @@ template<typename Entity >
Returns
True if entity is managed by the loader, false otherwise.
-

Definition at line 690 of file snapshot.hpp.

+

Definition at line 694 of file snapshot.hpp.

@@ -423,7 +423,7 @@ template<typename Entity >
Returns
The identifier to which entity refers in the target registry.
-

Definition at line 706 of file snapshot.hpp.

+

Definition at line 710 of file snapshot.hpp.

@@ -519,7 +519,7 @@ template<typename Entity > This functions helps to identify and destroy those entities.

Returns
A non-const reference to this loader.
-

Definition at line 677 of file snapshot.hpp.

+

Definition at line 681 of file snapshot.hpp.

@@ -552,7 +552,7 @@ template<typename Entity >

Users should invoke this member function after restoring each snapshot, unless they know exactly what they are doing.

Returns
A non-const reference to this loader.
-

Definition at line 645 of file snapshot.hpp.

+

Definition at line 649 of file snapshot.hpp.

@@ -615,7 +615,7 @@ template<typename... Tag, typename Archive , typename... Type, typename... Me
Returns
A non-const reference to this loader.
-

Definition at line 626 of file snapshot.hpp.

+

Definition at line 630 of file snapshot.hpp.

diff --git a/classentt_1_1Delegate.html b/classentt_1_1Delegate.html index c14f27c1a..5386e438f 100644 --- a/classentt_1_1Delegate.html +++ b/classentt_1_1Delegate.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1Delegate_3_01Ret_07Args_8_8_8_08_4-members.html b/classentt_1_1Delegate_3_01Ret_07Args_8_8_8_08_4-members.html index 7d4a19679..82ab9e5d2 100644 --- a/classentt_1_1Delegate_3_01Ret_07Args_8_8_8_08_4-members.html +++ b/classentt_1_1Delegate_3_01Ret_07Args_8_8_8_08_4-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -72,11 +72,12 @@ $(function() { - - - - - + + + + + +
connect() ENTT_NOEXCEPTentt::Delegate< Ret(Args...)>inline
connect(Class *instance) ENTT_NOEXCEPTentt::Delegate< Ret(Args...)>inline
Delegate() ENTT_NOEXCEPTentt::Delegate< Ret(Args...)>inline
empty() const ENTT_NOEXCEPTentt::Delegate< Ret(Args...)>inline
operator()(Args... args) constentt::Delegate< Ret(Args...)>inline
operator==(const Delegate< Ret(Args...)> &other) const ENTT_NOEXCEPTentt::Delegate< Ret(Args...)>inline
reset() ENTT_NOEXCEPTentt::Delegate< Ret(Args...)>inline
connect(Class *instance) ENTT_NOEXCEPTentt::Delegate< Ret(Args...)>inline
Delegate() ENTT_NOEXCEPTentt::Delegate< Ret(Args...)>inline
empty() const ENTT_NOEXCEPTentt::Delegate< Ret(Args...)>inline
operator()(Args... args) constentt::Delegate< Ret(Args...)>inline
operator==(const Delegate< Ret(Args...)> &other) const ENTT_NOEXCEPTentt::Delegate< Ret(Args...)>inline
reset() ENTT_NOEXCEPTentt::Delegate< Ret(Args...)>inline
diff --git a/classentt_1_1Delegate_3_01Ret_07Args_8_8_8_08_4.html b/classentt_1_1Delegate_3_01Ret_07Args_8_8_8_08_4.html index 08b2f0166..6329d37c6 100644 --- a/classentt_1_1Delegate_3_01Ret_07Args_8_8_8_08_4.html +++ b/classentt_1_1Delegate_3_01Ret_07Args_8_8_8_08_4.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -89,6 +89,10 @@ Public Member Functions void connect () ENTT_NOEXCEPT  Binds a free function to a delegate. More...
  +template<typename Class , Ret(Class::*)(Args...) const Member> +void connect (Class *instance) ENTT_NOEXCEPT + Connects a member function for a given instance to a delegate. More...
+  template<typename Class , Ret(Class::*)(Args...) Member> void connect (Class *instance) ENTT_NOEXCEPT  Connects a member function for a given instance to a delegate. More...
@@ -121,7 +125,7 @@ class entt::Delegate< Ret(Args...)>

Definition at line 36 of file delegate.hpp.

Member Function Documentation

-

◆ connect() [1/2]

+

◆ connect() [1/3]

@@ -155,12 +159,60 @@ template<Ret(*)(Args...) Function>
-

Definition at line 70 of file delegate.hpp.

+

Definition at line 75 of file delegate.hpp.

-

◆ connect() [2/2]

+

◆ connect() [2/3]

+ +
+
+
+template<typename Ret , typename... Args>
+
+template<typename Class , Ret(Class::*)(Args...) const Member>
+ + + + + +
+ + + + + + + + +
void entt::Delegate< Ret(Args...)>::connect (Class * instance)
+ 		+inline
+
+ +

Connects a member function for a given instance to a delegate.

+

The delegate isn't responsible for the connected object. Users must guarantee that the lifetime of the instance overcomes the one of the delegate.

+
Template Parameters
+ + + +
ClassType of class to which the member function belongs.
MemberMember function to connect to the delegate.
+
+
+
Parameters
+ + +
instanceA valid instance of type pointer to Class.
+
+
+ +

Definition at line 91 of file delegate.hpp.

+ +
+
+ +

◆ connect() [3/3]

@@ -203,7 +255,7 @@ template<typename Class , Ret(Class::*)(Args...) Member>
-

Definition at line 86 of file delegate.hpp.

+

Definition at line 107 of file delegate.hpp.

@@ -235,7 +287,7 @@ template<typename Ret , typename... Args>

Checks whether a delegate actually stores a listener.

Returns
True if the delegate is empty, false otherwise.
-

Definition at line 60 of file delegate.hpp.

+

Definition at line 65 of file delegate.hpp.

@@ -274,7 +326,7 @@ template<typename Ret , typename... Args>
Returns
The value returned by the underlying function.
-

Definition at line 104 of file delegate.hpp.

+

Definition at line 125 of file delegate.hpp.

@@ -314,7 +366,7 @@ template<typename Ret , typename... Args>
Returns
True if the two delegates are identical, false otherwise.
-

Definition at line 116 of file delegate.hpp.

+

Definition at line 137 of file delegate.hpp.

@@ -346,7 +398,7 @@ template<typename Ret , typename... Args>

Resets a delegate.

After a reset, a delegate can be safely invoked with no effect.

-

Definition at line 95 of file delegate.hpp.

+

Definition at line 116 of file delegate.hpp.

diff --git a/classentt_1_1Dispatcher-members.html b/classentt_1_1Dispatcher-members.html index af5735ae8..2313612b8 100644 --- a/classentt_1_1Dispatcher-members.html +++ b/classentt_1_1Dispatcher-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1Dispatcher.html b/classentt_1_1Dispatcher.html index d95adf49a..18f218e76 100644 --- a/classentt_1_1Dispatcher.html +++ b/classentt_1_1Dispatcher.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1Emitter-members.html b/classentt_1_1Emitter-members.html index b25ef2391..dfcc1e0a8 100644 --- a/classentt_1_1Emitter-members.html +++ b/classentt_1_1Emitter-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1Emitter.html b/classentt_1_1Emitter.html index 1b6320154..08b01544a 100644 --- a/classentt_1_1Emitter.html +++ b/classentt_1_1Emitter.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1Family-members.html b/classentt_1_1Family-members.html index 1fd684b40..894203000 100644 --- a/classentt_1_1Family-members.html +++ b/classentt_1_1Family-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1Family.html b/classentt_1_1Family.html index 71b92e65f..ecfadb1a0 100644 --- a/classentt_1_1Family.html +++ b/classentt_1_1Family.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1HashedString-members.html b/classentt_1_1HashedString-members.html index 65dbe27db..e8369cff5 100644 --- a/classentt_1_1HashedString-members.html +++ b/classentt_1_1HashedString-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1HashedString.html b/classentt_1_1HashedString.html index c21d2ecc6..38e9c2940 100644 --- a/classentt_1_1HashedString.html +++ b/classentt_1_1HashedString.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1Identifier-members.html b/classentt_1_1Identifier-members.html index d422d6a98..05eda48b4 100644 --- a/classentt_1_1Identifier-members.html +++ b/classentt_1_1Identifier-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1Identifier.html b/classentt_1_1Identifier.html index db4e76125..735dce5e1 100644 --- a/classentt_1_1Identifier.html +++ b/classentt_1_1Identifier.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -96,7 +96,7 @@ Static Public Member Functions class entt::Identifier< Types >

Types identifiers.

-

Variable template used to generate identifiers at compile-time for the given types. Use the get member function to know what's the identifier associated to the specific type.

+

TURN_OFF_DOXYGEN Variable template used to generate identifiers at compile-time for the given types. Use the get member function to know what's the identifier associated to the specific type.

Note
Identifiers are constant expression and can be used in any context where such an expression is required. As an example:
using ID = entt::Identifier<AType, AnotherType>;
switch(aTypeIdentifier) {
case ID::get<AType>():
// ...
break;
case ID::get<AnotherType>():
// ...
break;
default:
// ...
}
Template Parameters
diff --git a/classentt_1_1Meta-members.html b/classentt_1_1Meta-members.html new file mode 100644 index 000000000..5e7d10a38 --- /dev/null +++ b/classentt_1_1Meta-members.html @@ -0,0 +1,85 @@ + + + + + + + +EnTT: Member List + + + + + + + + + +
+
+
+ + + + + +
+
EnTT +  2.7.2 +
+
+ + + + + + + + + +
+
+ + +
+ +
+ + + +
+
+
entt::Meta Member List
+
+
+ +

This is the complete list of members for entt::Meta, including all inherited members.

+ + + + + +
factory_type typedef (defined in entt::Meta)entt::Meta
reflect(const char *str, Property &&... property) ENTT_NOEXCEPT (defined in entt::Meta)entt::Metainlinestatic
resolve() ENTT_NOEXCEPT (defined in entt::Meta)entt::Metainlinestatic
resolve(const char *str) ENTT_NOEXCEPT (defined in entt::Meta)entt::Metainlinestatic
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1Meta.html b/classentt_1_1Meta.html new file mode 100644 index 000000000..144303d8e --- /dev/null +++ b/classentt_1_1Meta.html @@ -0,0 +1,111 @@ + + + + + + + +EnTT: entt::Meta Class Reference + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.2 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+Classes | +Public Types | +Static Public Member Functions | +List of all members
+
+
entt::Meta Class Referencefinal
+
+
+ + + + + +

+Public Types

+template<typename Type >
using factory_type = MetaFactory< Type >
 
+ + + + + + + + + +

+Static Public Member Functions

+template<typename Type , typename... Property>
static factory_type< std::decay_t< Type > > reflect (const char *str, Property &&... property) ENTT_NOEXCEPT
 
+template<typename Type >
static MetaType * resolve () ENTT_NOEXCEPT
 
+static MetaType * resolve (const char *str) ENTT_NOEXCEPT
 
+

Detailed Description

+
+

Definition at line 24 of file factory.hpp.

+
The documentation for this class was generated from the following file: +
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1MetaCtor-members.html b/classentt_1_1MetaCtor-members.html new file mode 100644 index 000000000..dd2e4c2d0 --- /dev/null +++ b/classentt_1_1MetaCtor-members.html @@ -0,0 +1,89 @@ + + + + + + + +EnTT: Member List + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.2 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+
entt::MetaCtor Member List
+
+
+ +

This is the complete list of members for entt::MetaCtor, including all inherited members.

+ + + + + + + + + +
accept() const ENTT_NOEXCEPT (defined in entt::MetaCtor)entt::MetaCtorinline
arg(size_type index) const ENTT_NOEXCEPT (defined in entt::MetaCtor)entt::MetaCtorinline
invoke(Args &&... args) (defined in entt::MetaCtor)entt::MetaCtorinline
Meta (defined in entt::MetaCtor)entt::MetaCtorfriend
properties(Op op) const ENTT_NOEXCEPT (defined in entt::MetaCtor)entt::MetaCtorinline
property(Key &&key) const ENTT_NOEXCEPT (defined in entt::MetaCtor)entt::MetaCtorinline
size() const ENTT_NOEXCEPT (defined in entt::MetaCtor)entt::MetaCtorinline
size_type typedef (defined in entt::MetaCtor)entt::MetaCtor
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1MetaCtor.html b/classentt_1_1MetaCtor.html new file mode 100644 index 000000000..edeee1d0a --- /dev/null +++ b/classentt_1_1MetaCtor.html @@ -0,0 +1,127 @@ + + + + + + + +EnTT: entt::MetaCtor Class Reference + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.2 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+Public Types | +Public Member Functions | +Friends | +List of all members
+
+
entt::MetaCtor Class Reference
+
+
+ + + + +

+Public Types

+using size_type = typename internal::MetaCtorNode::size_type
 
+ + + + + + + + + + + + + + + + + +

+Public Member Functions

+size_type size () const ENTT_NOEXCEPT
 
+MetaType * arg (size_type index) const ENTT_NOEXCEPT
 
+template<typename... Args>
bool accept () const ENTT_NOEXCEPT
 
+template<typename... Args>
MetaAny invoke (Args &&... args)
 
+template<typename Op >
void properties (Op op) const ENTT_NOEXCEPT
 
+template<typename Key >
MetaProp * property (Key &&key) const ENTT_NOEXCEPT
 
+ + + +

+Friends

+class Meta
 
+

Detailed Description

+
+

Definition at line 361 of file meta.hpp.

+
The documentation for this class was generated from the following file: +
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1MetaData-members.html b/classentt_1_1MetaData-members.html new file mode 100644 index 000000000..ee3d7824b --- /dev/null +++ b/classentt_1_1MetaData-members.html @@ -0,0 +1,91 @@ + + + + + + + +EnTT: Member List + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.2 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+
entt::MetaData Member List
+
+
+ +

This is the complete list of members for entt::MetaData, including all inherited members.

+ + + + + + + + + + + +
accept() const ENTT_NOEXCEPT (defined in entt::MetaData)entt::MetaDatainline
get(const void *instance) const ENTT_NOEXCEPT (defined in entt::MetaData)entt::MetaDatainline
Meta (defined in entt::MetaData)entt::MetaDatafriend
name() const ENTT_NOEXCEPT (defined in entt::MetaData)entt::MetaDatainline
properties(Op op) const ENTT_NOEXCEPT (defined in entt::MetaData)entt::MetaDatainline
property(Key &&key) const ENTT_NOEXCEPT (defined in entt::MetaData)entt::MetaDatainline
readonly() const ENTT_NOEXCEPT (defined in entt::MetaData)entt::MetaDatainline
set(void *instance, Type &&value) (defined in entt::MetaData)entt::MetaDatainline
shared() const ENTT_NOEXCEPT (defined in entt::MetaData)entt::MetaDatainline
type() const ENTT_NOEXCEPT (defined in entt::MetaData)entt::MetaDatainline
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1MetaData.html b/classentt_1_1MetaData.html new file mode 100644 index 000000000..a20183584 --- /dev/null +++ b/classentt_1_1MetaData.html @@ -0,0 +1,129 @@ + + + + + + + +EnTT: entt::MetaData Class Reference + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.2 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+Public Member Functions | +Friends | +List of all members
+
+
entt::MetaData Class Reference
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + +

+Public Member Functions

+const char * name () const ENTT_NOEXCEPT
 
+bool readonly () const ENTT_NOEXCEPT
 
+bool shared () const ENTT_NOEXCEPT
 
+MetaType * type () const ENTT_NOEXCEPT
 
+template<typename Type >
bool accept () const ENTT_NOEXCEPT
 
+template<typename Type >
void set (void *instance, Type &&value)
 
+MetaAny get (const void *instance) const ENTT_NOEXCEPT
 
+template<typename Op >
void properties (Op op) const ENTT_NOEXCEPT
 
+template<typename Key >
MetaProp * property (Key &&key) const ENTT_NOEXCEPT
 
+ + + +

+Friends

+class Meta
 
+

Detailed Description

+
+

Definition at line 433 of file meta.hpp.

+
The documentation for this class was generated from the following file: +
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1MetaDtor-members.html b/classentt_1_1MetaDtor-members.html new file mode 100644 index 000000000..9cb2313bc --- /dev/null +++ b/classentt_1_1MetaDtor-members.html @@ -0,0 +1,85 @@ + + + + + + + +EnTT: Member List + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.2 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+
entt::MetaDtor Member List
+
+
+ +

This is the complete list of members for entt::MetaDtor, including all inherited members.

+ + + + + +
invoke(void *instance) (defined in entt::MetaDtor)entt::MetaDtorinline
Meta (defined in entt::MetaDtor)entt::MetaDtorfriend
properties(Op op) const ENTT_NOEXCEPT (defined in entt::MetaDtor)entt::MetaDtorinline
property(Key &&key) const ENTT_NOEXCEPT (defined in entt::MetaDtor)entt::MetaDtorinline
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1MetaDtor.html b/classentt_1_1MetaDtor.html new file mode 100644 index 000000000..fae2dba57 --- /dev/null +++ b/classentt_1_1MetaDtor.html @@ -0,0 +1,109 @@ + + + + + + + +EnTT: entt::MetaDtor Class Reference + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.2 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+Public Member Functions | +Friends | +List of all members
+
+
entt::MetaDtor Class Reference
+
+
+ + + + + + + + + + +

+Public Member Functions

+void invoke (void *instance)
 
+template<typename Op >
void properties (Op op) const ENTT_NOEXCEPT
 
+template<typename Key >
MetaProp * property (Key &&key) const ENTT_NOEXCEPT
 
+ + + +

+Friends

+class Meta
 
+

Detailed Description

+
+

Definition at line 406 of file meta.hpp.

+
The documentation for this class was generated from the following file: +
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1MetaFunc-members.html b/classentt_1_1MetaFunc-members.html new file mode 100644 index 000000000..bf8de980d --- /dev/null +++ b/classentt_1_1MetaFunc-members.html @@ -0,0 +1,94 @@ + + + + + + + +EnTT: Member List + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.2 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+
entt::MetaFunc Member List
+
+
+ +

This is the complete list of members for entt::MetaFunc, including all inherited members.

+ + + + + + + + + + + + + + +
accept() const ENTT_NOEXCEPT (defined in entt::MetaFunc)entt::MetaFuncinline
arg(size_type index) const ENTT_NOEXCEPT (defined in entt::MetaFunc)entt::MetaFuncinline
constant() const ENTT_NOEXCEPT (defined in entt::MetaFunc)entt::MetaFuncinline
invoke(const void *instance, Args &&... args) const (defined in entt::MetaFunc)entt::MetaFuncinline
invoke(void *instance, Args &&... args) (defined in entt::MetaFunc)entt::MetaFuncinline
Meta (defined in entt::MetaFunc)entt::MetaFuncfriend
name() const ENTT_NOEXCEPT (defined in entt::MetaFunc)entt::MetaFuncinline
properties(Op op) const ENTT_NOEXCEPT (defined in entt::MetaFunc)entt::MetaFuncinline
property(Key &&key) const ENTT_NOEXCEPT (defined in entt::MetaFunc)entt::MetaFuncinline
ret() const ENTT_NOEXCEPT (defined in entt::MetaFunc)entt::MetaFuncinline
shared() const ENTT_NOEXCEPT (defined in entt::MetaFunc)entt::MetaFuncinline
size() const ENTT_NOEXCEPT (defined in entt::MetaFunc)entt::MetaFuncinline
size_type typedef (defined in entt::MetaFunc)entt::MetaFunc
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1MetaFunc.html b/classentt_1_1MetaFunc.html new file mode 100644 index 000000000..a3faa535e --- /dev/null +++ b/classentt_1_1MetaFunc.html @@ -0,0 +1,143 @@ + + + + + + + +EnTT: entt::MetaFunc Class Reference + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.2 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+Public Types | +Public Member Functions | +Friends | +List of all members
+
+
entt::MetaFunc Class Reference
+
+
+ + + + +

+Public Types

+using size_type = typename internal::MetaCtorNode::size_type
 
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+Public Member Functions

+const char * name () const ENTT_NOEXCEPT
 
+size_type size () const ENTT_NOEXCEPT
 
+bool constant () const ENTT_NOEXCEPT
 
+bool shared () const ENTT_NOEXCEPT
 
+MetaType * ret () const ENTT_NOEXCEPT
 
+MetaType * arg (size_type index) const ENTT_NOEXCEPT
 
+template<typename... Args>
bool accept () const ENTT_NOEXCEPT
 
+template<typename... Args>
MetaAny invoke (const void *instance, Args &&... args) const
 
+template<typename... Args>
MetaAny invoke (void *instance, Args &&... args)
 
+template<typename Op >
void properties (Op op) const ENTT_NOEXCEPT
 
+template<typename Key >
MetaProp * property (Key &&key) const ENTT_NOEXCEPT
 
+ + + +

+Friends

+class Meta
 
+

Detailed Description

+
+

Definition at line 486 of file meta.hpp.

+
The documentation for this class was generated from the following file: +
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1MetaProp-members.html b/classentt_1_1MetaProp-members.html new file mode 100644 index 000000000..bf963cb74 --- /dev/null +++ b/classentt_1_1MetaProp-members.html @@ -0,0 +1,84 @@ + + + + + + + +EnTT: Member List + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.2 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+
entt::MetaProp Member List
+
+
+ +

This is the complete list of members for entt::MetaProp, including all inherited members.

+ + + + +
key() const ENTT_NOEXCEPT (defined in entt::MetaProp)entt::MetaPropinline
Meta (defined in entt::MetaProp)entt::MetaPropfriend
value() const ENTT_NOEXCEPT (defined in entt::MetaProp)entt::MetaPropinline
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1MetaProp.html b/classentt_1_1MetaProp.html new file mode 100644 index 000000000..d455c4b79 --- /dev/null +++ b/classentt_1_1MetaProp.html @@ -0,0 +1,104 @@ + + + + + + + +EnTT: entt::MetaProp Class Reference + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.2 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+Public Member Functions | +Friends | +List of all members
+
+
entt::MetaProp Class Reference
+
+
+ + + + + + +

+Public Member Functions

+const MetaAny & key () const ENTT_NOEXCEPT
 
+const MetaAny & value () const ENTT_NOEXCEPT
 
+ + + +

+Friends

+class Meta
 
+

Detailed Description

+
+

Definition at line 340 of file meta.hpp.

+
The documentation for this class was generated from the following file: +
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1MetaType-members.html b/classentt_1_1MetaType-members.html new file mode 100644 index 000000000..a0186c27a --- /dev/null +++ b/classentt_1_1MetaType-members.html @@ -0,0 +1,95 @@ + + + + + + + +EnTT: Member List + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.2 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+
entt::MetaType Member List
+
+
+ +

This is the complete list of members for entt::MetaType, including all inherited members.

+ + + + + + + + + + + + + + + +
construct(Args &&... args) const (defined in entt::MetaType)entt::MetaTypeinline
ctor(Op op) const ENTT_NOEXCEPT (defined in entt::MetaType)entt::MetaTypeinline
ctor() const ENTT_NOEXCEPT (defined in entt::MetaType)entt::MetaTypeinline
data(Op op) const ENTT_NOEXCEPT (defined in entt::MetaType)entt::MetaTypeinline
data(const char *str) const ENTT_NOEXCEPT (defined in entt::MetaType)entt::MetaTypeinline
destroy(void *instance) (defined in entt::MetaType)entt::MetaTypeinline
dtor(Op op) const ENTT_NOEXCEPT (defined in entt::MetaType)entt::MetaTypeinline
dtor() const ENTT_NOEXCEPT (defined in entt::MetaType)entt::MetaTypeinline
func(Op op) const ENTT_NOEXCEPT (defined in entt::MetaType)entt::MetaTypeinline
func(const char *str) const ENTT_NOEXCEPT (defined in entt::MetaType)entt::MetaTypeinline
Meta (defined in entt::MetaType)entt::MetaTypefriend
name() const ENTT_NOEXCEPT (defined in entt::MetaType)entt::MetaTypeinline
properties(Op op) const ENTT_NOEXCEPT (defined in entt::MetaType)entt::MetaTypeinline
property(Key &&key) const ENTT_NOEXCEPT (defined in entt::MetaType)entt::MetaTypeinline
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1MetaType.html b/classentt_1_1MetaType.html new file mode 100644 index 000000000..89b318798 --- /dev/null +++ b/classentt_1_1MetaType.html @@ -0,0 +1,145 @@ + + + + + + + +EnTT: entt::MetaType Class Reference + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.2 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+Public Member Functions | +Friends | +List of all members
+
+
entt::MetaType Class Reference
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+Public Member Functions

+const char * name () const ENTT_NOEXCEPT
 
+template<typename Op >
void ctor (Op op) const ENTT_NOEXCEPT
 
+template<typename... Args>
MetaCtor * ctor () const ENTT_NOEXCEPT
 
+template<typename Op >
void dtor (Op op) const ENTT_NOEXCEPT
 
+MetaDtor * dtor () const ENTT_NOEXCEPT
 
+template<typename Op >
void data (Op op) const ENTT_NOEXCEPT
 
+MetaData * data (const char *str) const ENTT_NOEXCEPT
 
+template<typename Op >
void func (Op op) const ENTT_NOEXCEPT
 
+MetaFunc * func (const char *str) const ENTT_NOEXCEPT
 
+template<typename... Args>
MetaAny construct (Args &&... args) const
 
+void destroy (void *instance)
 
+template<typename Op >
void properties (Op op) const ENTT_NOEXCEPT
 
+template<typename Key >
MetaProp * property (Key &&key) const ENTT_NOEXCEPT
 
+ + + +

+Friends

+class Meta
 
+

Detailed Description

+
+

Definition at line 553 of file meta.hpp.

+
The documentation for this class was generated from the following file: +
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/classentt_1_1PersistentView-members.html b/classentt_1_1PersistentView-members.html index f5837e4c8..66bdfafd0 100644 --- a/classentt_1_1PersistentView-members.html +++ b/classentt_1_1PersistentView-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1PersistentView.html b/classentt_1_1PersistentView.html index 46c9c2077..18a198e73 100644 --- a/classentt_1_1PersistentView.html +++ b/classentt_1_1PersistentView.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1Process-members.html b/classentt_1_1Process-members.html index bd158ab67..97b80349b 100644 --- a/classentt_1_1Process-members.html +++ b/classentt_1_1Process-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1Process.html b/classentt_1_1Process.html index 65425e304..5dc79b4f5 100644 --- a/classentt_1_1Process.html +++ b/classentt_1_1Process.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1Prototype-members.html b/classentt_1_1Prototype-members.html index baa72dcaf..59faada7d 100644 --- a/classentt_1_1Prototype-members.html +++ b/classentt_1_1Prototype-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1Prototype.html b/classentt_1_1Prototype.html index cb3583a3c..b6a9af9b0 100644 --- a/classentt_1_1Prototype.html +++ b/classentt_1_1Prototype.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -190,7 +190,7 @@ class entt::Prototype< Entity >
-

Definition at line 39 of file prototype.hpp.

+

Definition at line 40 of file prototype.hpp.

Constructor & Destructor Documentation

◆ Prototype() [1/2]

@@ -226,7 +226,7 @@ template<typename Entity > -

Definition at line 69 of file prototype.hpp.

+

Definition at line 70 of file prototype.hpp.

@@ -265,7 +265,7 @@ template<typename Entity > -

Definition at line 93 of file prototype.hpp.

+

Definition at line 94 of file prototype.hpp.

@@ -319,7 +319,7 @@ template<typename Entity > -

Definition at line 356 of file prototype.hpp.

+

Definition at line 357 of file prototype.hpp.

@@ -361,7 +361,7 @@ template<typename Entity > -

Definition at line 380 of file prototype.hpp.

+

Definition at line 381 of file prototype.hpp.

@@ -415,7 +415,7 @@ template<typename Entity > -

Definition at line 307 of file prototype.hpp.

+

Definition at line 308 of file prototype.hpp.

@@ -458,7 +458,7 @@ template<typename Entity > -

Definition at line 333 of file prototype.hpp.

+

Definition at line 334 of file prototype.hpp.

@@ -490,7 +490,7 @@ template<typename Entity >

Creates a new entity using a given prototype.

Utility shortcut, equivalent to the following snippet:

-
const auto entity = registry.create();
prototype(registry, entity);
Note
The registry may or may not be different from the one already used by the prototype. There is also an overload that directly uses the underlying registry.
+
const auto entity = registry.create();
prototype(registry, entity);
Note
The registry may or may not be different from the one already used by the prototype. There is also an overload that directly uses the underlying registry.
Parameters
@@ -499,7 +499,7 @@ template<typename Entity >
Returns
A valid entity identifier.
-

Definition at line 259 of file prototype.hpp.

+

Definition at line 260 of file prototype.hpp.

@@ -530,10 +530,10 @@ template<typename Entity >

Creates a new entity using a given prototype.

Utility shortcut, equivalent to the following snippet:

-
const auto entity = registry.create();
prototype(entity);
Note
This overload directly uses the underlying registry as a working space. Therefore, the components of the prototype and of the entity will share the same registry.
+
const auto entity = registry.create();
prototype(entity);
Note
This overload directly uses the underlying registry as a working space. Therefore, the components of the prototype and of the entity will share the same registry.
Returns
A valid entity identifier.
-

Definition at line 282 of file prototype.hpp.

+

Definition at line 283 of file prototype.hpp.

@@ -575,7 +575,7 @@ template<typename Component >
Returns
A reference to the component owned by the prototype.
-

Definition at line 184 of file prototype.hpp.

+

Definition at line 185 of file prototype.hpp.

@@ -617,7 +617,7 @@ template<typename Component >
Returns
A reference to the component owned by the prototype.
-

Definition at line 201 of file prototype.hpp.

+

Definition at line 202 of file prototype.hpp.

@@ -659,7 +659,7 @@ template<typename... Component>
Returns
References to the components owned by the prototype.
-

Definition at line 219 of file prototype.hpp.

+

Definition at line 220 of file prototype.hpp.

@@ -701,7 +701,7 @@ template<typename... Component>
Returns
References to the components owned by the prototype.
-

Definition at line 237 of file prototype.hpp.

+

Definition at line 238 of file prototype.hpp.

@@ -741,7 +741,7 @@ template<typename... Component>
Returns
True if the prototype owns all the components, false otherwise.
-

Definition at line 167 of file prototype.hpp.

+

Definition at line 168 of file prototype.hpp.

@@ -795,7 +795,7 @@ template<typename Entity > -

Definition at line 405 of file prototype.hpp.

+

Definition at line 406 of file prototype.hpp.

@@ -838,7 +838,7 @@ template<typename Entity > -

Definition at line 429 of file prototype.hpp.

+

Definition at line 430 of file prototype.hpp.

@@ -870,7 +870,7 @@ template<typename Entity >

Creates a new entity using a given prototype.

Utility shortcut, equivalent to the following snippet:

-
const auto entity = registry.create();
prototype(registry, entity);
Note
The registry may or may not be different from the one already used by the prototype. There is also an overload that directly uses the underlying registry.
+
const auto entity = registry.create();
prototype(registry, entity);
Note
The registry may or may not be different from the one already used by the prototype. There is also an overload that directly uses the underlying registry.
Parameters
otherA valid reference to a registry.
@@ -879,7 +879,7 @@ template<typename Entity >
Returns
A valid entity identifier.
-

Definition at line 451 of file prototype.hpp.

+

Definition at line 452 of file prototype.hpp.

@@ -910,10 +910,10 @@ template<typename Entity >

Creates a new entity using a given prototype.

Utility shortcut, equivalent to the following snippet:

-
const auto entity = registry.create();
prototype(entity);
Note
This overload directly uses the underlying registry as a working space. Therefore, the components of the prototype and of the entity will share the same registry.
+
const auto entity = registry.create();
prototype(entity);
Note
This overload directly uses the underlying registry as a working space. Therefore, the components of the prototype and of the entity will share the same registry.
Returns
A valid entity identifier.
-

Definition at line 472 of file prototype.hpp.

+

Definition at line 473 of file prototype.hpp.

@@ -984,7 +984,7 @@ template<typename Entity >
Returns
This Prototype.
-

Definition at line 114 of file prototype.hpp.

+

Definition at line 115 of file prototype.hpp.

@@ -1032,7 +1032,7 @@ template<typename Component , typename... Args>
Returns
A reference to the newly created component.
-

Definition at line 133 of file prototype.hpp.

+

Definition at line 134 of file prototype.hpp.

@@ -1071,7 +1071,7 @@ template<typename Component > -

Definition at line 156 of file prototype.hpp.

+

Definition at line 157 of file prototype.hpp.

diff --git a/classentt_1_1RawView-members.html b/classentt_1_1RawView-members.html index d0d2cb361..9890b00ab 100644 --- a/classentt_1_1RawView-members.html +++ b/classentt_1_1RawView-members.html @@ -22,7 +22,7 @@ diff --git a/classentt_1_1RawView.html b/classentt_1_1RawView.html index 412e57e50..5d65faf4a 100644 --- a/classentt_1_1RawView.html +++ b/classentt_1_1RawView.html @@ -22,7 +22,7 @@ diff --git a/classentt_1_1Registry-members.html b/classentt_1_1Registry-members.html index a2c8cc986..c2f74e06c 100644 --- a/classentt_1_1Registry-members.html +++ b/classentt_1_1Registry-members.html @@ -22,7 +22,7 @@ diff --git a/classentt_1_1Registry.html b/classentt_1_1Registry.html index ef5cf28f5..44d6f06df 100644 --- a/classentt_1_1Registry.html +++ b/classentt_1_1Registry.html @@ -22,7 +22,7 @@ @@ -377,7 +377,7 @@ class entt::Registry< Entity > -

Definition at line 40 of file registry.hpp.

+

Definition at line 42 of file registry.hpp.

Member Function Documentation

◆ accommodate()

@@ -419,7 +419,7 @@ template<typename Component , typename... Args>

Assigns or replaces the given component for an entity.

Equivalent to the following snippet (pseudocode):

-
if(registry.has<Component>(entity)) {
registry.replace<Component>(entity, args...);
} else {
registry.assign<Component>(entity, args...);
}

Prefer this function anyway because it has slightly better performance.

+
if(registry.has<Component>(entity)) {
registry.replace<Component>(entity, args...);
} else {
registry.assign<Component>(entity, args...);
}

Prefer this function anyway because it has slightly better performance.

Warning
Attempting to use an invalid entity results in undefined behavior.
An assertion will abort the execution at runtime in debug mode in case of invalid entity.
Template Parameters
@@ -438,7 +438,7 @@ template<typename Component , typename... Args>
Returns
A reference to the newly created component.
-

Definition at line 956 of file registry.hpp.

+

Definition at line 994 of file registry.hpp.

@@ -470,7 +470,7 @@ template<typename Entity>

Returns the number of entities still in use.

Returns
Number of entities still in use.
-

Definition at line 231 of file registry.hpp.

+

Definition at line 304 of file registry.hpp.

@@ -539,7 +539,7 @@ template<typename Tag , typename... Args>
Returns
A reference to the newly created tag.
-

Definition at line 588 of file registry.hpp.

+

Definition at line 657 of file registry.hpp.

@@ -601,7 +601,7 @@ template<typename Component , typename... Args>
Returns
A reference to the newly created component.
-

Definition at line 619 of file registry.hpp.

+

Definition at line 685 of file registry.hpp.

@@ -633,17 +633,15 @@ template<typename Tag >

Gets the owner of the given tag, if any.

-
Warning
Attempting to get the owner of a tag that hasn't been previously attached to an entity results in undefined behavior.
- An assertion will abort the execution at runtime in debug mode if the tag hasn't an owner.
Template Parameters
otherA valid reference to a registry.
EnTT -  2.7.2 +  2.7.3
EnTT -  2.7.2 +  2.7.3
EnTT -  2.7.2 +  2.7.3
EnTT -  2.7.2 +  2.7.3
TagType of tag of which to get the owner.
-
Returns
A valid entity identifier.
+
Returns
A valid entity identifier if an owner exists, the null entity identifier otherwise.
-

Definition at line 924 of file registry.hpp.

+

Definition at line 963 of file registry.hpp.

@@ -683,7 +681,7 @@ template<typename Component >
Returns
Capacity of the pool of the given component.
-

Definition at line 268 of file registry.hpp.

+

Definition at line 341 of file registry.hpp.

@@ -715,7 +713,7 @@ template<typename Entity>

Returns the number of entities that a registry has currently allocated space for.

Returns
Capacity of the registry.
-

Definition at line 277 of file registry.hpp.

+

Definition at line 350 of file registry.hpp.

@@ -761,7 +759,7 @@ template<typename Tag >
Returns
A temporary sink object.
-

Definition at line 989 of file registry.hpp.

+

Definition at line 1027 of file registry.hpp.

@@ -806,7 +804,7 @@ template<typename Component >
Returns
A temporary sink object.
-

Definition at line 1018 of file registry.hpp.

+

Definition at line 1056 of file registry.hpp.

@@ -846,7 +844,7 @@ template<typename... Component>
Returns
True if the view has already been prepared, false otherwise.
-

Definition at line 1422 of file registry.hpp.

+

Definition at line 1455 of file registry.hpp.

@@ -885,7 +883,7 @@ template<typename Entity>

The returned entity has no components nor tags assigned.

Returns
A valid entity identifier.
-

Definition at line 448 of file registry.hpp.

+

Definition at line 521 of file registry.hpp.

@@ -927,7 +925,7 @@ template<typename Entity>
Returns
Actual version for the given entity identifier.
-

Definition at line 425 of file registry.hpp.

+

Definition at line 498 of file registry.hpp.

@@ -969,7 +967,7 @@ template<typename Component >
Returns
A pointer to the array of entities.
-

Definition at line 353 of file registry.hpp.

+

Definition at line 426 of file registry.hpp.

@@ -1004,14 +1002,14 @@ template<typename Tag >

Destroys the entity that owns the given tag, if any.

Convenient shortcut to destroy an entity by means of a tag type.
Syntactic sugar for the following snippet:

-
if(registry.has<Tag>()) {
registry.destroy(registry.attachee<Tag>());
}
Template Parameters
+
if(registry.has<Tag>()) {
registry.destroy(registry.attachee<Tag>());
}
Template Parameters
TagType of tag to use to search for the entity.
-

Definition at line 483 of file registry.hpp.

+

Definition at line 556 of file registry.hpp.

@@ -1054,7 +1052,7 @@ Attempting to use an invalid entity results in undefined behavior.
-

Definition at line 509 of file registry.hpp.

+

Definition at line 582 of file registry.hpp.

@@ -1089,7 +1087,7 @@ template<typename... Component, typename... Type>

Destroys the entities that own the given components, if any.

Convenient shortcut to destroy a set of entities at once.
Syntactic sugar for the following snippet:

-
for(const auto entity: registry.view<Component...>(Type{}...)) {
registry.destroy(entity);
}
Template Parameters
+
for(const auto entity: registry.view<Component...>(Type{}...)) {
registry.destroy(entity);
}
Template Parameters
@@ -1097,7 +1095,7 @@ template<typename... Component, typename... Type> -

Definition at line 560 of file registry.hpp.

+

Definition at line 629 of file registry.hpp.

@@ -1143,7 +1141,7 @@ template<typename Tag >
Returns
A temporary sink object.
-

Definition at line 1047 of file registry.hpp.

+

Definition at line 1085 of file registry.hpp.

@@ -1188,7 +1186,7 @@ template<typename Component >
Returns
A temporary sink object.
-

Definition at line 1076 of file registry.hpp.

+

Definition at line 1114 of file registry.hpp.

@@ -1230,7 +1228,7 @@ template<typename... Component> -

Definition at line 1409 of file registry.hpp.

+

Definition at line 1442 of file registry.hpp.

@@ -1281,7 +1279,7 @@ template<typename Func > -

Definition at line 1249 of file registry.hpp.

+

Definition at line 1282 of file registry.hpp.

@@ -1321,7 +1319,7 @@ template<typename Component >
Returns
True if the pool of the given component is empty, false otherwise.
-

Definition at line 288 of file registry.hpp.

+

Definition at line 361 of file registry.hpp.

@@ -1353,7 +1351,7 @@ template<typename Entity>

Checks if there exists at least an entity still in use.

Returns
True if at least an entity is still in use, false otherwise.
-

Definition at line 296 of file registry.hpp.

+

Definition at line 369 of file registry.hpp.

@@ -1392,7 +1390,7 @@ template<typename Entity>
Returns
The entity identifier without the version.
-

Definition at line 395 of file registry.hpp.

+

Definition at line 468 of file registry.hpp.

@@ -1435,7 +1433,7 @@ template<typename Entity>
Returns
True if the identifier is valid, false otherwise.
-

Definition at line 384 of file registry.hpp.

+

Definition at line 457 of file registry.hpp.

@@ -1477,7 +1475,7 @@ template<typename Tag >
Returns
A reference to the tag.
-

Definition at line 735 of file registry.hpp.

+

Definition at line 783 of file registry.hpp.

@@ -1519,7 +1517,7 @@ template<typename Tag >
Returns
A reference to the tag.
-

Definition at line 753 of file registry.hpp.

+

Definition at line 801 of file registry.hpp.

@@ -1568,7 +1566,7 @@ template<typename Component >
Returns
A reference to the component owned by the entity.
-

Definition at line 772 of file registry.hpp.

+

Definition at line 820 of file registry.hpp.

@@ -1617,7 +1615,7 @@ template<typename Component >
Returns
A reference to the component owned by the entity.
-

Definition at line 793 of file registry.hpp.

+

Definition at line 841 of file registry.hpp.

@@ -1666,7 +1664,7 @@ template<typename... Component>
Returns
References to the components owned by the entity.
-

Definition at line 813 of file registry.hpp.

+

Definition at line 861 of file registry.hpp.

@@ -1715,7 +1713,7 @@ template<typename... Component>
Returns
References to the components owned by the entity.
-

Definition at line 833 of file registry.hpp.

+

Definition at line 881 of file registry.hpp.

@@ -1755,7 +1753,7 @@ template<typename Tag >
Returns
True if the tag already has an owner, false otherwise.
-

Definition at line 669 of file registry.hpp.

+

Definition at line 726 of file registry.hpp.

@@ -1799,7 +1797,7 @@ template<typename Tag >

Checks if an entity owns the given tag.

Syntactic sugar for the following snippet:

-
registry.has<Tag>() && registry.attachee<Tag>() == entity
Template Parameters
+
registry.has<Tag>() && registry.attachee<Tag>() == entity
Template Parameters
ComponentTypes of components to use to search for the entities.
TypeType of view to use or empty to use a standard view.
TagType of tag for which to perform the check.
@@ -1813,7 +1811,7 @@ template<typename Tag >
Returns
True if the entity owns the tag, false otherwise.
-

Definition at line 696 of file registry.hpp.

+

Definition at line 744 of file registry.hpp.

@@ -1862,7 +1860,7 @@ template<typename... Component>
Returns
True if the entity has all the components, false otherwise.
-

Definition at line 713 of file registry.hpp.

+

Definition at line 761 of file registry.hpp.

@@ -1912,7 +1910,7 @@ template<typename Tag >
Returns
A valid entity identifier.
-

Definition at line 902 of file registry.hpp.

+

Definition at line 950 of file registry.hpp.

@@ -2014,7 +2012,7 @@ template<typename Entity>
Returns
True if the entity is an orphan, false otherwise.
-

Definition at line 1276 of file registry.hpp.

+

Definition at line 1309 of file registry.hpp.

@@ -2063,7 +2061,7 @@ template<typename Func > -

Definition at line 1310 of file registry.hpp.

+

Definition at line 1343 of file registry.hpp.

@@ -2105,7 +2103,7 @@ template<typename... Component> -

Definition at line 1374 of file registry.hpp.

+

Definition at line 1407 of file registry.hpp.

@@ -2147,7 +2145,7 @@ template<typename Component >
Returns
A pointer to the array of components of the given type.
-

Definition at line 315 of file registry.hpp.

+

Definition at line 388 of file registry.hpp.

@@ -2189,7 +2187,7 @@ template<typename Component >
Returns
A pointer to the array of components of the given type.
-

Definition at line 334 of file registry.hpp.

+

Definition at line 407 of file registry.hpp.

@@ -2228,7 +2226,7 @@ template<typename Tag > -

Definition at line 632 of file registry.hpp.

+

Definition at line 696 of file registry.hpp.

@@ -2276,7 +2274,7 @@ template<typename Component > -

Definition at line 655 of file registry.hpp.

+

Definition at line 714 of file registry.hpp.

@@ -2337,7 +2335,7 @@ template<typename Tag , typename... Args>
Returns
A reference to the tag.
-

Definition at line 856 of file registry.hpp.

+

Definition at line 904 of file registry.hpp.

@@ -2399,7 +2397,7 @@ template<typename Component , typename... Args>
Returns
A reference to the newly created component.
-

Definition at line 881 of file registry.hpp.

+

Definition at line 929 of file registry.hpp.

@@ -2446,7 +2444,7 @@ template<typename Component > -

Definition at line 245 of file registry.hpp.

+

Definition at line 318 of file registry.hpp.

@@ -2485,7 +2483,7 @@ template<typename Entity> -

Definition at line 258 of file registry.hpp.

+

Definition at line 331 of file registry.hpp.

@@ -2534,7 +2532,7 @@ template<typename Component > -

Definition at line 1180 of file registry.hpp.

+

Definition at line 1218 of file registry.hpp.

@@ -2574,7 +2572,7 @@ template<typename Component > -

Definition at line 1201 of file registry.hpp.

+

Definition at line 1237 of file registry.hpp.

@@ -2606,7 +2604,7 @@ template<typename Entity>

Resets a whole registry.

Destroys all the entities. After a call to reset, all the entities still in use are recycled with a new version number. In case entity identifers are stored around, the valid member function can be used to know if they are still valid.

-

Definition at line 1221 of file registry.hpp.

+

Definition at line 1254 of file registry.hpp.

@@ -2641,7 +2639,7 @@ template<typename Entity>
Warning
The loader returned by this function requires that the registry be empty. In case it isn't, all the data will be automatically deleted before to return.
Returns
A temporary object to use to load snasphosts.
-

Definition at line 1580 of file registry.hpp.

+

Definition at line 1613 of file registry.hpp.

@@ -2681,7 +2679,7 @@ template<typename Component >
Returns
Number of existing components of the given type.
-

Definition at line 215 of file registry.hpp.

+

Definition at line 288 of file registry.hpp.

@@ -2713,7 +2711,7 @@ template<typename Entity>

Returns the number of entities created so far.

Returns
Number of entities created so far.
-

Definition at line 223 of file registry.hpp.

+

Definition at line 296 of file registry.hpp.

@@ -2747,7 +2745,7 @@ template<typename Entity> It can be used to save and restore its internal state or to keep two or more instances of this class in sync, as an example in a client-server architecture.

Returns
A temporary object to use to take snasphosts.
-

Definition at line 1551 of file registry.hpp.

+

Definition at line 1584 of file registry.hpp.

@@ -2825,7 +2823,7 @@ template<typename Component , typename Compare , typename Sort = StdSort, ty -

Definition at line 1123 of file registry.hpp.

+

Definition at line 1161 of file registry.hpp.

@@ -2874,7 +2872,7 @@ template<typename To , typename From > -

Definition at line 1159 of file registry.hpp.

+

Definition at line 1197 of file registry.hpp.

@@ -2917,7 +2915,7 @@ template<typename Tag >
Returns
Runtime numeric identifier of the given type of tag.
-

Definition at line 188 of file registry.hpp.

+

Definition at line 261 of file registry.hpp.

@@ -2959,7 +2957,7 @@ template<typename Component >
Returns
Runtime numeric identifier of the given type of component.
-

Definition at line 205 of file registry.hpp.

+

Definition at line 278 of file registry.hpp.

@@ -2998,7 +2996,7 @@ template<typename Entity>
Returns
True if the identifier is valid, false otherwise.
-

Definition at line 362 of file registry.hpp.

+

Definition at line 435 of file registry.hpp.

@@ -3037,7 +3035,7 @@ template<typename Entity>
Returns
The version stored along with the given entity identifier.
-

Definition at line 404 of file registry.hpp.

+

Definition at line 477 of file registry.hpp.

@@ -3096,7 +3094,7 @@ template<typename... Component>
Returns
A newly created standard view.
-

Definition at line 1353 of file registry.hpp.

+

Definition at line 1386 of file registry.hpp.

@@ -3157,7 +3155,7 @@ template<typename... Component>
Returns
A newly created persistent view.
-

Definition at line 1468 of file registry.hpp.

+

Definition at line 1501 of file registry.hpp.

@@ -3211,7 +3209,7 @@ template<typename Component >
Returns
A newly created raw view.
-

Definition at line 1498 of file registry.hpp.

+

Definition at line 1531 of file registry.hpp.

@@ -3283,7 +3281,7 @@ template<typename It >
Returns
A newly created runtime view.
-

Definition at line 1530 of file registry.hpp.

+

Definition at line 1563 of file registry.hpp.

diff --git a/classentt_1_1ResourceCache-members.html b/classentt_1_1ResourceCache-members.html index 645183e45..5926cbd25 100644 --- a/classentt_1_1ResourceCache-members.html +++ b/classentt_1_1ResourceCache-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1ResourceCache.html b/classentt_1_1ResourceCache.html index 683ae7c31..f06006ba6 100644 --- a/classentt_1_1ResourceCache.html +++ b/classentt_1_1ResourceCache.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1ResourceHandle-members.html b/classentt_1_1ResourceHandle-members.html index 3c7052a34..ddd8a7b34 100644 --- a/classentt_1_1ResourceHandle-members.html +++ b/classentt_1_1ResourceHandle-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1ResourceHandle.html b/classentt_1_1ResourceHandle.html index 76b9a4517..80ef468a0 100644 --- a/classentt_1_1ResourceHandle.html +++ b/classentt_1_1ResourceHandle.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1ResourceLoader-members.html b/classentt_1_1ResourceLoader-members.html index 42f83681f..87d364c99 100644 --- a/classentt_1_1ResourceLoader-members.html +++ b/classentt_1_1ResourceLoader-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1ResourceLoader.html b/classentt_1_1ResourceLoader.html index c9902ed0a..19a2022e8 100644 --- a/classentt_1_1ResourceLoader.html +++ b/classentt_1_1ResourceLoader.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1RuntimeView-members.html b/classentt_1_1RuntimeView-members.html index e87fda638..54314c300 100644 --- a/classentt_1_1RuntimeView-members.html +++ b/classentt_1_1RuntimeView-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1RuntimeView.html b/classentt_1_1RuntimeView.html index d98051185..2e93ddb34 100644 --- a/classentt_1_1RuntimeView.html +++ b/classentt_1_1RuntimeView.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1Scheduler-members.html b/classentt_1_1Scheduler-members.html index 47b8bf888..42a97f261 100644 --- a/classentt_1_1Scheduler-members.html +++ b/classentt_1_1Scheduler-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1Scheduler.html b/classentt_1_1Scheduler.html index eb2f2b44e..961865b63 100644 --- a/classentt_1_1Scheduler.html +++ b/classentt_1_1Scheduler.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1SigH.html b/classentt_1_1SigH.html index 77bf951df..f05ffecb7 100644 --- a/classentt_1_1SigH.html +++ b/classentt_1_1SigH.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -86,7 +86,7 @@ class entt::SigH< Function, Collector > -

Definition at line 112 of file sigh.hpp.

+

Definition at line 121 of file sigh.hpp.

The documentation for this class was generated from the following file: diff --git a/classentt_1_1SigH_3_01Ret_07Args_8_8_8_08_00_01Collector_01_4-members.html b/classentt_1_1SigH_3_01Ret_07Args_8_8_8_08_00_01Collector_01_4-members.html index f8b64fcec..9a669e7a7 100644 --- a/classentt_1_1SigH_3_01Ret_07Args_8_8_8_08_00_01Collector_01_4-members.html +++ b/classentt_1_1SigH_3_01Ret_07Args_8_8_8_08_00_01Collector_01_4-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1SigH_3_01Ret_07Args_8_8_8_08_00_01Collector_01_4.html b/classentt_1_1SigH_3_01Ret_07Args_8_8_8_08_00_01Collector_01_4.html index ec633f7dc..7ef7d6647 100644 --- a/classentt_1_1SigH_3_01Ret_07Args_8_8_8_08_00_01Collector_01_4.html +++ b/classentt_1_1SigH_3_01Ret_07Args_8_8_8_08_00_01Collector_01_4.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -159,7 +159,7 @@ class entt::SigH< Ret(Args...), Collector > -

Definition at line 255 of file sigh.hpp.

+

Definition at line 299 of file sigh.hpp.

Member Typedef Documentation

◆ instance_type

@@ -185,7 +185,7 @@ template<typename Class > -

Definition at line 271 of file sigh.hpp.

+

Definition at line 315 of file sigh.hpp.

@@ -225,7 +225,7 @@ template<typename Ret , typename... Args, typename Collector >
Returns
An instance of the collector filled with collected data.
-

Definition at line 321 of file sigh.hpp.

+

Definition at line 365 of file sigh.hpp.

@@ -257,7 +257,7 @@ template<typename Ret , typename... Args, typename Collector >

Returns false if at least a listener is connected to the signal.

Returns
True if the signal has no listeners connected, false otherwise.
-

Definition at line 285 of file sigh.hpp.

+

Definition at line 329 of file sigh.hpp.

@@ -297,7 +297,7 @@ template<typename Ret , typename... Args, typename Collector >
Returns
True if the two signals are identical, false otherwise.
-

Definition at line 352 of file sigh.hpp.

+

Definition at line 396 of file sigh.hpp.

@@ -336,7 +336,7 @@ template<typename Ret , typename... Args, typename Collector > -

Definition at line 309 of file sigh.hpp.

+

Definition at line 353 of file sigh.hpp.

@@ -370,7 +370,7 @@ template<typename Ret , typename... Args, typename Collector > The function type for a listener is the one of the signal to which it belongs. The order of invocation of the listeners isn't guaranteed.

Returns
A temporary sink object.
-

Definition at line 298 of file sigh.hpp.

+

Definition at line 342 of file sigh.hpp.

@@ -402,7 +402,7 @@ template<typename Ret , typename... Args, typename Collector >

Number of listeners connected to the signal.

Returns
Number of listeners currently connected.
-

Definition at line 277 of file sigh.hpp.

+

Definition at line 321 of file sigh.hpp.

@@ -452,7 +452,7 @@ template<typename Ret , typename... Args, typename Collector > -

Definition at line 338 of file sigh.hpp.

+

Definition at line 382 of file sigh.hpp.

diff --git a/classentt_1_1Sink.html b/classentt_1_1Sink.html index d95cb426e..a934536e4 100644 --- a/classentt_1_1Sink.html +++ b/classentt_1_1Sink.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -77,7 +77,7 @@ $(function() { class entt::Sink< Function >

Sink implementation.

-

Primary template isn't defined on purpose. All the specializations give a compile-time error unless the template parameter is a function type.

+

TURN_OFF_DOXYGEN Primary template isn't defined on purpose. All the specializations give a compile-time error unless the template parameter is a function type.

Template Parameters
@@ -85,7 +85,7 @@ class entt::Sink< Function > -

Definition at line 99 of file sigh.hpp.

+

Definition at line 108 of file sigh.hpp.

The documentation for this class was generated from the following file: diff --git a/classentt_1_1Sink_3_01Ret_07Args_8_8_8_08_4-members.html b/classentt_1_1Sink_3_01Ret_07Args_8_8_8_08_4-members.html index 14e2881e3..59252e5ba 100644 --- a/classentt_1_1Sink_3_01Ret_07Args_8_8_8_08_4-members.html +++ b/classentt_1_1Sink_3_01Ret_07Args_8_8_8_08_4-members.html @@ -22,7 +22,7 @@ @@ -72,7 +72,9 @@ $(function() {
FunctionA valid function type.
EnTT -  2.7.2 +  2.7.3
- + + + diff --git a/classentt_1_1Sink_3_01Ret_07Args_8_8_8_08_4.html b/classentt_1_1Sink_3_01Ret_07Args_8_8_8_08_4.html index 0f77fdf52..5148ae011 100644 --- a/classentt_1_1Sink_3_01Ret_07Args_8_8_8_08_4.html +++ b/classentt_1_1Sink_3_01Ret_07Args_8_8_8_08_4.html @@ -22,7 +22,7 @@ @@ -83,6 +83,10 @@ Public Member Functions + + + + @@ -91,6 +95,10 @@ Public Member Functions + + + + @@ -128,10 +136,10 @@ class entt::Sink< Ret(Args...)> -

Definition at line 130 of file sigh.hpp.

+

Definition at line 139 of file sigh.hpp.

Member Function Documentation

-

◆ connect() [1/2]

+

◆ connect() [1/3]

@@ -166,12 +174,60 @@ template<Ret(*)(Args...) Function>
-

Definition at line 162 of file sigh.hpp.

+

Definition at line 175 of file sigh.hpp.

-

◆ connect() [2/2]

+

◆ connect() [2/3]

+ +
+
+
+template<typename Ret , typename... Args>
+
+template<typename Class , Ret(Class::*)(Args...) const Member = &Class::receive>
+
connect()entt::Sink< Ret(Args...)>inline
connect(Class *instance)entt::Sink< Ret(Args...)>inline
disconnect()entt::Sink< Ret(Args...)>inline
connect(Class *instance)entt::Sink< Ret(Args...)>inline
disconnect()entt::Sink< Ret(Args...)>inline
disconnect(Class *instance)entt::Sink< Ret(Args...)>inline
disconnect(Class *instance)entt::Sink< Ret(Args...)>inline
disconnect(Class *instance)entt::Sink< Ret(Args...)>inline
disconnect()entt::Sink< Ret(Args...)>inline
EnTT -  2.7.2 +  2.7.3
void connect ()
 Connects a free function to a signal. More...
 
template<typename Class , Ret(Class::*)(Args...) const Member = &Class::receive>
void connect (Class *instance)
 Connects a member function for a given instance to a signal. More...
 
template<typename Class , Ret(Class::*)(Args...) Member = &Class::receive>
void connect (Class *instance)
 Connects a member function for a given instance to a signal. More...
void disconnect ()
 Disconnects a free function from a signal. More...
 
template<typename Class , Ret(Class::*)(Args...) const Member>
void disconnect (Class *instance)
 Disconnects the given member function from a signal. More...
 
template<typename Class , Ret(Class::*)(Args...) Member>
void disconnect (Class *instance)
 Disconnects the given member function from a signal. More...
+ + + + +
+ + + + + + + + +
void entt::Sink< Ret(Args...)>::connect (Class * instance)
+ 		+inline
+
+ +

Connects a member function for a given instance to a signal.

+

The signal isn't responsible for the connected object. Users must guarantee that the lifetime of the instance overcomes the one of the signal. On the other side, the signal handler performs checks to avoid multiple connections for the same member function of a given instance.

+
Template Parameters
+ + + +
ClassType of class to which the member function belongs.
MemberMember function to connect to the signal.
+
+
+
Parameters
+ + +
instanceA valid instance of type pointer to Class.
+
+
+ +

Definition at line 194 of file sigh.hpp.

+ +
+ + +

◆ connect() [3/3]

@@ -214,12 +270,12 @@ template<typename Class , Ret(Class::*)(Args...) Member = &Class::receive
-

Definition at line 181 of file sigh.hpp.

+

Definition at line 213 of file sigh.hpp.

-

◆ disconnect() [1/3]

+

◆ disconnect() [1/4]

@@ -253,12 +309,59 @@ template<Ret(*)(Args...) Function>
-

Definition at line 191 of file sigh.hpp.

+

Definition at line 223 of file sigh.hpp.

-

◆ disconnect() [2/3]

+

◆ disconnect() [2/4]

+ +
+
+
+template<typename Ret , typename... Args>
+
+template<typename Class , Ret(Class::*)(Args...) const Member>
+ + + + + +
+ + + + + + + + +
void entt::Sink< Ret(Args...)>::disconnect (Class * instance)
+ 		+inline
+
+ +

Disconnects the given member function from a signal.

+
Template Parameters
+ + + +
ClassType of class to which the member function belongs.
MemberMember function to connect to the signal.
+
+
+
Parameters
+ + +
instanceA valid instance of type pointer to Class.
+
+
+ +

Definition at line 235 of file sigh.hpp.

+ +
+
+ +

◆ disconnect() [3/4]

@@ -300,12 +403,12 @@ template<typename Class , Ret(Class::*)(Args...) Member>
-

Definition at line 203 of file sigh.hpp.

+

Definition at line 247 of file sigh.hpp.

-

◆ disconnect() [3/3]

+

◆ disconnect() [4/4]

@@ -346,7 +449,7 @@ template<typename Class >
-

Definition at line 214 of file sigh.hpp.

+

Definition at line 258 of file sigh.hpp.

diff --git a/classentt_1_1Snapshot-members.html b/classentt_1_1Snapshot-members.html index ea716314b..67783580c 100644 --- a/classentt_1_1Snapshot-members.html +++ b/classentt_1_1Snapshot-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1Snapshot.html b/classentt_1_1Snapshot.html index 4badf5c8b..7d41bf86a 100644 --- a/classentt_1_1Snapshot.html +++ b/classentt_1_1Snapshot.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -190,7 +190,7 @@ template<typename Component , typename Archive >
Returns
An object of this type to continue creating the snapshot.
-

Definition at line 144 of file snapshot.hpp.

+

Definition at line 148 of file snapshot.hpp.

@@ -239,7 +239,7 @@ template<typename... Component, typename Archive >
Returns
An object of this type to continue creating the snapshot.
-

Definition at line 171 of file snapshot.hpp.

+

Definition at line 175 of file snapshot.hpp.

@@ -307,7 +307,7 @@ template<typename... Component, typename Archive , typename It >
Returns
An object of this type to continue creating the snapshot.
-

Definition at line 193 of file snapshot.hpp.

+

Definition at line 197 of file snapshot.hpp.

@@ -514,7 +514,7 @@ template<typename Tag , typename Archive >
Returns
An object of this type to continue creating the snapshot.
-

Definition at line 210 of file snapshot.hpp.

+

Definition at line 214 of file snapshot.hpp.

@@ -563,7 +563,7 @@ template<typename... Tag, typename Archive >
Returns
An object of this type to continue creating the snapshot.
-

Definition at line 236 of file snapshot.hpp.

+

Definition at line 240 of file snapshot.hpp.

diff --git a/classentt_1_1SnapshotLoader-members.html b/classentt_1_1SnapshotLoader-members.html index 644479de6..7b01374e6 100644 --- a/classentt_1_1SnapshotLoader-members.html +++ b/classentt_1_1SnapshotLoader-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1SnapshotLoader.html b/classentt_1_1SnapshotLoader.html index 3b5998c4e..b715f0237 100644 --- a/classentt_1_1SnapshotLoader.html +++ b/classentt_1_1SnapshotLoader.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -134,7 +134,7 @@ class entt::SnapshotLoader< Entity > -

Definition at line 261 of file snapshot.hpp.

+

Definition at line 265 of file snapshot.hpp.

Member Function Documentation

◆ component()

@@ -181,7 +181,7 @@ template<typename... Component, typename Archive >
Returns
A valid loader to continue restoring data.
-

Definition at line 361 of file snapshot.hpp.

+

Definition at line 365 of file snapshot.hpp.

@@ -229,7 +229,7 @@ template<typename Archive >
Returns
A valid loader to continue restoring data.
-

Definition at line 341 of file snapshot.hpp.

+

Definition at line 345 of file snapshot.hpp.

@@ -277,7 +277,7 @@ template<typename Archive >
Returns
A valid loader to continue restoring data.
-

Definition at line 324 of file snapshot.hpp.

+

Definition at line 328 of file snapshot.hpp.

@@ -373,7 +373,7 @@ template<typename Entity > This functions helps to identify and destroy those entities.

Returns
A valid loader to continue restoring data.
-

Definition at line 399 of file snapshot.hpp.

+

Definition at line 403 of file snapshot.hpp.

@@ -422,7 +422,7 @@ template<typename... Tag, typename Archive >
Returns
A valid loader to continue restoring data.
-

Definition at line 382 of file snapshot.hpp.

+

Definition at line 386 of file snapshot.hpp.

diff --git a/classentt_1_1SparseSet.html b/classentt_1_1SparseSet.html index 6175a3020..840056a13 100644 --- a/classentt_1_1SparseSet.html +++ b/classentt_1_1SparseSet.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1SparseSet_3_01Entity_00_01Type_01_4-members.html b/classentt_1_1SparseSet_3_01Entity_00_01Type_01_4-members.html index ac42f045f..2f8c4538c 100644 --- a/classentt_1_1SparseSet_3_01Entity_00_01Type_01_4-members.html +++ b/classentt_1_1SparseSet_3_01Entity_00_01Type_01_4-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1SparseSet_3_01Entity_00_01Type_01_4.html b/classentt_1_1SparseSet_3_01Entity_00_01Type_01_4.html index b1aa374bb..796493cd9 100644 --- a/classentt_1_1SparseSet_3_01Entity_00_01Type_01_4.html +++ b/classentt_1_1SparseSet_3_01Entity_00_01Type_01_4.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -314,7 +314,7 @@ Internal data structures arrange elements to maximize performance. Because of th -

Definition at line 573 of file sparse_set.hpp.

+

Definition at line 576 of file sparse_set.hpp.

Member Function Documentation

◆ begin() [1/2]

@@ -346,7 +346,7 @@ template<typename Entity , typename Type >
Note
Input iterators stay true to the order imposed by a call to either sort or respect.
Returns
An iterator to the first instance of the given type.
-

Definition at line 785 of file sparse_set.hpp.

+

Definition at line 790 of file sparse_set.hpp.

@@ -380,7 +380,7 @@ template<typename Entity , typename Type >
Note
Input iterators stay true to the order imposed by a call to either sort or respect.
Returns
An iterator to the first instance of the given type.
-

Definition at line 801 of file sparse_set.hpp.

+

Definition at line 806 of file sparse_set.hpp.

@@ -414,7 +414,7 @@ template<typename Entity , typename Type >
Note
Input iterators stay true to the order imposed by a call to either sort or respect.
Returns
An iterator to the first instance of the given type.
-

Definition at line 768 of file sparse_set.hpp.

+

Definition at line 773 of file sparse_set.hpp.

@@ -448,7 +448,7 @@ template<typename Entity , typename Type >
Note
Input iterators stay true to the order imposed by a call to either sort or respect.
Returns
An iterator to the element following the last instance of the given type.
-

Definition at line 820 of file sparse_set.hpp.

+

Definition at line 825 of file sparse_set.hpp.

@@ -510,7 +510,7 @@ template<typename... Args>
Returns
The object associated to the entity.
-

Definition at line 932 of file sparse_set.hpp.

+

Definition at line 937 of file sparse_set.hpp.

@@ -572,7 +572,7 @@ template<typename... Args>
Returns
The object associated to the entity.
-

Definition at line 960 of file sparse_set.hpp.

+

Definition at line 965 of file sparse_set.hpp.

@@ -614,7 +614,7 @@ template<typename Entity , typename Type >

Reimplemented from entt::SparseSet< Entity >.

-

Definition at line 977 of file sparse_set.hpp.

+

Definition at line 982 of file sparse_set.hpp.

@@ -648,7 +648,7 @@ template<typename Entity , typename Type >
Note
Input iterators stay true to the order imposed by a call to either sort or respect.
Returns
An iterator to the element following the last instance of the given type.
-

Definition at line 838 of file sparse_set.hpp.

+

Definition at line 843 of file sparse_set.hpp.

@@ -682,7 +682,7 @@ template<typename Entity , typename Type >
Note
Input iterators stay true to the order imposed by a call to either sort or respect.
Returns
An iterator to the element following the last instance of the given type.
-

Definition at line 856 of file sparse_set.hpp.

+

Definition at line 861 of file sparse_set.hpp.

@@ -723,7 +723,7 @@ template<typename Entity , typename Type >
Returns
The object associated to the entity.
-

Definition at line 890 of file sparse_set.hpp.

+

Definition at line 895 of file sparse_set.hpp.

@@ -764,7 +764,7 @@ template<typename Entity , typename Type >
Returns
The object associated to the entity.
-

Definition at line 906 of file sparse_set.hpp.

+

Definition at line 911 of file sparse_set.hpp.

@@ -865,7 +865,7 @@ template<typename Entity , typename Type >
Returns
A reference to the requested element.
-

Definition at line 865 of file sparse_set.hpp.

+

Definition at line 870 of file sparse_set.hpp.

@@ -904,7 +904,7 @@ template<typename Entity , typename Type >
Returns
A reference to the requested element.
-

Definition at line 874 of file sparse_set.hpp.

+

Definition at line 879 of file sparse_set.hpp.

@@ -938,7 +938,7 @@ template<typename Entity , typename Type >
Note
There are no guarantees on the order, even though either sort or respect has been previously invoked. Internal data structures arrange elements to maximize performance. Accessing them directly gives a performance boost but less guarantees. Use begin and end if you want to iterate the sparse set in the expected order.
Returns
A pointer to the array of objects.
-

Definition at line 733 of file sparse_set.hpp.

+

Definition at line 738 of file sparse_set.hpp.

@@ -972,7 +972,7 @@ template<typename Entity , typename Type >
Note
There are no guarantees on the order, even though either sort or respect has been previously invoked. Internal data structures arrange elements to maximize performance. Accessing them directly gives a performance boost but less guarantees. Use begin and end if you want to iterate the sparse set in the expected order.
Returns
A pointer to the array of objects.
-

Definition at line 752 of file sparse_set.hpp.

+

Definition at line 757 of file sparse_set.hpp.

@@ -1011,7 +1011,7 @@ template<typename Entity , typename Type > -

Definition at line 713 of file sparse_set.hpp.

+

Definition at line 718 of file sparse_set.hpp.

@@ -1053,7 +1053,7 @@ template<typename Entity , typename Type > -

Definition at line 1075 of file sparse_set.hpp.

+

Definition at line 1080 of file sparse_set.hpp.

@@ -1130,7 +1130,7 @@ template<typename Compare , typename Sort = StdSort, typename... Args> -

Definition at line 1028 of file sparse_set.hpp.

+

Definition at line 1033 of file sparse_set.hpp.

diff --git a/classentt_1_1SparseSet_3_01Entity_01_4-members.html b/classentt_1_1SparseSet_3_01Entity_01_4-members.html index 870d7297b..a0346757b 100644 --- a/classentt_1_1SparseSet_3_01Entity_01_4-members.html +++ b/classentt_1_1SparseSet_3_01Entity_01_4-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1SparseSet_3_01Entity_01_4.html b/classentt_1_1SparseSet_3_01Entity_01_4.html index 52d17d155..675c39976 100644 --- a/classentt_1_1SparseSet_3_01Entity_01_4.html +++ b/classentt_1_1SparseSet_3_01Entity_01_4.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -245,7 +245,7 @@ template<typename Entity >
Note
Input iterators stay true to the order imposed by a call to respect.
Returns
An iterator to the first entity of the internal packed array.
-

Definition at line 296 of file sparse_set.hpp.

+

Definition at line 298 of file sparse_set.hpp.

@@ -279,7 +279,7 @@ template<typename Entity >
Note
Input iterators stay true to the order imposed by a call to respect.
Returns
An iterator to the first entity of the internal packed array.
-

Definition at line 312 of file sparse_set.hpp.

+

Definition at line 314 of file sparse_set.hpp.

@@ -311,7 +311,7 @@ template<typename Entity >

Returns the number of elements that a sparse set has currently allocated space for.

Returns
Capacity of the sparse set.
-

Definition at line 208 of file sparse_set.hpp.

+

Definition at line 210 of file sparse_set.hpp.

@@ -345,7 +345,7 @@ template<typename Entity >
Note
Input iterators stay true to the order imposed by a call to respect.
Returns
An iterator to the first entity of the internal packed array.
-

Definition at line 279 of file sparse_set.hpp.

+

Definition at line 281 of file sparse_set.hpp.

@@ -379,7 +379,7 @@ template<typename Entity >
Note
Input iterators stay true to the order imposed by a call to respect.
Returns
An iterator to the element following the last entity of the internal packed array.
-

Definition at line 329 of file sparse_set.hpp.

+

Definition at line 331 of file sparse_set.hpp.

@@ -419,7 +419,7 @@ template<typename Entity > -

Definition at line 439 of file sparse_set.hpp.

+

Definition at line 442 of file sparse_set.hpp.

@@ -453,7 +453,7 @@ template<typename Entity >
Note
There are no guarantees on the order, even though respect has been previously invoked. Internal data structures arrange elements to maximize performance. Accessing them directly gives a performance boost but less guarantees. Use begin and end if you want to iterate the sparse set in the expected order.
Returns
A pointer to the internal packed array.
-

Definition at line 263 of file sparse_set.hpp.

+

Definition at line 265 of file sparse_set.hpp.

@@ -495,7 +495,7 @@ template<typename Entity >

Reimplemented in entt::SparseSet< Entity, Type >.

-

Definition at line 463 of file sparse_set.hpp.

+

Definition at line 466 of file sparse_set.hpp.

@@ -527,7 +527,7 @@ template<typename Entity >

Checks whether a sparse set is empty.

Returns
True if the sparse set is empty, false otherwise.
-

Definition at line 244 of file sparse_set.hpp.

+

Definition at line 246 of file sparse_set.hpp.

@@ -561,7 +561,7 @@ template<typename Entity >
Note
Input iterators stay true to the order imposed by a call to respect.
Returns
An iterator to the element following the last entity of the internal packed array.
-

Definition at line 346 of file sparse_set.hpp.

+

Definition at line 348 of file sparse_set.hpp.

@@ -595,7 +595,7 @@ template<typename Entity >
Note
Input iterators stay true to the order imposed by a call to respect.
Returns
An iterator to the element following the last entity of the internal packed array.
-

Definition at line 363 of file sparse_set.hpp.

+

Definition at line 365 of file sparse_set.hpp.

@@ -628,7 +628,7 @@ template<typename Entity >

The extent of a sparse set is also the size of the internal sparse array. There is no guarantee that the internal packed array has the same size. Usually the size of the internal sparse array is equal or greater than the one of the internal packed array.

Returns
Extent of the sparse set.
-

Definition at line 222 of file sparse_set.hpp.

+

Definition at line 224 of file sparse_set.hpp.

@@ -671,7 +671,7 @@ template<typename Entity >
Returns
True if the sparse set contains the entity, false otherwise.
-

Definition at line 404 of file sparse_set.hpp.

+

Definition at line 406 of file sparse_set.hpp.

@@ -712,7 +712,7 @@ template<typename Entity >
Returns
The position of the entity in the sparse set.
-

Definition at line 423 of file sparse_set.hpp.

+

Definition at line 425 of file sparse_set.hpp.

@@ -751,7 +751,7 @@ template<typename Entity >
Returns
True if the sparse set contains the entity, false otherwise.
-

Definition at line 381 of file sparse_set.hpp.

+

Definition at line 383 of file sparse_set.hpp.

@@ -852,7 +852,7 @@ template<typename Entity >
Returns
A reference to the requested element.
-

Definition at line 372 of file sparse_set.hpp.

+

Definition at line 374 of file sparse_set.hpp.

@@ -891,7 +891,7 @@ template<typename Entity > -

Definition at line 199 of file sparse_set.hpp.

+

Definition at line 201 of file sparse_set.hpp.

@@ -933,7 +933,7 @@ template<typename Entity > -

Definition at line 517 of file sparse_set.hpp.

+

Definition at line 520 of file sparse_set.hpp.

@@ -966,7 +966,7 @@ template<typename Entity >

The number of elements is also the size of the internal packed array. There is no guarantee that the internal sparse array has the same size. Usually the size of the internal sparse array is equal or greater than the one of the internal packed array.

Returns
Number of elements.
-

Definition at line 236 of file sparse_set.hpp.

+

Definition at line 238 of file sparse_set.hpp.

@@ -1018,7 +1018,7 @@ template<typename Entity > -

Definition at line 489 of file sparse_set.hpp.

+

Definition at line 492 of file sparse_set.hpp.

diff --git a/classentt_1_1View-members.html b/classentt_1_1View-members.html index 9b0f3cd11..12e829c09 100644 --- a/classentt_1_1View-members.html +++ b/classentt_1_1View-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1View.html b/classentt_1_1View.html index 01720714a..94e867c44 100644 --- a/classentt_1_1View.html +++ b/classentt_1_1View.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1View_3_01Entity_00_01Component_01_4-members.html b/classentt_1_1View_3_01Entity_00_01Component_01_4-members.html index c39ebdb07..53b7f9abc 100644 --- a/classentt_1_1View_3_01Entity_00_01Component_01_4-members.html +++ b/classentt_1_1View_3_01Entity_00_01Component_01_4-members.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classentt_1_1View_3_01Entity_00_01Component_01_4.html b/classentt_1_1View_3_01Entity_00_01Component_01_4.html index 9d7c6f954..5d6811049 100644 --- a/classentt_1_1View_3_01Entity_00_01Component_01_4.html +++ b/classentt_1_1View_3_01Entity_00_01Component_01_4.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/classes.html b/classes.html index 0245a9c47..4f494d07a 100644 --- a/classes.html +++ b/classes.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -63,7 +63,7 @@ $(function() {
Class Index
-
a | b | c | d | e | f | h | i | m | o | p | r | s | t | v
+
a | c | d | e | f | h | i | m | o | p | r | s | t | v
- - + -
  a  
  e  
@@ -71,11 +71,10 @@ $(function() {
  m  
Registry (entt)   SparseSet (entt)   
Actor (entt)   Emitter (entt)   ResourceCache (entt)   SparseSet< Entity > (entt)   
  b  
-		entt_traits (entt)   Monostate (entt)   ResourceHandle (entt)   SparseSet< Entity, Type > (entt)   
entt_traits< std::uint16_t > (entt)   
  o  
+
Attachee (entt)   entt_traits (entt)   Monostate (entt)   ResourceHandle (entt)   SparseSet< Entity, Type > (entt)   
Attachee< Entity > (entt)   entt_traits< std::uint16_t > (entt)   
  o  
ResourceLoader (entt)   StdSort (entt)   
break_t (entt)   entt_traits< std::uint32_t > (entt)   RuntimeView (entt)   
  t  
+
Attachee< Entity, Type > (entt)   entt_traits< std::uint32_t > (entt)   RuntimeView (entt)   
  t  
  c  
entt_traits< std::uint64_t > (entt)   OneShotBubbleSort (entt)   
  s  
@@ -99,7 +98,7 @@ $(function() {
raw_t (entt)   
-
a | b | c | d | e | f | h | i | m | o | p | r | s | t | v
+
a | c | d | e | f | h | i | m | o | p | r | s | t | v
diff --git a/config_8h_source.html b/config_8h_source.html index 0dc3705d9..b9835d9b7 100644 --- a/config_8h_source.html +++ b/config_8h_source.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/core_8md_source.html b/core_8md_source.html new file mode 100644 index 000000000..6af4d70bc --- /dev/null +++ b/core_8md_source.html @@ -0,0 +1,74 @@ + + + + + + + +EnTT: docs/core.md Source File + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.3 +
+
+
+ + + + + + + +
+ +
+
+ + +
+ +
+ +
+
+
docs/core.md
+
+
+
1 # Crash Course: core functionalities
2 
3 <!--
4 @cond TURN_OFF_DOXYGEN
5 -->
6 # Table of Contents
7 
8 * [Introduction](#introduction)
9 * [Compile-time identifiers](#compile-time-identifiers)
10 * [Runtime identifiers](#runtime-identifiers)
11 * [Hashed strings](#hashed-strings)
12  * [Conflicts](#conflicts)
13 * [Monostate](#monostate)
14 <!--
15 @endcond TURN_OFF_DOXYGEN
16 -->
17 
18 # Introduction
19 
20 `EnTT` comes with a bunch of core functionalities mostly used by the other parts
21 of the library itself.<br/>
22 Hardly users will include these features in their code, but it's worth
23 describing what `EnTT` offers so as not to reinvent the wheel in case of need.
24 
25 # Compile-time identifiers
26 
27 Sometimes it's useful to be able to give unique identifiers to types at
28 compile-time.<br/>
29 There are plenty of different solutions out there and I could have used one of
30 them. However, I decided to spend my time to define a compact and versatile tool
31 that fully embraces what the modern C++ has to offer.
32 
33 The _result of my efforts_ is the `Identifier` class template:
34 
35 ```cpp
36 #include <ident.hpp>
37 
38 // defines the identifiers for the given types
39 using ID = entt::Identifier<AType, AnotherType>;
40 
41 // ...
42 
43 switch(aTypeIdentifier) {
44 case ID::get<AType>():
45  // ...
46  break;
47 case ID::get<AnotherType>():
48  // ...
49  break;
50 default:
51  // ...
52 }
53 ```
54 
55 This is all what the class template has to offer: a static `get` member function
56 that returns a numerical identifier for the given type. It can be used in any
57 context where constant expressions are required.
58 
59 As long as the list remains unchanged, identifiers are also guaranteed to be the
60 same for every run. In case they have been used in a production environment and
61 a type has to be removed, one can just use a placeholder to left the other
62 identifiers unchanged:
63 
64 ```cpp
65 template<typename> struct IgnoreType {};
66 
67 using ID = entt::Identifier<
68  ATypeStillValid,
69  IgnoreType<ATypeNoLongerValid>,
70  AnotherTypeStillValid
71 >;
72 ```
73 
74 A bit ugly to see, but it works at least.
75 
76 # Runtime identifiers
77 
78 Sometimes it's useful to be able to give unique identifiers to types at
79 runtime.<br/>
80 There are plenty of different solutions out there and I could have used one of
81 them. In fact, I adapted the most common one to my requirements and used it
82 extensively within the entire library.
83 
84 It's the `Family` class. Here is an example of use directly from the
85 entity-component system:
86 
87 ```cpp
88 using component_family = entt::Family<struct InternalRegistryComponentFamily>;
89 
90 // ...
91 
92 template<typename Component>
93 component_type component() const noexcept {
94  return component_family::type<Component>();
95 }
96 ```
97 
98 This is all what a _family_ has to offer: a `type` member function that returns
99 a numerical identifier for the given type.
100 
101 Please, note that identifiers aren't guaranteed to be the same for every run.
102 Indeed it mostly depends on the flow of execution.
103 
104 # Hashed strings
105 
106 A hashed string is a zero overhead resource identifier. Users can use
107 human-readable identifiers in the codebase while using their numeric
108 counterparts at runtime, thus without affecting performance.<br/>
109 The class has an implicit `constexpr` constructor that chews a bunch of
110 characters. Once created, all what one can do with it is getting back the
111 original string or converting it into a number.<br/>
112 The good part is that a hashed string can be used wherever a constant expression
113 is required and no _string-to-number_ conversion will take place at runtime if
114 used carefully.
115 
116 Example of use:
117 
118 ```cpp
119 auto load(entt::HashedString::hash_type resource) {
120  // uses the numeric representation of the resource to load and return it
121 }
122 
123 auto resource = load(entt::HashedString{"gui/background"});
124 ```
125 
126 There is also a _user defined literal_ dedicated to hashed strings to make them
127 more user-friendly:
128 
129 ```cpp
130 constexpr auto str = "text"_hs;
131 ```
132 
133 ## Conflicts
134 
135 The hashed string class uses internally FNV-1a to compute the numeric
136 counterpart of a string. Because of the _pigeonhole principle_, conflicts are
137 possible. This is a fact.<br/>
138 There is no silver bullet to solve the problem of conflicts when dealing with
139 hashing functions. In this case, the best solution seemed to be to give up.
140 That's all.<br/>
141 After all, human-readable resource identifiers aren't something strictly defined
142 and over which users have not the control. Choosing a slightly different
143 identifier is probably the best solution to make the conflict disappear in this
144 case.
145 
146 # Monostate
147 
148 The monostate pattern is often presented as an alternative to a singleton based
149 configuration system. This is exactly its purpose in `EnTT`. Moreover, this
150 implementation is thread safe by design (hopefully).<br/>
151 Keys are represented by hashed strings, values are basic types like `int`s or
152 `bool`s. Values of different types can be associated to each key, even more than
153 one at a time. Because of this, users must pay attention to use the same type
154 both during an assignment and when they try to read back their data. Otherwise,
155 they will probably incur in unexpected results.
156 
157 Example of use:
158 
159 ```cpp
160 entt::Monostate<entt::HashedString{"mykey"}>{} = true;
161 entt::Monostate<"mykey"_hs>{} = 42;
162 
163 // ...
164 
165 const bool b = entt::Monostate<"mykey"_hs>{};
166 const int i = entt::Monostate<entt::HashedString{"mykey"}>{};
167 ```
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/delegate_8hpp_source.html b/delegate_8hpp_source.html index b318a50e0..84bc0b1c8 100644 --- a/delegate_8hpp_source.html +++ b/delegate_8hpp_source.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -67,16 +67,16 @@ $(function() {
delegate.hpp
-
1 #ifndef ENTT_SIGNAL_DELEGATE_HPP
2 #define ENTT_SIGNAL_DELEGATE_HPP
3 
4 
5 #include <utility>
6 #include "../config/config.h"
7 
8 
9 namespace entt {
10 
11 
18 template<typename>
19 class Delegate;
20 
21 
35 template<typename Ret, typename... Args>
36 class Delegate<Ret(Args...)> final {
37  using proto_fn_type = Ret(void *, Args...);
38  using stub_type = std::pair<void *, proto_fn_type *>;
39 
40  template<Ret(*Function)(Args...)>
41  static Ret proto(void *, Args... args) {
42  return (Function)(args...);
43  }
44 
45  template<typename Class, Ret(Class:: *Member)(Args...)>
46  static Ret proto(void *instance, Args... args) {
47  return (static_cast<Class *>(instance)->*Member)(args...);
48  }
49 
50 public:
52  Delegate() ENTT_NOEXCEPT
53  : stub{}
54  {}
55 
60  bool empty() const ENTT_NOEXCEPT {
61  // no need to test also stub.first
62  return !stub.second;
63  }
64 
69  template<Ret(*Function)(Args...)>
70  void connect() ENTT_NOEXCEPT {
71  stub = std::make_pair(nullptr, &proto<Function>);
72  }
73 
85  template<typename Class, Ret(Class:: *Member)(Args...)>
86  void connect(Class *instance) ENTT_NOEXCEPT {
87  stub = std::make_pair(instance, &proto<Class, Member>);
88  }
89 
95  void reset() ENTT_NOEXCEPT {
96  stub.second = nullptr;
97  }
98 
104  Ret operator()(Args... args) const {
105  return stub.second(stub.first, args...);
106  }
107 
116  bool operator==(const Delegate<Ret(Args...)> &other) const ENTT_NOEXCEPT {
117  return stub.first == other.stub.first && stub.second == other.stub.second;
118  }
119 
120 private:
121  stub_type stub;
122 };
123 
124 
136 template<typename Ret, typename... Args>
137 bool operator!=(const Delegate<Ret(Args...)> &lhs, const Delegate<Ret(Args...)> &rhs) ENTT_NOEXCEPT {
138  return !(lhs == rhs);
139 }
140 
141 
142 }
143 
144 
145 #endif // ENTT_SIGNAL_DELEGATE_HPP
entt::operator!=
constexpr bool operator!=(const HashedString &lhs, const HashedString &rhs) ENTT_NOEXCEPT
Compares two hashed strings.
Definition: hashed_string.hpp:103
-
entt::Delegate< Ret(Args...)>::connect
void connect() ENTT_NOEXCEPT
Binds a free function to a delegate.
Definition: delegate.hpp:70
-
entt::Delegate< Ret(Args...)>::operator()
Ret operator()(Args... args) const
Triggers a delegate.
Definition: delegate.hpp:104
+
1 #ifndef ENTT_SIGNAL_DELEGATE_HPP
2 #define ENTT_SIGNAL_DELEGATE_HPP
3 
4 
5 #include <utility>
6 #include "../config/config.h"
7 
8 
9 namespace entt {
10 
11 
18 template<typename>
19 class Delegate;
20 
21 
35 template<typename Ret, typename... Args>
36 class Delegate<Ret(Args...)> final {
37  using proto_fn_type = Ret(void *, Args...);
38  using stub_type = std::pair<void *, proto_fn_type *>;
39 
40  template<Ret(*Function)(Args...)>
41  static Ret proto(void *, Args... args) {
42  return (Function)(args...);
43  }
44 
45  template<typename Class, Ret(Class:: *Member)(Args...) const>
46  static Ret proto(void *instance, Args... args) {
47  return (static_cast<const Class *>(instance)->*Member)(args...);
48  }
49 
50  template<typename Class, Ret(Class:: *Member)(Args...)>
51  static Ret proto(void *instance, Args... args) {
52  return (static_cast<Class *>(instance)->*Member)(args...);
53  }
54 
55 public:
57  Delegate() ENTT_NOEXCEPT
58  : stub{}
59  {}
60 
65  bool empty() const ENTT_NOEXCEPT {
66  // no need to test also stub.first
67  return !stub.second;
68  }
69 
74  template<Ret(*Function)(Args...)>
75  void connect() ENTT_NOEXCEPT {
76  stub = std::make_pair(nullptr, &proto<Function>);
77  }
78 
90  template<typename Class, Ret(Class:: *Member)(Args...) const>
91  void connect(Class *instance) ENTT_NOEXCEPT {
92  stub = std::make_pair(instance, &proto<Class, Member>);
93  }
94 
106  template<typename Class, Ret(Class:: *Member)(Args...)>
107  void connect(Class *instance) ENTT_NOEXCEPT {
108  stub = std::make_pair(instance, &proto<Class, Member>);
109  }
110 
116  void reset() ENTT_NOEXCEPT {
117  stub.second = nullptr;
118  }
119 
125  Ret operator()(Args... args) const {
126  return stub.second(stub.first, args...);
127  }
128 
137  bool operator==(const Delegate<Ret(Args...)> &other) const ENTT_NOEXCEPT {
138  return stub.first == other.stub.first && stub.second == other.stub.second;
139  }
140 
141 private:
142  stub_type stub;
143 };
144 
145 
157 template<typename Ret, typename... Args>
158 bool operator!=(const Delegate<Ret(Args...)> &lhs, const Delegate<Ret(Args...)> &rhs) ENTT_NOEXCEPT {
159  return !(lhs == rhs);
160 }
161 
162 
163 }
164 
165 
166 #endif // ENTT_SIGNAL_DELEGATE_HPP
entt::operator!=
constexpr bool operator!=(const HashedString &lhs, const HashedString &rhs) ENTT_NOEXCEPT
Compares two hashed strings.
Definition: hashed_string.hpp:103
+
entt::Delegate< Ret(Args...)>::connect
void connect() ENTT_NOEXCEPT
Binds a free function to a delegate.
Definition: delegate.hpp:75
+
entt::Delegate< Ret(Args...)>::operator()
Ret operator()(Args... args) const
Triggers a delegate.
Definition: delegate.hpp:125
entt
EnTT default namespace.
Definition: algorithm.hpp:10
entt::Delegate
Basic delegate implementation.
Definition: delegate.hpp:19
-
entt::Delegate< Ret(Args...)>::Delegate
Delegate() ENTT_NOEXCEPT
Default constructor.
Definition: delegate.hpp:52
-
entt::Delegate< Ret(Args...)>::operator==
bool operator==(const Delegate< Ret(Args...)> &other) const ENTT_NOEXCEPT
Checks if the contents of the two delegates are different.
Definition: delegate.hpp:116
-
entt::Delegate< Ret(Args...)>::empty
bool empty() const ENTT_NOEXCEPT
Checks whether a delegate actually stores a listener.
Definition: delegate.hpp:60
-
entt::Delegate< Ret(Args...)>::reset
void reset() ENTT_NOEXCEPT
Resets a delegate.
Definition: delegate.hpp:95
-
entt::Delegate< Ret(Args...)>::connect
void connect(Class *instance) ENTT_NOEXCEPT
Connects a member function for a given instance to a delegate.
Definition: delegate.hpp:86
+
entt::Delegate< Ret(Args...)>::Delegate
Delegate() ENTT_NOEXCEPT
Default constructor.
Definition: delegate.hpp:57
+
entt::Delegate< Ret(Args...)>::operator==
bool operator==(const Delegate< Ret(Args...)> &other) const ENTT_NOEXCEPT
Checks if the contents of the two delegates are different.
Definition: delegate.hpp:137
+
entt::Delegate< Ret(Args...)>::empty
bool empty() const ENTT_NOEXCEPT
Checks whether a delegate actually stores a listener.
Definition: delegate.hpp:65
+
entt::Delegate< Ret(Args...)>::reset
void reset() ENTT_NOEXCEPT
Resets a delegate.
Definition: delegate.hpp:116
+
entt::Delegate< Ret(Args...)>::connect
void connect(Class *instance) ENTT_NOEXCEPT
Connects a member function for a given instance to a delegate.
Definition: delegate.hpp:91
diff --git a/dir_66e9674e8206a335795995fa32a03c91.html b/dir_66e9674e8206a335795995fa32a03c91.html index 5149c4bc7..6eb5887fc 100644 --- a/dir_66e9674e8206a335795995fa32a03c91.html +++ b/dir_66e9674e8206a335795995fa32a03c91.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/dir_68267d1309a1af8e8297ef4c3efbcdba.html b/dir_68267d1309a1af8e8297ef4c3efbcdba.html index b37549885..0b3d64bdc 100644 --- a/dir_68267d1309a1af8e8297ef4c3efbcdba.html +++ b/dir_68267d1309a1af8e8297ef4c3efbcdba.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/dir_721f6154dba3c88bcdead5f446bce319.html b/dir_721f6154dba3c88bcdead5f446bce319.html index 47e5be0d4..0160c8243 100644 --- a/dir_721f6154dba3c88bcdead5f446bce319.html +++ b/dir_721f6154dba3c88bcdead5f446bce319.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/dir_7929ab29d3f740cf727ccbd263321562.html b/dir_7929ab29d3f740cf727ccbd263321562.html index 54a1d5f2b..0eaeaa7e3 100644 --- a/dir_7929ab29d3f740cf727ccbd263321562.html +++ b/dir_7929ab29d3f740cf727ccbd263321562.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/dir_85dbee8884f1b3a817fa7eff8dff73ec.html b/dir_85dbee8884f1b3a817fa7eff8dff73ec.html index 103c296cc..45c9f9778 100644 --- a/dir_85dbee8884f1b3a817fa7eff8dff73ec.html +++ b/dir_85dbee8884f1b3a817fa7eff8dff73ec.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/dir_a53318306f6ac0f7fe657839abd543ab.html b/dir_a53318306f6ac0f7fe657839abd543ab.html index 31f61cc6f..0de5b30f0 100644 --- a/dir_a53318306f6ac0f7fe657839abd543ab.html +++ b/dir_a53318306f6ac0f7fe657839abd543ab.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/dir_b64489a1e8130d5ebf6d86d282f500f0.html b/dir_b64489a1e8130d5ebf6d86d282f500f0.html index 063a9b628..027c8db2a 100644 --- a/dir_b64489a1e8130d5ebf6d86d282f500f0.html +++ b/dir_b64489a1e8130d5ebf6d86d282f500f0.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/dir_c5715f7ee899854a669b87bbaa642de0.html b/dir_c5715f7ee899854a669b87bbaa642de0.html new file mode 100644 index 000000000..ca77cfa03 --- /dev/null +++ b/dir_c5715f7ee899854a669b87bbaa642de0.html @@ -0,0 +1,78 @@ + + + + + + + +EnTT: src/entt/meta Directory Reference + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.2 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+
meta Directory Reference
+
+
+
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/dir_de8f4e6ba3f54a2a21309f742e93a373.html b/dir_de8f4e6ba3f54a2a21309f742e93a373.html index 2d5eac20a..f6db24e45 100644 --- a/dir_de8f4e6ba3f54a2a21309f742e93a373.html +++ b/dir_de8f4e6ba3f54a2a21309f742e93a373.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/dir_e3a7bb56c55e5c2286e2fe96e197d4f5.html b/dir_e3a7bb56c55e5c2286e2fe96e197d4f5.html index 414855302..25fdac6ed 100644 --- a/dir_e3a7bb56c55e5c2286e2fe96e197d4f5.html +++ b/dir_e3a7bb56c55e5c2286e2fe96e197d4f5.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/dispatcher_8hpp_source.html b/dispatcher_8hpp_source.html index 7992a04d3..c40667af7 100644 --- a/dispatcher_8hpp_source.html +++ b/dispatcher_8hpp_source.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -75,7 +75,7 @@ $(function() {
entt::Dispatcher::trigger
void trigger(Args &&... args)
Triggers an immediate event of the given type.
Definition: dispatcher.hpp:130
entt::Dispatcher
Basic dispatcher implementation.
Definition: dispatcher.hpp:35
entt::Dispatcher::update
void update()
Delivers all the pending events of the given type.
Definition: dispatcher.hpp:159
-
entt::SigH
Unmanaged signal handler declaration.
Definition: sigh.hpp:112
+
entt::SigH
Unmanaged signal handler declaration.
Definition: sigh.hpp:121
entt::Family
Dynamic identifier generator.
Definition: family.hpp:22
diff --git a/emitter_8hpp_source.html b/emitter_8hpp_source.html index 96106a58e..fc6e1d69e 100644 --- a/emitter_8hpp_source.html +++ b/emitter_8hpp_source.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/entity_8hpp_source.html b/entity_8hpp_source.html index 160e27518..930b878aa 100644 --- a/entity_8hpp_source.html +++ b/entity_8hpp_source.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -67,9 +67,10 @@ $(function() {
entity.hpp
-
1 #ifndef ENTT_ENTITY_ENTITY_HPP
2 #define ENTT_ENTITY_ENTITY_HPP
3 
4 
5 #include "../config/config.h"
6 #include "entt_traits.hpp"
7 
8 
9 namespace entt {
10 
11 
12 namespace internal {
13 
14 
21 template<typename Entity>
22 static constexpr auto null = ~typename entt_traits<Entity>::entity_type{};
23 
24 
25 struct Null {
26  explicit constexpr Null() = default;
27 
28  template<typename Entity>
29  constexpr operator Entity() const ENTT_NOEXCEPT {
30  return null<Entity>;
31  }
32 
33  constexpr bool operator==(Null) const ENTT_NOEXCEPT {
34  return true;
35  }
36 
37  constexpr bool operator!=(Null) const ENTT_NOEXCEPT {
38  return false;
39  }
40 
41  template<typename Entity>
42  constexpr bool operator==(const Entity entity) const ENTT_NOEXCEPT {
43  return entity == null<Entity>;
44  }
45 
46  template<typename Entity>
47  constexpr bool operator!=(const Entity entity) const ENTT_NOEXCEPT {
48  return entity != null<Entity>;
49  }
50 };
51 
52 
53 template<typename Entity>
54 constexpr bool operator==(const Entity entity, Null null) ENTT_NOEXCEPT {
55  return null == entity;
56 }
57 
58 
59 template<typename Entity>
60 constexpr bool operator!=(const Entity entity, Null null) ENTT_NOEXCEPT {
61  return null != entity;
62 }
63 
64 
71 }
72 
73 
81 constexpr auto null = internal::Null{};
82 
83 
84 }
85 
86 
87 #endif // ENTT_ENTITY_ENTITY_HPP
entt::operator!=
constexpr bool operator!=(const HashedString &lhs, const HashedString &rhs) ENTT_NOEXCEPT
Compares two hashed strings.
Definition: hashed_string.hpp:103
+
1 #ifndef ENTT_ENTITY_ENTITY_HPP
2 #define ENTT_ENTITY_ENTITY_HPP
3 
4 
5 #include "../config/config.h"
6 #include "entt_traits.hpp"
7 
8 
9 namespace entt {
10 
11 
18 namespace internal {
19 
20 
21 struct Null {
22  explicit constexpr Null() = default;
23 
24  template<typename Entity>
25  constexpr operator Entity() const ENTT_NOEXCEPT {
26  using traits_type = entt::entt_traits<Entity>;
27  return traits_type::entity_mask | (traits_type::version_mask << traits_type::entity_shift);
28  }
29 
30  constexpr bool operator==(Null) const ENTT_NOEXCEPT {
31  return true;
32  }
33 
34  constexpr bool operator!=(Null) const ENTT_NOEXCEPT {
35  return false;
36  }
37 
38  template<typename Entity>
39  constexpr bool operator==(const Entity entity) const ENTT_NOEXCEPT {
40  return entity == static_cast<Entity>(*this);
41  }
42 
43  template<typename Entity>
44  constexpr bool operator!=(const Entity entity) const ENTT_NOEXCEPT {
45  return entity != static_cast<Entity>(*this);
46  }
47 };
48 
49 
50 template<typename Entity>
51 constexpr bool operator==(const Entity entity, Null null) ENTT_NOEXCEPT {
52  return null == entity;
53 }
54 
55 
56 template<typename Entity>
57 constexpr bool operator!=(const Entity entity, Null null) ENTT_NOEXCEPT {
58  return null != entity;
59 }
60 
61 
62 }
63 
64 
78 constexpr auto null = internal::Null{};
79 
80 
81 }
82 
83 
84 #endif // ENTT_ENTITY_ENTITY_HPP
entt::operator!=
constexpr bool operator!=(const HashedString &lhs, const HashedString &rhs) ENTT_NOEXCEPT
Compares two hashed strings.
Definition: hashed_string.hpp:103
entt
EnTT default namespace.
Definition: algorithm.hpp:10
-
entt::null
constexpr auto null
Null entity.
Definition: entity.hpp:81
+
entt::null
constexpr auto null
Null entity.
Definition: entity.hpp:78
+
entt::entt_traits
Entity traits.
Definition: entt_traits.hpp:18
diff --git a/entity_8md_source.html b/entity_8md_source.html new file mode 100644 index 000000000..d339f5dba --- /dev/null +++ b/entity_8md_source.html @@ -0,0 +1,74 @@ + + + + + + + +EnTT: docs/entity.md Source File + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.3 +
+
+
+ + + + + + + +
+ +
+
+ + +
+ +
+ +
+
+
docs/entity.md
+
+
+
1 # Crash Course: entity-component system
2 
3 <!--
4 @cond TURN_OFF_DOXYGEN
5 -->
6 # Table of Contents
7 
8 * [Introduction](#introduction)
9 * [Design choices](#design-choices)
10  * [A bitset-free entity-component system](#a-bitset-free-entity-component-system)
11  * [Pay per use](#pay-per-use)
12 * [Vademecum](#vademecum)
13 * [The Registry, the Entity and the Component](#the-registry-the-entity-and-the-component)
14  * [Single instance components](#single-instance-components)
15  * [Observe changes](#observe-changes)
16  * [Who let the tags out?](#who-let-the-tags-out)
17  * [Runtime components](#runtime-components)
18  * [A journey through a plugin](#a-journey-through-a-plugin)
19  * [Sorting: is it possible?](#sorting-is-it-possible)
20  * [Snapshot: complete vs continuous](#snapshot-complete-vs-continuous)
21  * [Snapshot loader](#snapshot-loader)
22  * [Continuous loader](#continuous-loader)
23  * [Archives](#archives)
24  * [One example to rule them all](#one-example-to-rule-them-all)
25  * [Prototype](#prototype)
26  * [Helpers](#helpers)
27  * [Dependency function](#dependency-function)
28  * [Labels](#labels)
29  * [Null entity](#null-entity)
30 * [View: to persist or not to persist?](#view-to-persist-or-not-to-persist)
31  * [Standard View](#standard-view)
32  * [Single component standard view](#single-component-standard-view)
33  * [Multi component standard view](#multi-component-standard-view)
34  * [Persistent View](#persistent-view)
35  * [Raw View](#raw-view)
36  * [Runtime View](#runtime-view)
37  * [Give me everything](#give-me-everything)
38 * [Iterations: what is allowed and what is not](#iterations-what-is-allowed-and-what-is-not)
39 * [Multithreading](#multithreading)
40 <!--
41 @endcond TURN_OFF_DOXYGEN
42 -->
43 
44 # Introduction
45 
46 `EnTT` is a header-only, tiny and easy to use entity-component system (and much
47 more) written in modern C++.<br/>
48 The entity-component-system (also known as _ECS_) is an architectural pattern
49 used mostly in game development.
50 
51 # Design choices
52 
53 ## A bitset-free entity-component system
54 
55 `EnTT` is a _bitset-free_ entity-component system that doesn't require users to
56 specify the component set at compile-time.<br/>
57 This is why users can instantiate the core class simply like:
58 
59 ```cpp
60 entt::DefaultRegistry registry;
61 ```
62 
63 In place of its more annoying and error-prone counterpart:
64 
65 ```cpp
66 entt::DefaultRegistry<Comp0, Comp1, ..., CompN> registry;
67 ```
68 
69 ## Pay per use
70 
71 `EnTT` is entirely designed around the principle that users have to pay only for
72 what they want.
73 
74 When it comes to using an entity-component system, the tradeoff is usually
75 between performance and memory usage. The faster it is, the more memory it uses.
76 However, slightly worse performance along non-critical paths are the right price
77 to pay to reduce memory usage and I've always wondered why this kind of tools do
78 not leave me the choice.<br/>
79 `EnTT` follows a completely different approach. It squeezes the best from the
80 basic data structures and gives users the possibility to pay more for higher
81 performance where needed.<br/>
82 The disadvantage of this approach is that users need to know the systems they
83 are working on and the tools they are using. Otherwise, the risk to ruin the
84 performance along critical paths is high.
85 
86 So far, this choice has proven to be a good one and I really hope it can be for
87 many others besides me.
88 
89 # Vademecum
90 
91 The `Registry` to store, the views to iterate. That's all.
92 
93 An entity (the _E_ of an _ECS_) is an opaque identifier that users should just
94 use as-is and store around if needed. Do not try to inspect an entity
95 identifier, its format can change in future and a registry offers all the
96 functionalities to query them out-of-the-box. The underlying type of an entity
97 (either `std::uint16_t`, `std::uint32_t` or `std::uint64_t`) can be specified
98 when defining a registry (actually the `DefaultRegistry` is nothing more than a
99 `Registry` where the type of the entities is `std::uint32_t`).<br/>
100 Components (the _C_ of an _ECS_) should be plain old data structures or more
101 complex and movable data structures with a proper constructor. Actually, the
102 sole requirement of a component type is that it must be both move constructible
103 and move assignable. They are list initialized by using the parameters provided
104 to construct the component itself. No need to register components or their types
105 neither with the registry nor with the entity-component system at all.<br/>
106 Systems (the _S_ of an _ECS_) are just plain functions, functors, lambdas or
107 whatever users want. They can accept a `Registry` or a view of any type and use
108 them the way they prefer. No need to register systems or their types neither
109 with the registry nor with the entity-component system at all.
110 
111 The following sections will explain in short how to use the entity-component
112 system, the core part of the whole library.<br/>
113 In fact, the project is composed of many other classes in addition to those
114 describe below. For more details, please refer to the inline documentation.
115 
116 # The Registry, the Entity and the Component
117 
118 A registry can store and manage entities, as well as create views to iterate the
119 underlying data structures.<br/>
120 `Registry` is a class template that lets users decide what's the preferred type
121 to represent an entity. Because `std::uint32_t` is large enough for almost all
122 the cases, there exists also an alias named `DefaultRegistry` for
123 `Registry<std::uint32_t>`.
124 
125 Entities are represented by _entity identifiers_. An entity identifier is an
126 opaque type that users should not inspect or modify in any way. It carries
127 information about the entity itself and its version.
128 
129 A registry can be used both to construct and destroy entities:
130 
131 ```cpp
132 // constructs a naked entity with no components and returns its identifier
133 auto entity = registry.create();
134 
135 // destroys an entity and all its components
136 registry.destroy(entity);
137 ```
138 
139 Entities can also be destroyed _by type_, that is by specifying the types of the
140 tags or components that identify them:
141 
142 ```cpp
143 // destroys the entity that owns the given tag, if any
144 registry.destroy<MyTag>(entt::tag_t{});
145 
146 // destroys the entities that own the given components, if any
147 registry.destroy<AComponent, AnotherComponent>();
148 ```
149 
150 When an entity is destroyed, the registry can freely reuse it internally with a
151 slightly different identifier. In particular, the version of an entity is
152 increased each and every time it's discarded.<br/>
153 In case entity identifiers are stored around, the registry offers all the
154 functionalities required to test them and get out of the them all the
155 information they carry:
156 
157 ```cpp
158 // returns true if the entity is still valid, false otherwise
159 bool b = registry.valid(entity);
160 
161 // gets the version contained in the entity identifier
162 auto version = registry.version(entity);
163 
164 // gets the actual version for the given entity
165 auto curr = registry.current(entity);
166 ```
167 
168 Components can be assigned to or removed from entities at any time with a few
169 calls to member functions of the registry. As for the entities, the registry
170 offers also a set of functionalities users can use to work with the components.
171 
172 The `assign` member function template creates, initializes and assigns to an
173 entity the given component. It accepts a variable number of arguments to
174 construct the component itself if present:
175 
176 ```cpp
177 registry.assign<Position>(entity, 0., 0.);
178 
179 // ...
180 
181 Velocity &velocity = registry.assign<Velocity>(entity);
182 velocity.dx = 0.;
183 velocity.dy = 0.;
184 ```
185 
186 If an entity already has the given component, the `replace` member function
187 template can be used to replace it:
188 
189 ```cpp
190 registry.replace<Position>(entity, 0., 0.);
191 
192 // ...
193 
194 Velocity &velocity = registry.replace<Velocity>(entity);
195 velocity.dx = 0.;
196 velocity.dy = 0.;
197 ```
198 
199 In case users want to assign a component to an entity, but it's unknown whether
200 the entity already has it or not, `accommodate` does the work in a single call
201 (there is a performance penalty to pay for this mainly due to the fact that it
202 has to check if the entity already has the given component or not):
203 
204 ```cpp
205 registry.accommodate<Position>(entity, 0., 0.);
206 
207 // ...
208 
209 Velocity &velocity = registry.accommodate<Velocity>(entity);
210 velocity.dx = 0.;
211 velocity.dy = 0.;
212 ```
213 
214 Note that `accommodate` is a slightly faster alternative for the following
215 `if/else` statement and nothing more:
216 
217 ```cpp
218 if(registry.has<Comp>(entity)) {
219  registry.replace<Comp>(entity, arg1, argN);
220 } else {
221  registry.assign<Comp>(entity, arg1, argN);
222 }
223 ```
224 
225 As already shown, if in doubt about whether or not an entity has one or more
226 components, the `has` member function template may be useful:
227 
228 ```cpp
229 bool b = registry.has<Position, Velocity>(entity);
230 ```
231 
232 On the other side, if the goal is to delete a single component, the `remove`
233 member function template is the way to go when it's certain that the entity owns
234 a copy of the component:
235 
236 ```cpp
237 registry.remove<Position>(entity);
238 ```
239 
240 Otherwise consider to use the `reset` member function. It behaves similarly to
241 `remove` but with a strictly defined behavior (and a performance penalty is the
242 price to pay for this). In particular it removes the component if and only if it
243 exists, otherwise it returns safely to the caller:
244 
245 ```cpp
246 registry.reset<Position>(entity);
247 ```
248 
249 There exist also two other _versions_ of the `reset` member function:
250 
251 * If no entity is passed to it, `reset` will remove the given component from
252  each entity that has it:
253 
254  ```cpp
255  registry.reset<Position>();
256  ```
257 
258 * If neither the entity nor the component are specified, all the entities still
259  in use and their components are destroyed:
260 
261  ```cpp
262  registry.reset();
263  ```
264 
265 Finally, references to components can be retrieved simply by doing this:
266 
267 ```cpp
268 const auto &cregistry = registry;
269 
270 // const and non-const reference
271 const Position &position = cregistry.get<Position>(entity);
272 Position &position = registry.get<Position>(entity);
273 
274 // const and non-const references
275 std::tuple<const Position &, const Velocity &> tup = cregistry.get<Position, Velocity>(entity);
276 std::tuple<Position &, Velocity &> tup = registry.get<Position, Velocity>(entity);
277 ```
278 
279 The `get` member function template gives direct access to the component of an
280 entity stored in the underlying data structures of the registry.
281 
282 ## Single instance components
283 
284 In those cases where all what is needed is a single instance component, tags are
285 the right tool to achieve the purpose.<br/>
286 Tags undergo the same requirements of components. They can be either plain old
287 data structures or more complex and movable data structures with a proper
288 constructor.<br/>
289 Actually, the same type can be used both as a tag and as a component and the
290 registry will not complain about it. It is up to users to properly manage their
291 own types. In some cases, the tag `tag_t` must also be used in order to
292 disambiguate overloads of member functions.
293 
294 Attaching tags to entities and removing them is trivial:
295 
296 ```cpp
297 auto player = registry.create();
298 auto camera = registry.create();
299 
300 // attaches a default-initialized tag to an entity
301 registry.assign<PlayingCharacter>(entt::tag_t{}, player);
302 
303 // attaches a tag to an entity and initializes it
304 registry.assign<Camera>(entt::tag_t{}, camera, player);
305 
306 // removes tags from their owners
307 registry.remove<PlayingCharacter>();
308 registry.remove<Camera>();
309 ```
310 
311 In case a tag already has an owner, its content can be updated by means of the
312 `replace` member function template and the ownership of the tag can be
313 transferred to another entity using the `move` member function template:
314 
315 ```
316 // replaces the content of the given tag
317 Point &point = registry.replace<Point>(entt::tag_t{}, 1.f, 1.f);
318 
319 // transfers the ownership of the tag to another entity
320 entity_type prev = registry.move<Point>(next);
321 ```
322 
323 If in doubt about whether or not a tag already has an owner, the `has` member
324 function template may be useful:
325 
326 ```cpp
327 bool b = registry.has<PlayingCharacter>();
328 ```
329 
330 References to tags can be retrieved simply by doing this:
331 
332 ```cpp
333 const auto &cregistry = registry;
334 
335 // either a non-const reference ...
336 PlayingCharacter &player = registry.get<PlayingCharacter>();
337 
338 // ... or a const one
339 const Camera &camera = cregistry.get<Camera>();
340 ```
341 
342 The `get` member function template gives direct access to the tag as stored in
343 the underlying data structures of the registry.
344 
345 As shown above, in almost all the cases the entity identifier isn't required.
346 Since a single instance component can have only one associated entity, it
347 doesn't make much sense to mention it explicitly.<br/>
348 To find out who the owner is, just do the following:
349 
350 ```cpp
351 auto player = registry.attachee<PlayingCharacter>();
352 ```
353 
354 Note that iterating tags isn't possible for obvious reasons. Tags give direct
355 access to single entities and nothing more.
356 
357 ## Observe changes
358 
359 Because of how the registry works internally, it stores a couple of signal
360 handlers for each pool in order to notify some of its data structures on the
361 construction and destruction of components.<br/>
362 These signal handlers are also exposed and made available to users. This is the
363 basic brick to build fancy things like dependencies and reactive systems.
364 
365 To get a sink to be used to connect and disconnect listeners so as to be
366 notified on the creation of a component, use the `construction` member function:
367 
368 ```cpp
369 // connects a free function
370 registry.construction<Position>().connect<&MyFreeFunction>();
371 
372 // connects a member function
373 registry.construction<Position>().connect<MyClass, &MyClass::member>(&instance);
374 
375 // disconnects a free function
376 registry.construction<Position>().disconnect<&MyFreeFunction>();
377 
378 // disconnects a member function
379 registry.construction<Position>().disconnect<MyClass, &MyClass::member>(&instance);
380 ```
381 
382 To be notified when components are destroyed, use the `destruction` member
383 function instead.
384 
385 The function type of a listener is the same in both cases:
386 
387 ```cpp
388 void(Registry<Entity> &, Entity);
389 ```
390 
391 In other terms, a listener is provided with the registry that triggered the
392 notification and the entity affected by the change. Note also that:
393 
394 * Listeners are invoked **after** components have been assigned to entities.
395 * Listeners are invoked **before** components have been removed from entities.
396 * The order of invocation of the listeners isn't guaranteed in any case.
397 
398 There are also some limitations on what a listener can and cannot do. In
399 particular:
400 
401 * Connecting and disconnecting other functions from within the body of a
402  listener should be avoided. It can lead to undefined behavior in some cases.
403 * Assigning and removing components and tags from within the body of a listener
404  that observes the destruction of instances of a given type should be avoided.
405  It can lead to undefined behavior in some cases. This type of listeners is
406  intended to provide users with an easy way to perform cleanup and nothing
407  more.
408 
409 To a certain extent, these limitations do not apply. However, it is risky to try
410 to force them and users should respect the limitations unless they know exactly
411 what they are doing. Subtle bugs are the price to pay in case of errors
412 otherwise.
413 
414 In general, events and therefore listeners must not be used as replacements for
415 systems. They should not contain much logic and interactions with a registry
416 should be kept to a minimum, if possible. Note also that the greater the number
417 of listeners, the greater the performance hit when components are created or
418 destroyed.
419 
420 ### Who let the tags out?
421 
422 As an extension, signals are also provided with tags. Although they are not
423 strictly required internally, it makes sense that a user expects signal support
424 even when it comes to tags actually.<br/>
425 Signals for tags undergo exactly the same requirements of those introduced for
426 components. Also the function type for a listener is the same and it's invoked
427 with the same guarantees discussed above.
428 
429 To get the sinks for a tag just use tag `tag_t` to disambiguate overloads of
430 member functions as in the following example:
431 
432 ```cpp
433 registry.construction<MyTag>(entt::tag_t{}).connect<&MyFreeFunction>();
434 registry.destruction<MyTag>(entt::tag_t{}).connect<MyClass, &MyClass::member>(&instance);
435 ```
436 
437 Listeners for tags and components are managed separately and do not influence
438 each other in any case. Therefore, note that the greater the number of listeners
439 for a type, the greater the performance hit when a tag of the given type is
440 created or destroyed.
441 
442 ## Runtime components
443 
444 Defining components at runtime is useful to support plugin systems and mods in
445 general. However, it seems impossible with a tool designed around a bunch of
446 templates. Indeed it's not that difficult.<br/>
447 Of course, some features cannot be easily exported into a runtime
448 environment. As an example, sorting a group of components defined at runtime
449 isn't for free if compared to most of the other operations. However, the basic
450 functionalities of an entity-component system such as `EnTT` fit the problem
451 perfectly and can also be used to manage runtime components if required.<br/>
452 All that is necessary to do it is to know the identifiers of the components. An
453 identifier is nothing more than a number or similar that can be used at runtime
454 to work with the type system.
455 
456 In `EnTT`, identifiers are easily accessible:
457 
458 ```cpp
459 entt::DefaultRegistry registry;
460 
461 // standard component identifier
462 auto ctype = registry.type<Position>();
463 
464 // single instance component identifier
465 auto ttype = registry.type<PlayingCharacter>(entt::tag_t{});
466 ```
467 
468 Once the identifiers are made available, almost everything becomes pretty
469 simple.
470 
471 ### A journey through a plugin
472 
473 `EnTT` comes with an example (actually a test) that shows how to integrate
474 compile-time and runtime components in a stack based JavaScript environment. It
475 uses [`Duktape`](https://github.com/svaarala/duktape) under the hood, mainly
476 because I wanted to learn how it works at the time I was writing the code.
477 
478 The code is not production-ready and overall performance can be highly improved.
479 However, I sacrificed optimizations in favor of a more readable piece of code. I
480 hope I succeeded.<br/>
481 Note also that this isn't neither the only nor (probably) the best way to do it.
482 In fact, the right way depends on the scripting language and the problem one is
483 facing in general.<br/>
484 That being said, feel free to use it at your own risk.
485 
486 The basic idea is that of creating a compile-time component aimed to map all the
487 runtime components assigned to an entity.<br/>
488 Identifiers come in use to address the right function from a map when invoked
489 from the runtime environment and to filter entities when iterating.<br/>
490 With a bit of gymnastic, one can narrow views and improve the performance to
491 some extent but it was not the goal of the example.
492 
493 ## Sorting: is it possible?
494 
495 It goes without saying that sorting entities and components is possible with
496 `EnTT`.<br/>
497 In fact, there are two functions that respond to slightly different needs:
498 
499 * Components can be sorted directly:
500 
501  ```cpp
502  registry.sort<Renderable>([](const auto &lhs, const auto &rhs) {
503  return lhs.z < rhs.z;
504 
505  });
506  ```
507 
508  There exists also the possibility to use a custom sort function object, as
509  long as it adheres to the requirements described in the inline
510  documentation.<br/>
511  This is possible mainly because users can get much more with a custom sort
512  function object if the pattern of usage is known. As an example, in case of an
513  almost sorted pool, quick sort could be much, much slower than insertion sort.
514 
515 * Components can be sorted according to the order imposed by another component:
516 
517  ```cpp
518  registry.sort<Movement, Physics>();
519  ```
520 
521  In this case, instances of `Movement` are arranged in memory so that cache
522  misses are minimized when the two components are iterated together.
523 
524 ## Snapshot: complete vs continuous
525 
526 The `Registry` class offers basic support to serialization.<br/>
527 It doesn't convert components and tags to bytes directly, there wasn't the need
528 of another tool for serialization out there. Instead, it accepts an opaque
529 object with a suitable interface (namely an _archive_) to serialize its internal
530 data structures and restore them later. The way types and instances are
531 converted to a bunch of bytes is completely in charge to the archive and thus to
532 final users.
533 
534 The goal of the serialization part is to allow users to make both a dump of the
535 entire registry or a narrower snapshot, that is to select only the components
536 and the tags in which they are interested.<br/>
537 Intuitively, the use cases are different. As an example, the first approach is
538 suitable for local save/restore functionalities while the latter is suitable for
539 creating client-server applications and for transferring somehow parts of the
540 representation side to side.
541 
542 To take a snapshot of the registry, use the `snapshot` member function. It
543 returns a temporary object properly initialized to _save_ the whole registry or
544 parts of it.
545 
546 Example of use:
547 
548 ```cpp
549 OutputArchive output;
550 
551 registry.snapshot()
552  .entities(output)
553  .destroyed(output)
554  .component<AComponent, AnotherComponent>(output)
555  .tag<MyTag>(output);
556 ```
557 
558 It isn't necessary to invoke all these functions each and every time. What
559 functions to use in which case mostly depends on the goal and there is not a
560 golden rule to do that.
561 
562 The `entities` member function asks the registry to serialize all the entities
563 that are still in use along with their versions. On the other side, the
564 `destroyed` member function tells to the registry to serialize the entities that
565 have been destroyed and are no longer in use.<br/>
566 These two functions can be used to save and restore the whole set of entities
567 with the versions they had during serialization.
568 
569 The `component` member function is a function template the aim of which is to
570 store aside components. The presence of a template parameter list is a
571 consequence of a couple of design choices from the past and in the present:
572 
573 * First of all, there is no reason to force a user to serialize all the
574  components at once and most of the times it isn't desiderable. As an example,
575  in case the stuff for the HUD in a game is put into the registry for some
576  reasons, its components can be freely discarded during a serialization step
577  because probably the software already knows how to reconstruct the HUD
578  correctly from scratch.
579 
580 * Furthermore, the registry makes heavy use of _type-erasure_ techniques
581  internally and doesn't know at any time what types of components it contains.
582  Therefore being explicit at the call point is mandatory.
583 
584 There exists also another version of the `component` member function that
585 accepts a range of entities to serialize. This version is a bit slower than the
586 other one, mainly because it iterates the range of entities more than once for
587 internal purposes. However, it can be used to filter out those entities that
588 shouldn't be serialized for some reasons.<br/>
589 As an example:
590 
591 ```cpp
592 const auto view = registry.view<Serialize>();
593 OutputArchive output;
594 
595 registry.snapshot()
596  .component<AComponent, AnotherComponent>(output, view.cbegin(), view.cend());
597 ```
598 
599 The `tag` member function is similar to the previous one, apart from the fact
600 that it works with tags and not with components.<br/>
601 Note also that both `component` and `tag` store items along with entities. It
602 means that they work properly without a call to the `entities` member function.
603 
604 Once a snapshot is created, there exist mainly two _ways_ to load it: as a whole
605 and in a kind of _continuous mode_.<br/>
606 The following sections describe both loaders and archives in details.
607 
608 ### Snapshot loader
609 
610 A snapshot loader requires that the destination registry be empty and loads all
611 the data at once while keeping intact the identifiers that the entities
612 originally had.<br/>
613 To do that, the registry offers a member function named `restore` that returns a
614 temporary object properly initialized to _restore_ a snapshot.
615 
616 Example of use:
617 
618 ```cpp
619 InputArchive input;
620 
621 registry.restore()
622  .entities(input)
623  .destroyed(input)
624  .component<AComponent, AnotherComponent>(input)
625  .tag<MyTag>(input)
626  .orphans();
627 ```
628 
629 It isn't necessary to invoke all these functions each and every time. What
630 functions to use in which case mostly depends on the goal and there is not a
631 golden rule to do that. For obvious reasons, what is important is that the data
632 are restored in exactly the same order in which they were serialized.
633 
634 The `entities` and `destroyed` member functions restore the sets of entities and
635 the versions that the entities originally had at the source.
636 
637 The `component` member function restores all and only the components specified
638 and assigns them to the right entities. Note that the template parameter list
639 must be exactly the same used during the serialization. The same applies to the
640 `tag` member function.
641 
642 The `orphans` member function literally destroys those entities that have
643 neither components nor tags. It's usually useless if the snapshot is a full dump
644 of the source. However, in case all the entities are serialized but only few
645 components and tags are saved, it could happen that some of the entities have
646 neither components nor tags once restored. The best users can do to deal with
647 them is to destroy those entities and thus update their versions.
648 
649 ### Continuous loader
650 
651 A continuous loader is designed to load data from a source registry to a
652 (possibly) non-empty destination. The loader can accommodate in a registry more
653 than one snapshot in a sort of _continuous loading_ that updates the
654 destination one step at a time.<br/>
655 Identifiers that entities originally had are not transferred to the target.
656 Instead, the loader maps remote identifiers to local ones while restoring a
657 snapshot. Because of that, this kind of loader offers a way to update
658 automatically identifiers that are part of components or tags (as an example, as
659 data members or gathered in a container).<br/>
660 Another difference with the snapshot loader is that the continuous loader does
661 not need to work with the private data structures of a registry. Furthermore, it
662 has an internal state that must persist over time. Therefore, there is no reason
663 to create it by means of a registry, or to limit its lifetime to that of a
664 temporary object.
665 
666 Example of use:
667 
668 ```cpp
669 entt::ContinuousLoader<entity_type> loader{registry};
670 InputArchive input;
671 
672 loader.entities(input)
673  .destroyed(input)
674  .component<AComponent, AnotherComponent, DirtyComponent>(input, &DirtyComponent::parent, &DirtyComponent::child)
675  .tag<MyTag, DirtyTag>(input, &DirtyTag::container)
676  .orphans()
677  .shrink();
678 ```
679 
680 It isn't necessary to invoke all these functions each and every time. What
681 functions to use in which case mostly depends on the goal and there is not a
682 golden rule to do that. For obvious reasons, what is important is that the data
683 are restored in exactly the same order in which they were serialized.
684 
685 The `entities` and `destroyed` member functions restore groups of entities and
686 map each entity to a local counterpart when required. In other terms, for each
687 remote entity identifier not yet registered by the loader, the latter creates a
688 local identifier so that it can keep the local entity in sync with the remote
689 one.
690 
691 The `component` and `tag` member functions restore all and only the components
692 and the tags specified and assign them to the right entities.<br/>
693 In case the component or the tag contains entities itself (either as data
694 members of type `entity_type` or as containers of entities), the loader can
695 update them automatically. To do that, it's enough to specify the data members
696 to update as shown in the example.
697 
698 The `orphans` member function literally destroys those entities that have
699 neither components nor tags after a restore. It has exactly the same purpose
700 described in the previous section and works the same way.
701 
702 Finally, `shrink` helps to purge local entities that no longer have a remote
703 conterpart. Users should invoke this member function after restoring each
704 snapshot, unless they know exactly what they are doing.
705 
706 ### Archives
707 
708 Archives must publicly expose a predefined set of member functions. The API is
709 straightforward and consists only of a group of function call operators that
710 are invoked by the snapshot class and the loaders.
711 
712 In particular:
713 
714 * An output archive, the one used when creating a snapshot, must expose a
715  function call operator with the following signature to store entities:
716 
717  ```cpp
718  void operator()(Entity);
719  ```
720 
721  Where `Entity` is the type of the entities used by the registry. Note that all
722  the member functions of the snapshot class make also an initial call to this
723  endpoint to save the _size_ of the set they are going to store.<br/>
724  In addition, an archive must accept a pair of entity and either component or
725  tag for each type to be serialized. Therefore, given a type `T`, the archive
726  must contain a function call operator with the following signature:
727 
728  ```cpp
729  void operator()(Entity, const T &);
730  ```
731 
732  The output archive can freely decide how to serialize the data. The register
733  is not affected at all by the decision.
734 
735 * An input archive, the one used when restoring a snapshot, must expose a
736  function call operator with the following signature to load entities:
737 
738  ```cpp
739  void operator()(Entity &);
740  ```
741 
742  Where `Entity` is the type of the entities used by the registry. Each time the
743  function is invoked, the archive must read the next element from the
744  underlying storage and copy it in the given variable. Note that all the member
745  functions of a loader class make also an initial call to this endpoint to read
746  the _size_ of the set they are going to load.<br/>
747  In addition, the archive must accept a pair of entity and either component or
748  tag for each type to be restored. Therefore, given a type `T`, the archive
749  must contain a function call operator with the following signature:
750 
751  ```cpp
752  void operator()(Entity &, T &);
753  ```
754 
755  Every time such an operator is invoked, the archive must read the next
756  elements from the underlying storage and copy them in the given variables.
757 
758 ### One example to rule them all
759 
760 `EnTT` comes with some examples (actually some tests) that show how to integrate
761 a well known library for serialization as an archive. It uses
762 [`Cereal C++`](https://uscilab.github.io/cereal/) under the hood, mainly
763 because I wanted to learn how it works at the time I was writing the code.
764 
765 The code is not production-ready and it isn't neither the only nor (probably)
766 the best way to do it. However, feel free to use it at your own risk.
767 
768 The basic idea is to store everything in a group of queues in memory, then bring
769 everything back to the registry with different loaders.
770 
771 ## Prototype
772 
773 A prototype defines a type of an application in terms of its parts. They can be
774 used to assign components to entities of a registry at once.<br/>
775 Roughly speaking, in most cases prototypes can be considered just as templates
776 to use to initialize entities according to _concepts_. In fact, users can create
777 how many prototypes they want, each one initialized differently from the others.
778 
779 The following is an example of use of a prototype:
780 
781 ```cpp
782 entt::DefaultRegistry registry;
783 entt::DefaultPrototype prototype{registry};
784 
785 prototype.set<Position>(100.f, 100.f);
786 prototype.set<Velocity>(0.f, 0.f);
787 
788 // ...
789 
790 const auto entity = prototype();
791 ```
792 
793 To assign and remove components from a prototype, it offers two dedicated member
794 functions named `set` and `unset`. The `has` member function can be used to know
795 if a given prototype contains one or more components and the `get` member
796 function can be used to retrieve the components.
797 
798 Creating an entity from a prototype is straightforward:
799 
800 * To create a new entity from scratch and assign it a prototype, this is the way
801  to go:
802  ```cpp
803  const auto entity = prototype();
804  ```
805  It is equivalent to the following invokation:
806  ```cpp
807  const auto entity = prototype.create();
808  ```
809 
810 * In case we want to initialize an already existing entity, we can provide the
811  `operator()` directly with the entity identifier:
812  ```cpp
813  prototype(entity);
814  ```
815  It is equivalent to the following invokation:
816  ```cpp
817  prototype.assign(entity);
818  ```
819  Note that existing components aren't overwritten in this case. Only those
820  components that the entity doesn't own yet are copied over. All the other
821  components remain unchanged.
822 
823 * Finally, to assign or replace all the components for an entity, thus
824  overwriting existing ones:
825  ```cpp
826  prototype.accommodate(entity);
827  ```
828 
829 In the examples above, the prototype uses its underlying registry to create
830 entities and components both for its purposes and when it's cloned. To use a
831 different repository to clone a prototype, all the member functions accept also
832 a reference to a valid registry as a first argument.
833 
834 Prototypes are a very useful tool that can save a lot of typing sometimes.
835 Furthermore, the codebase may be easier to maintain, since updating a prototype
836 is much less error prone than jumping around in the codebase to update all the
837 snippets copied and pasted around to initialize entities and components.
838 
839 ## Helpers
840 
841 The so called _helpers_ are small classes and functions mainly designed to offer
842 built-in support for the most basic functionalities.<br/>
843 The list of helpers will grow longer as time passes and new ideas come out.
844 
845 ### Dependency function
846 
847 A _dependency function_ is a predefined listener, actually a function template
848 to use to automatically assign components to an entity when a type has a
849 dependency on some other types.<br/>
850 The following adds components `AType` and `AnotherType` whenever `MyType` is
851 assigned to an entity:
852 
853 ```cpp
854 entt::connnect<AType, AnotherType>(registry.construction<MyType>());
855 ```
856 
857 A component is assigned to an entity and thus default initialized only in case
858 the entity itself hasn't it yet. It means that already existent components won't
859 be overriden.<br/>
860 A dependency can easily be broken by means of the following function template:
861 
862 ```cpp
863 entt::disconnect<AType, AnotherType>(registry.construction<MyType>());
864 ```
865 
866 ### Labels
867 
868 There's nothing magical about the way labels can be assigned to entities while
869 avoiding a performance hit at runtime. Nonetheless, the syntax can be annoying
870 and that's why a more user-friendly shortcut is provided to do it.<br/>
871 This shortcut is the alias template `entt::label`.
872 
873 If used in combination with hashed strings, it helps to use labels where types
874 would be required otherwise. As an example:
875 
876 ```cpp
877 registry.assign<entt::label<"enemy"_hs>>(entity);
878 ```
879 
880 ## Null entity
881 
882 In `EnTT`, there exists a sort of _null entity_ made available to users that is
883 accessible via the `entt::null` variable.<br/>
884 The library guarantees that the following expression always returns false:
885 
886 ```cpp
887 registry.valid(entt::null);
888 ```
889 
890 In other terms, a registry will reject the null entity in all cases because it
891 isn't considered valid. It means that the null entity cannot own components or
892 tags for obvious reasons.<br/>
893 The type of the null entity is internal and should not be used for any purpose
894 other than defining the null entity itself. However, there exist implicit
895 conversions from the null entity to identifiers of any allowed type:
896 
897 ```cpp
898 typename entt::DefaultRegistry::entity_type null = entt::null;
899 ```
900 
901 Similarly, the null entity can be compared to any other identifier:
902 
903 ```cpp
904 const auto entity = registry.create();
905 const bool null = (entity == entt::null);
906 ```
907 
908 # View: to persist or not to persist?
909 
910 First of all, it is worth answering an obvious question: why views?<br/>
911 Roughly speaking, they are a good tool to enforce single responsibility. A
912 system that has access to a registry can create and destroy entities, as well as
913 assign and remove components. On the other side, a system that has access to a
914 view can only iterate entities and their components, then read or update the
915 data members of the latter.<br/>
916 It is a subtle difference that can help designing a better software sometimes.
917 
918 There are mainly four kinds of views: standard (also known as `View`),
919 persistent (also known as `PersistentView`), raw (also known as `RawView`) and
920 runtime (also known as `RuntimeView`).<br/>
921 All of them have pros and cons to take in consideration. In particular:
922 
923 * Standard views:
924 
925  Pros:
926 
927  * They work out-of-the-box and don't require any dedicated data structure.
928  * Creating and destroying them isn't expensive at all because they don't have
929  any type of initialization.
930  * They are the best tool for iterating entities for a single component.
931  * They are the best tool for iterating entities for multiple components when
932  one of the components is assigned to a significantly low number of entities.
933  * They don't affect any other operations of the registry.
934 
935  Cons:
936 
937  * Their performance tend to degenerate when the number of components to
938  iterate grows up and the most of the entities have all of them.
939 
940 * Persistent views:
941 
942  Pros:
943 
944  * Once prepared, creating and destroying them isn't expensive at all because
945  they don't have any type of initialization.
946  * They are the best tool for iterating entities for multiple components when
947  most entities have them all.
948 
949  Cons:
950 
951  * They have dedicated data structures and thus affect the memory usage to a
952  minimal extent.
953  * If not previously prepared, the first time they are used they go through an
954  initialization step that could take a while.
955  * They affect to a minimum the creation and destruction of entities and
956  components. In other terms: the more persistent views there will be, the
957  less performing will be creating and destroying entities and components.
958 
959 * Raw views:
960 
961  Pros:
962 
963  * They work out-of-the-box and don't require any dedicated data structure.
964  * Creating and destroying them isn't expensive at all because they don't have
965  any type of initialization.
966  * They are the best tool for iterating components when it is not necessary to
967  know which entities they belong to.
968  * They don't affect any other operations of the registry.
969 
970  Cons:
971 
972  * They can be used to iterate only one type of component at a time.
973  * They don't return the entity to which a component belongs to the caller.
974 
975 * Runtime views:
976 
977  Pros:
978 
979  * Their lists of components are defined at runtime and not at compile-time.
980  * Creating and destroying them isn't expensive at all because they don't have
981  any type of initialization.
982  * They are the best tool for things like plugin systems and mods in general.
983  * They don't affect any other operations of the registry.
984 
985  Cons:
986 
987  * Their performances are definitely lower than those of all the other views,
988  although they are still usable and sufficient for most of the purposes.
989 
990 To sum up and as a rule of thumb:
991 
992 * Use a raw view to iterate components only (no entities) for a given type.
993 * Use a standard view to iterate entities and components for a single type.
994 * Use a standard view to iterate entities and components for multiple types when
995  the number of types is low. Standard views are really optimized and persistent
996  views won't add much in this case.
997 * Use a standard view to iterate entities and components for multiple types when
998  a significantly low number of entities have one of the components.
999 * Use a standard view in all those cases where a persistent view would give a
1000  boost to performance but the iteration isn't performed frequently.
1001 * Prepare and use a persistent view when you want to iterate only entities for
1002  multiple components.
1003 * Prepare and use a persistent view when you want to iterate entities for
1004  multiple components and each component is assigned to a great number of
1005  entities but the intersection between the sets of entities is small.
1006 * Prepare and use a persistent view in all the cases where a standard view
1007  wouldn't fit well otherwise.
1008 * Finally, in case you don't know at compile-time what are the components to
1009  use, choose a runtime view and set them during execution.
1010 
1011 To easily iterate entities and components, all the views offer the common
1012 `begin` and `end` member functions that allow users to use a view in a typical
1013 range-for loop. Almost all the views offer also a *more functional* `each`
1014 member function that accepts a callback for convenience.<br/>
1015 Continue reading for more details or refer to the inline documentation.
1016 
1017 ## Standard View
1018 
1019 A standard view behaves differently if it's constructed for a single component
1020 or if it has been requested to iterate multiple components. Even the API is
1021 different in the two cases.<br/>
1022 All that they share is the way they are created by means of a registry:
1023 
1024 ```cpp
1025 // single component standard view
1026 auto single = registry.view<Position>();
1027 
1028 // multi component standard view
1029 auto multi = registry.view<Position, Velocity>();
1030 ```
1031 
1032 For all that remains, it's worth discussing them separately.<br/>
1033 
1034 ### Single component standard view
1035 
1036 Single component standard views are specialized in order to give a boost in
1037 terms of performance in all the situation. This kind of views can access the
1038 underlying data structures directly and avoid superfluous checks.<br/>
1039 They offer a bunch of functionalities to get the number of entities they are
1040 going to return and a raw access to the entity list as well as to the component
1041 list. It's also possible to ask a view if it contains a given entity.<br/>
1042 Refer to the inline documentation for all the details.
1043 
1044 There is no need to store views around for they are extremely cheap to
1045 construct, even though they can be copied without problems and reused freely. In
1046 fact, they return newly created and correctly initialized iterators whenever
1047 `begin` or `end` are invoked.<br/>
1048 To iterate a single component standard view, either use it in a range-for loop:
1049 
1050 ```cpp
1051 auto view = registry.view<Renderable>();
1052 
1053 for(auto entity: view) {
1054  Renderable &renderable = view.get(entity);
1055 
1056  // ...
1057 }
1058 ```
1059 
1060 Or rely on the `each` member function to iterate entities and get all their
1061 components at once:
1062 
1063 ```cpp
1064 registry.view<Renderable>().each([](auto entity, auto &renderable) {
1065  // ...
1066 });
1067 ```
1068 
1069 The `each` member function is highly optimized. Unless users want to iterate
1070 only entities, using `each` should be the preferred approach.
1071 
1072 **Note**: prefer the `get` member function of a view instead of the `get` member
1073 function template of a registry during iterations, if possible. However, keep in
1074 mind that it works only with the components of the view itself.
1075 
1076 ### Multi component standard view
1077 
1078 Multi component standard views iterate entities that have at least all the given
1079 components in their bags. During construction, these views look at the number of
1080 entities available for each component and pick up a reference to the smallest
1081 set of candidates in order to speed up iterations.<br/>
1082 They offer fewer functionalities than their companion views for single
1083 component. In particular, a multi component standard view exposes utility
1084 functions to get the estimated number of entities it is going to return and to
1085 know whether it's empty or not. It's also possible to ask a view if it contains
1086 a given entity.<br/>
1087 Refer to the inline documentation for all the details.
1088 
1089 There is no need to store views around for they are extremely cheap to
1090 construct, even though they can be copied without problems and reused freely. In
1091 fact, they return newly created and correctly initialized iterators whenever
1092 `begin` or `end` are invoked.<br/>
1093 To iterate a multi component standard view, either use it in a range-for loop:
1094 
1095 ```cpp
1096 auto view = registry.view<Position, Velocity>();
1097 
1098 for(auto entity: view) {
1099  // a component at a time ...
1100  Position &position = view.get<Position>(entity);
1101  Velocity &velocity = view.get<Velocity>(entity);
1102 
1103  // ... or multiple components at once
1104  std::tuple<Position &, Velocity &> tup = view.get<Position, Velocity>(entity);
1105 
1106  // ...
1107 }
1108 ```
1109 
1110 Or rely on the `each` member function to iterate entities and get all their
1111 components at once:
1112 
1113 ```cpp
1114 registry.view<Position, Velocity>().each([](auto entity, auto &position, auto &velocity) {
1115  // ...
1116 });
1117 ```
1118 
1119 The `each` member function is highly optimized. Unless users want to iterate
1120 only entities or get only some of the components, using `each` should be the
1121 preferred approach.
1122 
1123 **Note**: prefer the `get` member function of a view instead of the `get` member
1124 function template of a registry during iterations, if possible. However, keep in
1125 mind that it works only with the components of the view itself.
1126 
1127 ## Persistent View
1128 
1129 A persistent view returns all the entities and only the entities that have at
1130 least the given components. Moreover, it's guaranteed that the entity list is
1131 tightly packed in memory for fast iterations.<br/>
1132 In general, persistent views don't stay true to the order of any set of
1133 components unless users explicitly sort them.
1134 
1135 Persistent views can be used only to iterate multiple components. To create this
1136 kind of views, the tag `persistent_t` must also be used in order to disambiguate
1137 overloads of the `view` member function:
1138 
1139 ```cpp
1140 auto view = registry.view<Position, Velocity>(entt::persistent_t{});
1141 ```
1142 
1143 There is no need to store views around for they are extremely cheap to
1144 construct, even though they can be copied without problems and reused freely. In
1145 fact, they return newly created and correctly initialized iterators whenever
1146 `begin` or `end` are invoked.<br/>
1147 That being said, persistent views perform an initialization step the very first
1148 time they are constructed and this could be quite costly. To avoid it, consider
1149 asking to the registry to _prepare_ them when no entities have been created yet:
1150 
1151 ```cpp
1152 registry.prepare<Position, Velocity>();
1153 ```
1154 
1155 If the registry is empty, preparation is extremely fast. Moreover the `prepare`
1156 member function template is idempotent. Feel free to invoke it even more than
1157 once: if the view has been already prepared before, the function returns
1158 immediately and does nothing.
1159 
1160 A persistent view offers a bunch of functionalities to get the number of
1161 entities it's going to return, a raw access to the entity list and the
1162 possibility to sort the underlying data structures according to the order of one
1163 of the components for which it has been constructed. It's also possible to ask a
1164 view if it contains a given entity.<br/>
1165 Refer to the inline documentation for all the details.
1166 
1167 To iterate a persistent view, either use it in a range-for loop:
1168 
1169 ```cpp
1170 auto view = registry.view<Position, Velocity>(entt::persistent_t{});
1171 
1172 for(auto entity: view) {
1173  // a component at a time ...
1174  Position &position = view.get<Position>(entity);
1175  Velocity &velocity = view.get<Velocity>(entity);
1176 
1177  // ... or multiple components at once
1178  std::tuple<Position &, Velocity &> tup = view.get<Position, Velocity>(entity);
1179 
1180  // ...
1181 }
1182 ```
1183 
1184 Or rely on the `each` member function to iterate entities and get all their
1185 components at once:
1186 
1187 ```cpp
1188 registry.view<Position, Velocity>(entt::persistent_t{}).each([](auto entity, auto &position, auto &velocity) {
1189  // ...
1190 });
1191 ```
1192 
1193 Performance are more or less the same. The best approach depends mainly on
1194 whether all the components have to be accessed or not.
1195 
1196 **Note**: prefer the `get` member function of a view instead of the `get` member
1197 function template of a registry during iterations, if possible. However, keep in
1198 mind that it works only with the components of the view itself.
1199 
1200 ## Raw View
1201 
1202 Raw views return all the components of a given type. This kind of views can
1203 access components directly and avoid extra indirections like when components are
1204 accessed via an entity identifier.<br/>
1205 They offer a bunch of functionalities to get the number of instances they are
1206 going to return and a raw access to the entity list as well as to the component
1207 list.<br/>
1208 Refer to the inline documentation for all the details.
1209 
1210 Raw views can be used only to iterate components for a single type. To create
1211 this kind of views, the tag `raw_t` must also be used in order to disambiguate
1212 overloads of the `view` member function:
1213 
1214 ```cpp
1215 auto view = registry.view<Renderable>(entt::raw_t{});
1216 ```
1217 
1218 There is no need to store views around for they are extremely cheap to
1219 construct, even though they can be copied without problems and reused freely. In
1220 fact, they return newly created and correctly initialized iterators whenever
1221 `begin` or `end` are invoked.<br/>
1222 To iterate a raw view, use it in a range-for loop:
1223 
1224 ```cpp
1225 auto view = registry.view<Renderable>(entt::raw_t{});
1226 
1227 for(auto &&component: raw) {
1228  // ...
1229 }
1230 ```
1231 
1232 Or rely on the `each` member function:
1233 
1234 ```cpp
1235 registry.view<Renderable>(entt::raw_t{}).each([](auto &renderable) {
1236  // ...
1237 });
1238 ```
1239 
1240 Performance are exactly the same in both cases.
1241 
1242 **Note**: raw views don't have a `get` member function for obvious reasons.
1243 
1244 ## Runtime View
1245 
1246 Runtime views iterate entities that have at least all the given components in
1247 their bags. During construction, these views look at the number of entities
1248 available for each component and pick up a reference to the smallest
1249 set of candidates in order to speed up iterations.<br/>
1250 They offer more or less the same functionalities of a multi component standard
1251 view. However, they don't expose a `get` member function and users should refer
1252 to the registry that generated the view to access components. In particular, a
1253 runtime view exposes utility functions to get the estimated number of entities
1254 it is going to return and to know whether it's empty or not. It's also possible
1255 to ask a view if it contains a given entity.<br/>
1256 Refer to the inline documentation for all the details.
1257 
1258 Runtime view are extremely cheap to construct and should not be stored around in
1259 any case. They should be used immediately after creation and then they should be
1260 thrown away. The reasons for this go far beyond the scope of this document.<br/>
1261 To iterate a runtime view, either use it in a range-for loop:
1262 
1263 ```cpp
1264 using component_type = typename decltype(registry)::component_type;
1265 component_type types[] = { registry.type<Position>(), registry.type<Velocity>() };
1266 
1267 auto view = registry.view(std::cbegin(types), std::cend(types));
1268 
1269 for(auto entity: view) {
1270  // a component at a time ...
1271  Position &position = registry.get<Position>(entity);
1272  Velocity &velocity = registry.get<Velocity>(entity);
1273 
1274  // ... or multiple components at once
1275  std::tuple<Position &, Velocity &> tup = view.get<Position, Velocity>(entity);
1276 
1277  // ...
1278 }
1279 ```
1280 
1281 Or rely on the `each` member function to iterate entities:
1282 
1283 ```cpp
1284 using component_type = typename decltype(registry)::component_type;
1285 component_type types[] = { registry.type<Position>(), registry.type<Velocity>() };
1286 
1287 auto view = registry.view(std::cbegin(types), std::cend(types)).each([](auto entity) {
1288  // ...
1289 });
1290 ```
1291 
1292 Performance are exactly the same in both cases.
1293 
1294 **Note**: runtime views are meant for all those cases where users don't know at
1295 compile-time what components to use to iterate entities. This is particularly
1296 well suited to plugin systems and mods in general. Where possible, don't use
1297 runtime views, as their performance are slightly inferior to those of the other
1298 views.
1299 
1300 
1301 ## Give me everything
1302 
1303 Views are narrow windows on the entire list of entities. They work by filtering
1304 entities according to their components.<br/>
1305 In some cases there may be the need to iterate all the entities still in use
1306 regardless of their components. The registry offers a specific member function
1307 to do that:
1308 
1309 ```cpp
1310 registry.each([](auto entity) {
1311  // ...
1312 });
1313 ```
1314 
1315 It returns to the caller all the entities that are still in use by means of the
1316 given function.<br/>
1317 As a rule of thumb, consider using a view if the goal is to iterate entities
1318 that have a determinate set of components. A view is usually much faster than
1319 combining this function with a bunch of custom tests.<br/>
1320 In all the other cases, this is the way to go.
1321 
1322 There exists also another member function to use to retrieve orphans. An orphan
1323 is an entity that is still in use and has neither assigned components nor
1324 tags.<br/>
1325 The signature of the function is the same of `each`:
1326 
1327 ```cpp
1328 registry.orphans([](auto entity) {
1329  // ...
1330 });
1331 ```
1332 
1333 To test the _orphanity_ of a single entity, use the member function `orphan`
1334 instead. It accepts a valid entity identifer as an argument and returns true in
1335 case the entity is an orphan, false otherwise.
1336 
1337 In general, all these functions can result in poor performance.<br/>
1338 `each` is fairly slow because of some checks it performs on each and every
1339 entity. For similar reasons, `orphans` can be even slower. Both functions should
1340 not be used frequently to avoid the risk of a performance hit.
1341 
1342 # Iterations: what is allowed and what is not
1343 
1344 Most of the _ECS_ available out there have some annoying limitations (at least
1345 from my point of view): entities and components cannot be created nor destroyed
1346 during iterations.<br/>
1347 `EnTT` partially solves the problem with a few limitations:
1348 
1349 * Creating entities and components is allowed during iterations.
1350 * Deleting an entity or removing its components is allowed during iterations if
1351  it's the one currently returned by the view. For all the other entities,
1352  destroying them or removing their components isn't allowed and it can result
1353  in undefined behavior.
1354 
1355 Iterators are invalidated and the behavior is undefined if an entity is modified
1356 or destroyed and it's not the one currently returned by the view nor a newly
1357 created one.<br/>
1358 To work around it, possible approaches are:
1359 
1360 * Store aside the entities and the components to be removed and perform the
1361  operations at the end of the iteration.
1362 * Mark entities and components with a proper tag component that indicates they
1363  must be purged, then perform a second iteration to clean them up one by one.
1364 
1365 A notable side effect of this feature is that the number of required allocations
1366 is further reduced in most of the cases.
1367 
1368 # Multithreading
1369 
1370 In general, the entire registry isn't thread safe as it is. Thread safety isn't
1371 something that users should want out of the box for several reasons. Just to
1372 mention one of them: performance.<br/>
1373 Views and consequently the approach adopted by `EnTT` are the great exception to
1374 the rule. It's true that views and thus their iterators aren't thread safe by
1375 themselves. Because of this users shouldn't try to iterate a set of components
1376 and modify the same set concurrently. However:
1377 
1378 * As long as a thread iterates the entities that have the component `X` or
1379  assign and removes that component from a set of entities, another thread can
1380  safely do the same with components `Y` and `Z` and everything will work like a
1381  charm. As a trivial example, users can freely execute the rendering system and
1382  iterate the renderable entities while updating a physic component concurrently
1383  on a separate thread.
1384 
1385 * Similarly, a single set of components can be iterated by multiple threads as
1386  long as the components are neither assigned nor removed in the meantime. In
1387  other words, a hypothetical movement system can start multiple threads, each
1388  of which will access the components that carry information about velocity and
1389  position for its entities.
1390 
1391 This kind of entity-component systems can be used in single threaded
1392 applications as well as along with async stuff or multiple threads. Moreover,
1393 typical thread based models for _ECS_ don't require a fully thread safe registry
1394 to work. Actually, users can reach the goal with the registry as it is while
1395 working with most of the common models.
1396 
1397 Because of the few reasons mentioned above and many others not mentioned, users
1398 are completely responsible for synchronization whether required. On the other
1399 hand, they could get away with it without having to resort to particular
1400 expedients.
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/entt_8hpp_source.html b/entt_8hpp_source.html index ae75251fb..1acf28d47 100644 --- a/entt_8hpp_source.html +++ b/entt_8hpp_source.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -67,7 +67,7 @@ $(function() {
entt.hpp
-
1 #include "core/algorithm.hpp"
2 #include "core/family.hpp"
3 #include "core/hashed_string.hpp"
4 #include "core/ident.hpp"
5 #include "core/monostate.hpp"
6 #include "entity/actor.hpp"
7 #include "entity/entity.hpp"
8 #include "entity/entt_traits.hpp"
9 #include "entity/helper.hpp"
10 #include "entity/prototype.hpp"
11 #include "entity/registry.hpp"
12 #include "entity/snapshot.hpp"
13 #include "entity/sparse_set.hpp"
14 #include "entity/utility.hpp"
15 #include "entity/view.hpp"
16 #include "locator/locator.hpp"
17 #include "process/process.hpp"
18 #include "process/scheduler.hpp"
19 #include "resource/cache.hpp"
20 #include "resource/handle.hpp"
21 #include "resource/loader.hpp"
22 #include "signal/delegate.hpp"
23 #include "signal/dispatcher.hpp"
24 #include "signal/emitter.hpp"
25 #include "signal/sigh.hpp"
+
1 #include "core/algorithm.hpp"
2 #include "core/family.hpp"
3 #include "core/hashed_string.hpp"
4 #include "core/ident.hpp"
5 #include "core/monostate.hpp"
6 #include "entity/actor.hpp"
7 #include "entity/attachee.hpp"
8 #include "entity/entity.hpp"
9 #include "entity/entt_traits.hpp"
10 #include "entity/helper.hpp"
11 #include "entity/prototype.hpp"
12 #include "entity/registry.hpp"
13 #include "entity/snapshot.hpp"
14 #include "entity/sparse_set.hpp"
15 #include "entity/utility.hpp"
16 #include "entity/view.hpp"
17 #include "locator/locator.hpp"
18 #include "process/process.hpp"
19 #include "process/scheduler.hpp"
20 #include "resource/cache.hpp"
21 #include "resource/handle.hpp"
22 #include "resource/loader.hpp"
23 #include "signal/delegate.hpp"
24 #include "signal/dispatcher.hpp"
25 #include "signal/emitter.hpp"
26 #include "signal/sigh.hpp"
Generated by   diff --git a/entt__traits_8hpp_source.html b/entt__traits_8hpp_source.html index 2368b9db1..e39c0ac61 100644 --- a/entt__traits_8hpp_source.html +++ b/entt__traits_8hpp_source.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -67,7 +67,7 @@ $(function() {
entt_traits.hpp
-
1 #ifndef ENTT_ENTITY_ENTT_TRAITS_HPP
2 #define ENTT_ENTITY_ENTT_TRAITS_HPP
3 
4 
5 #include <cstdint>
6 
7 
8 namespace entt {
9 
10 
17 template<typename>
18 struct entt_traits;
19 
20 
29 template<>
30 struct entt_traits<std::uint16_t> {
32  using entity_type = std::uint16_t;
34  using version_type = std::uint8_t;
36  using difference_type = std::int32_t;
37 
39  static constexpr auto entity_mask = 0xFFF;
41  static constexpr auto version_mask = 0xF;
43  static constexpr auto entity_shift = 12;
44 };
45 
46 
55 template<>
56 struct entt_traits<std::uint32_t> {
58  using entity_type = std::uint32_t;
60  using version_type = std::uint16_t;
62  using difference_type = std::int64_t;
63 
65  static constexpr auto entity_mask = 0xFFFFF;
67  static constexpr auto version_mask = 0xFFF;
69  static constexpr auto entity_shift = 20;
70 };
71 
72 
81 template<>
82 struct entt_traits<std::uint64_t> {
84  using entity_type = std::uint64_t;
86  using version_type = std::uint32_t;
88  using difference_type = std::int64_t;
89 
91  static constexpr auto entity_mask = 0xFFFFFFFF;
93  static constexpr auto version_mask = 0xFFFFFFFF;
95  static constexpr auto entity_shift = 32;
96 };
97 
98 
99 }
100 
101 
102 #endif // ENTT_ENTITY_ENTT_TRAITS_HPP
entt::entt_traits< std::uint64_t >::difference_type
std::int64_t difference_type
Difference type.
Definition: entt_traits.hpp:88
+
1 #ifndef ENTT_ENTITY_ENTT_TRAITS_HPP
2 #define ENTT_ENTITY_ENTT_TRAITS_HPP
3 
4 
5 #include <cstdint>
6 
7 
8 namespace entt {
9 
10 
17 template<typename>
18 struct entt_traits;
19 
20 
29 template<>
30 struct entt_traits<std::uint16_t> {
32  using entity_type = std::uint16_t;
34  using version_type = std::uint8_t;
36  using difference_type = std::int32_t;
37 
39  static constexpr std::uint16_t entity_mask = 0xFFF;
41  static constexpr std::uint16_t version_mask = 0xF;
43  static constexpr auto entity_shift = 12;
44 };
45 
46 
55 template<>
56 struct entt_traits<std::uint32_t> {
58  using entity_type = std::uint32_t;
60  using version_type = std::uint16_t;
62  using difference_type = std::int64_t;
63 
65  static constexpr std::uint32_t entity_mask = 0xFFFFF;
67  static constexpr std::uint32_t version_mask = 0xFFF;
69  static constexpr auto entity_shift = 20;
70 };
71 
72 
81 template<>
82 struct entt_traits<std::uint64_t> {
84  using entity_type = std::uint64_t;
86  using version_type = std::uint32_t;
88  using difference_type = std::int64_t;
89 
91  static constexpr std::uint64_t entity_mask = 0xFFFFFFFF;
93  static constexpr std::uint64_t version_mask = 0xFFFFFFFF;
95  static constexpr auto entity_shift = 32;
96 };
97 
98 
99 }
100 
101 
102 #endif // ENTT_ENTITY_ENTT_TRAITS_HPP
entt::entt_traits< std::uint64_t >::difference_type
std::int64_t difference_type
Difference type.
Definition: entt_traits.hpp:88
entt::entt_traits< std::uint32_t >::entity_type
std::uint32_t entity_type
Underlying entity type.
Definition: entt_traits.hpp:58
entt::entt_traits< std::uint64_t >::entity_type
std::uint64_t entity_type
Underlying entity type.
Definition: entt_traits.hpp:84
entt::entt_traits< std::uint32_t >::difference_type
std::int64_t difference_type
Difference type.
Definition: entt_traits.hpp:62
diff --git a/factory_8hpp_source.html b/factory_8hpp_source.html new file mode 100644 index 000000000..a172863cf --- /dev/null +++ b/factory_8hpp_source.html @@ -0,0 +1,99 @@ + + + + + + + +EnTT: src/entt/meta/factory.hpp Source File + + + + + + + + + +
+
+ + + + + + +
+
EnTT +  2.7.2 +
+
+
+ + + + + + + + +
+
+ + +
+ +
+ + +
+
+
+
factory.hpp
+
+
+
1 #ifndef ENTT_META_FACTORY_HPP
2 #define ENTT_META_FACTORY_HPP
3 
4 
5 #include <array>
6 #include <cassert>
7 #include <cstddef>
8 #include <utility>
9 #include <algorithm>
10 #include <type_traits>
11 #include "../core/hashed_string.hpp"
12 #include "meta.hpp"
13 
14 
15 namespace entt {
16 
17 
18 template<typename Key, typename Value>
19 inline auto property(Key &&key, Value &&value) {
20  return std::make_pair(key, value);
21 }
22 
23 
24 class Meta final {
25  template<typename Type, typename = void>
26  struct MetaFactory {
27  template<typename Func, Func *Ptr, typename... Property>
28  static auto ctor(Property &&... property) ENTT_NOEXCEPT {
29  using helper_type = internal::ReflectionHelper<std::integral_constant<Func *, Ptr>>;
30  static_assert(std::is_same<typename helper_type::return_type, Type>::value, "!");
31  auto * const type = internal::MetaInfo<Type>::type;
32 
33  static internal::MetaCtorNode node{
34  type->ctor,
35  properties<Type, typename helper_type::args_type>(std::forward<Property>(property)...),
36  helper_type::size,
37  &helper_type::arg,
38  &helper_type::accept,
39  [](const MetaAny * const any) {
40  return helper_type::invoke(0, nullptr, any, std::make_index_sequence<helper_type::size>{});
41  },
42  []() {
43  static MetaCtor meta{&node};
44  return &meta;
45  }
46  };
47 
48  assert((!internal::MetaInfo<Type>::template ctor<typename helper_type::args_type>));
49  internal::MetaInfo<Type>::template ctor<typename helper_type::args_type> = &node;
50  type->ctor = &node;
51  return MetaFactory<Type>{};
52  }
53 
54  template<typename... Args, typename... Property>
55  static auto ctor(Property &&... property) ENTT_NOEXCEPT {
56  using helper_type = internal::FunctionHelper<void(Args...)>;
57  auto * const type = internal::MetaInfo<Type>::type;
58 
59  static internal::MetaCtorNode node{
60  type->ctor,
61  properties<Type, typename helper_type::args_type>(std::forward<Property>(property)...),
62  helper_type::size,
63  &helper_type::arg,
64  &helper_type::accept,
65  [](const MetaAny * const any) {
66  return internal::CtorHelper<Type, Args...>::construct(any, std::make_index_sequence<helper_type::size>{});
67  },
68  []() {
69  static MetaCtor meta{&node};
70  return &meta;
71  }
72  };
73 
74  assert((!internal::MetaInfo<Type>::template ctor<typename helper_type::args_type>));
75  internal::MetaInfo<Type>::template ctor<typename helper_type::args_type> = &node;
76  type->ctor = &node;
77  return MetaFactory<Type>{};
78  }
79 
80  template<void(*Func)(Type &), typename... Property>
81  static auto dtor(Property &&... property) ENTT_NOEXCEPT {
82  static internal::MetaDtorNode node{
83  properties<Type, std::integral_constant<void(*)(Type &), Func>>(std::forward<Property>(property)...),
84  [](void *instance) {
85  (*Func)(*static_cast<Type *>(instance));
86  },
87  []() {
88  static MetaDtor meta{&node};
89  return &meta;
90  }
91  };
92 
93  assert(!internal::MetaInfo<Type>::type->dtor);
94  assert((!internal::MetaInfo<Type>::template dtor<std::integral_constant<void(*)(Type &), Func>>));
95  internal::MetaInfo<Type>::template dtor<std::integral_constant<void(*)(Type &), Func>> = &node;
96  internal::MetaInfo<Type>::type->dtor = &node;
97  return MetaFactory<Type>{};
98  }
99 
100  template<typename Data, Data *Ptr, typename... Property>
101  static auto data(const char *str, Property &&... property) ENTT_NOEXCEPT {
102  using helper_type = internal::ReflectionHelper<std::integral_constant<Data *, Ptr>>;
103  auto * const type = internal::MetaInfo<Type>::type;
104 
105  static internal::MetaDataNode node{
106  HashedString{str},
107  type->data,
108  properties<Type, std::integral_constant<Data *, Ptr>>(std::forward<Property>(property)...),
109  helper_type::readonly,
110  helper_type::shared,
111  &internal::MetaInfo<Data>::resolve,
112  &helper_type::setter,
113  [](const void *) {
114  return MetaAny{*Ptr};
115  },
116  [](const internal::MetaTypeNode * const other) {
117  return other == internal::MetaInfo<Data>::resolve();
118  },
119  []() {
120  static MetaData meta{&node};
121  return &meta;
122  }
123  };
124 
125  assert(!duplicate(HashedString{str}, node.next));
126  assert((!internal::MetaInfo<Type>::template data<std::integral_constant<Data *, Ptr>>));
127  internal::MetaInfo<Type>::template data<std::integral_constant<Data *, Ptr>> = &node;
128  type->data = &node;
129  return MetaFactory<Type>{};
130  }
131 
132  template<typename Func, Func *Ptr, typename... Property>
133  static auto func(const char *str, Property &&... property) ENTT_NOEXCEPT {
134  using helper_type = internal::ReflectionHelper<std::integral_constant<Func *, Ptr>>;
135  auto * const type = internal::MetaInfo<Type>::type;
136 
137  static internal::MetaFuncNode node{
138  HashedString{str},
139  type->func,
140  properties<Type, std::integral_constant<Func *, Ptr>>(std::forward<Property>(property)...),
141  helper_type::size,
142  helper_type::constant,
143  helper_type::shared,
144  &internal::MetaInfo<typename helper_type::return_type>::resolve,
145  &helper_type::arg,
146  &helper_type::accept,
147  [](const void *instance, const MetaAny *any) {
148  return helper_type::invoke(0, instance, any, std::make_index_sequence<helper_type::size>{});
149  },
150  [](void *instance, const MetaAny *any) {
151  return helper_type::invoke(0, instance, any, std::make_index_sequence<helper_type::size>{});
152  },
153  []() {
154  static MetaFunc meta{&node};
155  return &meta;
156  }
157  };
158 
159  assert(!duplicate(HashedString{str}, node.next));
160  assert((!internal::MetaInfo<Type>::template func<std::integral_constant<Func *, Ptr>>));
161  internal::MetaInfo<Type>::template func<std::integral_constant<Func *, Ptr>> = &node;
162  type->func = &node;
163  return MetaFactory<Type>{};
164  }
165  };
166 
167  template<typename Class>
168  struct MetaFactory<Class, std::enable_if_t<std::is_class<Class>::value>>: MetaFactory<Class, Class> {
169  using MetaFactory<Class, Class>::func;
170 
171  template<typename Type, Type Class:: *Member, typename... Property>
172  static std::enable_if_t<std::is_member_object_pointer<Type Class:: *>::value, MetaFactory<Class>>
173  member(const char *str, Property &&... property) ENTT_NOEXCEPT {
174  using helper_type = internal::ReflectionHelper<std::integral_constant<Type Class:: *, Member>>;
175  auto * const type = internal::MetaInfo<Class>::type;
176 
177  static internal::MetaDataNode node{
178  HashedString{str},
179  type->data,
180  properties<Class, std::integral_constant<Type Class:: *, Member>>(std::forward<Property>(property)...),
181  helper_type::readonly,
182  helper_type::shared,
183  &internal::MetaInfo<Type>::resolve,
184  &helper_type::setter,
185  [](const void *instance) {
186  return MetaAny{static_cast<const Class *>(instance)->*Member};
187  },
188  [](const internal::MetaTypeNode * const other) {
189  return other == internal::MetaInfo<Type>::resolve();
190  },
191  []() {
192  static MetaData meta{&node};
193  return &meta;
194  }
195  };
196 
197  assert(!duplicate(HashedString{str}, node.next));
198  assert((!internal::MetaInfo<Class>::template data<std::integral_constant<Type Class:: *, Member>>));
199  internal::MetaInfo<Class>::template data<std::integral_constant<Type Class:: *, Member>> = &node;
200  type->data = &node;
201  return MetaFactory<Class>{};
202  }
203 
204  template<typename Type, Type Class:: *Member, typename... Property>
205  static std::enable_if_t<std::is_member_function_pointer<Type Class:: *>::value, MetaFactory<Class>>
206  member(const char *str, Property &&... property) ENTT_NOEXCEPT {
207  using helper_type = internal::ReflectionHelper<std::integral_constant<Type Class:: *, Member>>;
208  auto * const type = internal::MetaInfo<Class>::type;
209 
210  static internal::MetaFuncNode node{
211  HashedString{str},
212  type->func,
213  properties<Class, std::integral_constant<Type Class:: *, Member>>(std::forward<Property>(property)...),
214  helper_type::size,
215  helper_type::constant,
216  helper_type::shared,
217  &internal::MetaInfo<typename helper_type::return_type>::resolve,
218  &helper_type::arg,
219  &helper_type::accept,
220  [](const void *instance, const MetaAny *any) {
221  return helper_type::invoke(0, instance, any, std::make_index_sequence<helper_type::size>{});
222  },
223  [](void *instance, const MetaAny *any) {
224  return helper_type::invoke(0, instance, any, std::make_index_sequence<helper_type::size>{});
225  },
226  []() {
227  static MetaFunc meta{&node};
228  return &meta;
229  }
230  };
231 
232  assert(!duplicate(HashedString{str}, node.next));
233  assert((!internal::MetaInfo<Class>::template func<std::integral_constant<Type Class:: *, Member>>));
234  internal::MetaInfo<Class>::template func<std::integral_constant<Type Class:: *, Member>> = &node;
235  type->func = &node;
236  return MetaFactory<Class>{};
237  }
238  };
239 
240  template<typename Name, typename Node>
241  inline static bool duplicate(const Name &name, const Node *node) ENTT_NOEXCEPT {
242  return node ? node->name == name || duplicate(name, node->next) : false;
243  }
244 
245  inline static bool duplicate(const MetaAny &key, const internal::MetaPropNode *node) ENTT_NOEXCEPT {
246  return node ? node->key() == key || duplicate(key, node->next) : false;
247  }
248 
249  template<typename...>
250  static internal::MetaPropNode * properties() {
251  return nullptr;
252  }
253 
254  template<typename Type, typename Owner, typename Property, typename... Other>
255  static internal::MetaPropNode * properties(const Property &property, const Other &... other) {
256  static const MetaAny key{property.first};
257  static const MetaAny value{property.second};
258 
259  static internal::MetaPropNode node{
260  properties<Type, Owner>(other...),
261  []() -> const MetaAny & {
262  return key;
263  },
264  []() -> const MetaAny & {
265  return value;
266  },
267  []() {
268  static MetaProp meta{&node};
269  return &meta;
270  }
271  };
272 
273  assert(!duplicate(key, node.next));
274  assert((!internal::MetaInfo<Type>::template prop<Owner, Property, Other...>));
275  internal::MetaInfo<Type>::template prop<Owner, Property, Other...> = &node;
276  return &node;
277  }
278 
279  template<typename Type, typename... Property>
280  static MetaFactory<Type> reflect(HashedString name, Property &&... property) ENTT_NOEXCEPT {
281  static internal::MetaTypeNode node{
282  name,
283  internal::MetaInfo<>::type,
284  properties<Type, Type>(std::forward<Property>(property)...),
285  internal::TypeHelper<Type>::destroy,
286  []() {
287  static MetaType meta{&node};
288  return &meta;
289  }
290  };
291 
292  assert(!duplicate(name, node.next));
293  assert(!internal::MetaInfo<Type>::type);
294  internal::MetaInfo<Type>::type = &node;
295  internal::MetaInfo<>::type = &node;
296  return MetaFactory<Type>{};
297  }
298 
299 public:
300  template<typename Type>
301  using factory_type = MetaFactory<Type>;
302 
303  template<typename Type, typename... Property>
304  inline static factory_type<std::decay_t<Type>> reflect(const char *str, Property &&... property) ENTT_NOEXCEPT {
305  return reflect<std::decay_t<Type>>(HashedString{str}, std::forward<Property>(property)...);
306  }
307 
308  template<typename Type>
309  inline static MetaType * resolve() ENTT_NOEXCEPT {
310  return internal::MetaInfo<Type>::resolve()->meta();
311  }
312 
313  inline static MetaType * resolve(const char *str) ENTT_NOEXCEPT {
314  return internal::Utils::meta(HashedString{str}, internal::MetaInfo<>::type);
315  }
316 };
317 
318 
319 }
320 
321 
322 #endif // ENTT_META_FACTORY_HPP
+ + + + + +
entt
EnTT default namespace.
Definition: algorithm.hpp:10
+ + + +
entt::HashedString
Zero overhead resource identifier.
Definition: hashed_string.hpp:22
+ + + + + + + + + + +
+ +
+Generated by   +doxygen + 1.8.13 +
+ + diff --git a/family_8hpp_source.html b/family_8hpp_source.html index 41befce38..c727c484c 100644 --- a/family_8hpp_source.html +++ b/family_8hpp_source.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
diff --git a/files.html b/files.html index c47f3a91a..786fc6647 100644 --- a/files.html +++ b/files.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -77,30 +77,31 @@ $(function() {  monostate.hpp  ▼ entity  actor.hpp - entity.hpp - entt_traits.hpp - helper.hpp - prototype.hpp - registry.hpp - snapshot.hpp - sparse_set.hpp - utility.hpp - view.hpp - ▼ locator - locator.hpp - ▼ process - process.hpp - scheduler.hpp - ▼ resource - cache.hpp - handle.hpp - loader.hpp - ▼ signal - delegate.hpp - dispatcher.hpp - emitter.hpp - sigh.hpp - entt.hpp + attachee.hpp + entity.hpp + entt_traits.hpp + helper.hpp + prototype.hpp + registry.hpp + snapshot.hpp + sparse_set.hpp + utility.hpp + view.hpp + ▼ locator + locator.hpp + ▼ process + process.hpp + scheduler.hpp + ▼ resource + cache.hpp + handle.hpp + loader.hpp + ▼ signal + delegate.hpp + dispatcher.hpp + emitter.hpp + sigh.hpp + entt.hpp
diff --git a/functions.html b/functions.html index d95e9d205..e016ee8b5 100644 --- a/functions.html +++ b/functions.html @@ -22,7 +22,7 @@
EnTT -  2.7.2 +  2.7.3
@@ -71,7 +71,7 @@ $(function() { , entt::Registry< Entity >
  • Actor() -: entt::Actor< Entity > +: entt::Actor< Entity >
  • alive() : entt::Process< Derived, Delta > @@ -83,7 +83,11 @@ $(function() { , entt::Registry< Entity >
  • attach() -: entt::Scheduler< Delta > +: entt::Scheduler< Delta > +
    • +
  • Attachee() +: entt::Attachee< Entity > +, entt::Attachee< Entity, Type >
  • attachee() : entt::Registry< Entity > diff --git a/functions_0x7e.html b/functions_0x7e.html index c2e51b85e..1dffb8354 100644 --- a/functions_0x7e.html +++ b/functions_0x7e.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    @@ -65,6 +65,10 @@ $(function() {
  • ~Actor() : entt::Actor< Entity >
    • +
  • ~Attachee() +: entt::Attachee< Entity > +, entt::Attachee< Entity, Type > +
  • ~Emitter() : entt::Emitter< Derived >
    • diff --git a/functions_b.html b/functions_b.html index 02b4456a1..4eb10204b 100644 --- a/functions_b.html +++ b/functions_b.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    diff --git a/functions_c.html b/functions_c.html index 81b575a62..75b5e632c 100644 --- a/functions_c.html +++ b/functions_c.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    @@ -102,7 +102,7 @@ $(function() { : entt::Registry< Entity >
  • connect() -: entt::Delegate< Ret(Args...)> +: entt::Delegate< Ret(Args...)> , entt::Sink< Ret(Args...)>
  • Connection() @@ -117,7 +117,9 @@ $(function() { , entt::View< Entity, Component >
  • construct() -: entt::SparseSet< Entity > +: entt::Attachee< Entity > +, entt::Attachee< Entity, Type > +, entt::SparseSet< Entity > , entt::SparseSet< Entity, Type >
  • construction() diff --git a/functions_d.html b/functions_d.html index a345ba7bc..79f645615 100644 --- a/functions_d.html +++ b/functions_d.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    @@ -79,7 +79,9 @@ $(function() { : entt::Process< Derived, Delta >
  • destroy() -: entt::Registry< Entity > +: entt::Attachee< Entity > +, entt::Attachee< Entity, Type > +, entt::Registry< Entity > , entt::SparseSet< Entity > , entt::SparseSet< Entity, Type >
    • @@ -101,7 +103,7 @@ $(function() { , entt::ResourceCache< Resource >
  • disconnect() -: entt::Sink< Ret(Args...)> +: entt::Sink< Ret(Args...)>
    • diff --git a/functions_e.html b/functions_e.html index 28de690af..1a3fa6f54 100644 --- a/functions_e.html +++ b/functions_e.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    @@ -90,7 +90,7 @@ $(function() {
  • end() : entt::PersistentView< Entity, Component > , entt::RawView< Entity, Component > -, entt::RuntimeView< Entity > +, entt::RuntimeView< Entity > , entt::SparseSet< Entity > , entt::SparseSet< Entity, Type > , entt::View< Entity, Component > @@ -108,9 +108,9 @@ $(function() { , entt::Registry< Entity >
  • entity_mask -: entt::entt_traits< std::uint16_t > -, entt::entt_traits< std::uint32_t > -, entt::entt_traits< std::uint64_t > +: entt::entt_traits< std::uint16_t > +, entt::entt_traits< std::uint32_t > +, entt::entt_traits< std::uint64_t >
  • entity_shift : entt::entt_traits< std::uint16_t > @@ -119,6 +119,8 @@ $(function() {
  • entity_type : entt::Actor< Entity > +, entt::Attachee< Entity > +, entt::Attachee< Entity, Type > , entt::ContinuousLoader< Entity > , entt::entt_traits< std::uint16_t > , entt::entt_traits< std::uint32_t > diff --git a/functions_f.html b/functions_f.html index c1ba99d44..4bd4b4724 100644 --- a/functions_f.html +++ b/functions_f.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    diff --git a/functions_func.html b/functions_func.html index f6c079373..c5400101f 100644 --- a/functions_func.html +++ b/functions_func.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    @@ -71,7 +71,7 @@ $(function() { , entt::Registry< Entity >
  • Actor() -: entt::Actor< Entity > +: entt::Actor< Entity >
  • alive() : entt::Process< Derived, Delta > @@ -83,7 +83,11 @@ $(function() { , entt::Registry< Entity >
  • attach() -: entt::Scheduler< Delta > +: entt::Scheduler< Delta > +
    • +
  • Attachee() +: entt::Attachee< Entity > +, entt::Attachee< Entity, Type >
  • attachee() : entt::Registry< Entity > diff --git a/functions_func_0x7e.html b/functions_func_0x7e.html index d47b84fe2..077b45d9f 100644 --- a/functions_func_0x7e.html +++ b/functions_func_0x7e.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    @@ -65,6 +65,10 @@ $(function() {
  • ~Actor() : entt::Actor< Entity >
    • +
  • ~Attachee() +: entt::Attachee< Entity > +, entt::Attachee< Entity, Type > +
  • ~Emitter() : entt::Emitter< Derived >
    • diff --git a/functions_func_b.html b/functions_func_b.html index 3d0cb0e0f..7b607a591 100644 --- a/functions_func_b.html +++ b/functions_func_b.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    diff --git a/functions_func_c.html b/functions_func_c.html index eaf7c88cc..499f883e0 100644 --- a/functions_func_c.html +++ b/functions_func_c.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    @@ -100,10 +100,12 @@ $(function() { , entt::Sink< Ret(Args...)>
  • Connection() -: entt::Emitter< Derived >::Connection< Event > +: entt::Emitter< Derived >::Connection< Event >
  • construct() -: entt::SparseSet< Entity > +: entt::Attachee< Entity > +, entt::Attachee< Entity, Type > +, entt::SparseSet< Entity > , entt::SparseSet< Entity, Type >
  • construction() @@ -117,10 +119,10 @@ $(function() { , entt::View< Entity, Component >
  • ContinuousLoader() -: entt::ContinuousLoader< Entity > +: entt::ContinuousLoader< Entity >
  • create() -: entt::Prototype< Entity > +: entt::Prototype< Entity > , entt::Registry< Entity >
  • current() diff --git a/functions_func_d.html b/functions_func_d.html index 6ad836799..ac6b7eddf 100644 --- a/functions_func_d.html +++ b/functions_func_d.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    @@ -76,7 +76,9 @@ $(function() { : entt::Delegate< Ret(Args...)>
  • destroy() -: entt::Registry< Entity > +: entt::Attachee< Entity > +, entt::Attachee< Entity, Type > +, entt::Registry< Entity > , entt::SparseSet< Entity > , entt::SparseSet< Entity, Type >
    • @@ -86,14 +88,14 @@ $(function() { , entt::SnapshotLoader< Entity >
  • destruction() -: entt::Registry< Entity > +: entt::Registry< Entity >
  • discard() : entt::Registry< Entity > , entt::ResourceCache< Resource >
  • disconnect() -: entt::Sink< Ret(Args...)> +: entt::Sink< Ret(Args...)>
    • diff --git a/functions_func_e.html b/functions_func_e.html index 98f83b777..bcf0560ce 100644 --- a/functions_func_e.html +++ b/functions_func_e.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    diff --git a/functions_func_f.html b/functions_func_f.html index 0ecfea209..76a722cf1 100644 --- a/functions_func_f.html +++ b/functions_func_f.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    diff --git a/functions_func_g.html b/functions_func_g.html index 8400e4910..7038f4629 100644 --- a/functions_func_g.html +++ b/functions_func_g.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    @@ -64,15 +64,17 @@ $(function() {

    - g -

    diff --git a/functions_func_h.html b/functions_func_h.html index bdc6a202d..4ccae51c7 100644 --- a/functions_func_h.html +++ b/functions_func_h.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    diff --git a/functions_func_l.html b/functions_func_l.html index c7fb14c6f..019161380 100644 --- a/functions_func_l.html +++ b/functions_func_l.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    diff --git a/functions_func_m.html b/functions_func_m.html index 6b20d3d22..c50a4b6ea 100644 --- a/functions_func_m.html +++ b/functions_func_m.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    @@ -66,7 +66,8 @@ $(function() { : entt::ContinuousLoader< Entity >
  • move() -: entt::Registry< Entity > +: entt::Attachee< Entity, Type > +, entt::Registry< Entity >
    • diff --git a/functions_func_o.html b/functions_func_o.html index d1bbdd275..87bff096f 100644 --- a/functions_func_o.html +++ b/functions_func_o.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    @@ -97,20 +97,22 @@ $(function() { : entt::ResourceHandle< Resource >
  • operator=() -: entt::Actor< Entity > +: entt::Actor< Entity > +, entt::Attachee< Entity > +, entt::Attachee< Entity, Type > , entt::ContinuousLoader< Entity > -, entt::Emitter< Derived >::Connection< Event > +, entt::Emitter< Derived >::Connection< Event > , entt::Emitter< Derived > , entt::Monostate< hash_type > , entt::Prototype< Entity > , entt::Registry< Entity > , entt::ResourceCache< Resource > -, entt::ResourceHandle< Resource > -, entt::Scheduler< Delta > +, entt::ResourceHandle< Resource > +, entt::Scheduler< Delta > , entt::Snapshot< Entity > -, entt::SnapshotLoader< Entity > -, entt::SparseSet< Entity > -, entt::SparseSet< Entity, Type > +, entt::SnapshotLoader< Entity > +, entt::SparseSet< Entity > +, entt::SparseSet< Entity, Type >
  • operator==() : entt::Delegate< Ret(Args...)> @@ -119,7 +121,7 @@ $(function() {
  • operator[]() : entt::PersistentView< Entity, Component > -, entt::RawView< Entity, Component > +, entt::RawView< Entity, Component > , entt::SparseSet< Entity > , entt::SparseSet< Entity, Type > , entt::View< Entity, Component > diff --git a/functions_func_p.html b/functions_func_p.html index 71b72cea1..3ac69af0b 100644 --- a/functions_func_p.html +++ b/functions_func_p.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    diff --git a/functions_func_r.html b/functions_func_r.html index f73c7e39e..92a7c711f 100644 --- a/functions_func_r.html +++ b/functions_func_r.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    diff --git a/functions_func_s.html b/functions_func_s.html index c077f683f..830fea15b 100644 --- a/functions_func_s.html +++ b/functions_func_s.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    diff --git a/functions_func_t.html b/functions_func_t.html index 3d69fe72f..450f54f24 100644 --- a/functions_func_t.html +++ b/functions_func_t.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    diff --git a/functions_func_u.html b/functions_func_u.html index ec079962c..263459f75 100644 --- a/functions_func_u.html +++ b/functions_func_u.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    diff --git a/functions_func_v.html b/functions_func_v.html index db7cac2a8..cf06482e1 100644 --- a/functions_func_v.html +++ b/functions_func_v.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    diff --git a/functions_g.html b/functions_g.html index a8113d9dc..434a90b94 100644 --- a/functions_g.html +++ b/functions_g.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    @@ -64,15 +64,17 @@ $(function() {

    - g -

    diff --git a/functions_h.html b/functions_h.html index 5bc7ba89e..aa45d4a60 100644 --- a/functions_h.html +++ b/functions_h.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    diff --git a/functions_i.html b/functions_i.html index 0e023ce48..e4030596e 100644 --- a/functions_i.html +++ b/functions_i.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    diff --git a/functions_l.html b/functions_l.html index 26be31801..e0b24510f 100644 --- a/functions_l.html +++ b/functions_l.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    diff --git a/functions_m.html b/functions_m.html index 1587045c1..00e99a3d8 100644 --- a/functions_m.html +++ b/functions_m.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    @@ -66,7 +66,8 @@ $(function() { : entt::ContinuousLoader< Entity >
  • move() -: entt::Registry< Entity > +: entt::Attachee< Entity, Type > +, entt::Registry< Entity >
    • diff --git a/functions_o.html b/functions_o.html index 33fdc78f8..8359603cc 100644 --- a/functions_o.html +++ b/functions_o.html @@ -22,7 +22,7 @@
    EnTT -  2.7.2 +  2.7.3
    @@ -63,7 +63,8 @@ $(function() {

    - o -