75 lines
22 KiB
HTML
75 lines
22 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
|
|
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
|
|
<meta name="generator" content="Doxygen 1.8.13"/>
|
|
<meta name="viewport" content="width=device-width, initial-scale=1"/>
|
|
<title>EnTT: docs/md/lib.md Source File</title>
|
|
<link href="tabs.css" rel="stylesheet" type="text/css"/>
|
|
<script type="text/javascript" src="jquery.js"></script>
|
|
<script type="text/javascript" src="dynsections.js"></script>
|
|
<link href="search/search.css" rel="stylesheet" type="text/css"/>
|
|
<script type="text/javascript" src="search/searchdata.js"></script>
|
|
<script type="text/javascript" src="search/search.js"></script>
|
|
<link href="doxygen.css" rel="stylesheet" type="text/css" />
|
|
</head>
|
|
<body>
|
|
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
|
|
<div id="titlearea">
|
|
<table cellspacing="0" cellpadding="0">
|
|
<tbody>
|
|
<tr style="height: 56px;">
|
|
<td id="projectalign" style="padding-left: 0.5em;">
|
|
<div id="projectname">EnTT
|
|
 <span id="projectnumber">3.1.0</span>
|
|
</div>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
<!-- end header part -->
|
|
<!-- Generated by Doxygen 1.8.13 -->
|
|
<script type="text/javascript">
|
|
var searchBox = new SearchBox("searchBox", "search",false,'Search');
|
|
</script>
|
|
<script type="text/javascript" src="menudata.js"></script>
|
|
<script type="text/javascript" src="menu.js"></script>
|
|
<script type="text/javascript">
|
|
$(function() {
|
|
initMenu('',true,false,'search.php','Search');
|
|
$(document).ready(function() { init_search(); });
|
|
});
|
|
</script>
|
|
<div id="main-nav"></div>
|
|
</div><!-- top -->
|
|
<!-- window showing the filter options -->
|
|
<div id="MSearchSelectWindow"
|
|
onmouseover="return searchBox.OnSearchSelectShow()"
|
|
onmouseout="return searchBox.OnSearchSelectHide()"
|
|
onkeydown="return searchBox.OnSearchSelectKey(event)">
|
|
</div>
|
|
|
|
<!-- iframe showing the search results (closed by default) -->
|
|
<div id="MSearchResultsWindow">
|
|
<iframe src="javascript:void(0)" frameborder="0"
|
|
name="MSearchResults" id="MSearchResults">
|
|
</iframe>
|
|
</div>
|
|
|
|
<div class="header">
|
|
<div class="headertitle">
|
|
<div class="title">docs/md/lib.md</div> </div>
|
|
</div><!--header-->
|
|
<div class="contents">
|
|
<div class="fragment"><div class="line"><a name="l00001"></a><span class="lineno"> 1</span> # Push EnTT across boundaries</div><div class="line"><a name="l00002"></a><span class="lineno"> 2</span> </div><div class="line"><a name="l00003"></a><span class="lineno"> 3</span> <!--</div><div class="line"><a name="l00004"></a><span class="lineno"> 4</span> @cond TURN_OFF_DOXYGEN</div><div class="line"><a name="l00005"></a><span class="lineno"> 5</span> --></div><div class="line"><a name="l00006"></a><span class="lineno"> 6</span> # Table of Contents</div><div class="line"><a name="l00007"></a><span class="lineno"> 7</span> </div><div class="line"><a name="l00008"></a><span class="lineno"> 8</span> * [Introduction](#introduction)</div><div class="line"><a name="l00009"></a><span class="lineno"> 9</span> * [Named types and traits class](#named-types-and-traits-class)</div><div class="line"><a name="l00010"></a><span class="lineno"> 10</span>  * [Do not mix types](#do-not-mix-types)</div><div class="line"><a name="l00011"></a><span class="lineno"> 11</span> * [Macros, macros everywhere](#macros-macros-everywhere)</div><div class="line"><a name="l00012"></a><span class="lineno"> 12</span>  * [Conflicts](#conflicts)</div><div class="line"><a name="l00013"></a><span class="lineno"> 13</span> * [Allocations: the dark side of the force](#allocations-the-dark-side-of-the-force)</div><div class="line"><a name="l00014"></a><span class="lineno"> 14</span> <!--</div><div class="line"><a name="l00015"></a><span class="lineno"> 15</span> @endcond TURN_OFF_DOXYGEN</div><div class="line"><a name="l00016"></a><span class="lineno"> 16</span> --></div><div class="line"><a name="l00017"></a><span class="lineno"> 17</span> </div><div class="line"><a name="l00018"></a><span class="lineno"> 18</span> # Introduction</div><div class="line"><a name="l00019"></a><span class="lineno"> 19</span> </div><div class="line"><a name="l00020"></a><span class="lineno"> 20</span> `EnTT` has historically had a limit when used across boundaries on Windows in</div><div class="line"><a name="l00021"></a><span class="lineno"> 21</span> general and on GNU/Linux when default visibility was set to _hidden_. The</div><div class="line"><a name="l00022"></a><span class="lineno"> 22</span> limitation is due mainly to a custom utility used to assign unique, sequential</div><div class="line"><a name="l00023"></a><span class="lineno"> 23</span> identifiers to different types. Unfortunately, this tool is used by several core</div><div class="line"><a name="l00024"></a><span class="lineno"> 24</span> classes (the `registry` among the others) that are thus almost unusable across</div><div class="line"><a name="l00025"></a><span class="lineno"> 25</span> boundaries.<br/></div><div class="line"><a name="l00026"></a><span class="lineno"> 26</span> The reasons for that are beyond the purposes of this document. However, the good</div><div class="line"><a name="l00027"></a><span class="lineno"> 27</span> news is that `EnTT` also offers now a way to overcome this limit and to push</div><div class="line"><a name="l00028"></a><span class="lineno"> 28</span> things across boundaries without problems when needed.</div><div class="line"><a name="l00029"></a><span class="lineno"> 29</span> </div><div class="line"><a name="l00030"></a><span class="lineno"> 30</span> # Named types and traits class</div><div class="line"><a name="l00031"></a><span class="lineno"> 31</span> </div><div class="line"><a name="l00032"></a><span class="lineno"> 32</span> To allow a type to work properly across boundaries when used by a class that</div><div class="line"><a name="l00033"></a><span class="lineno"> 33</span> requires to assign unique identifiers to types, users must specialize a class</div><div class="line"><a name="l00034"></a><span class="lineno"> 34</span> template to literally give a compile-time name to the type itself.<br/></div><div class="line"><a name="l00035"></a><span class="lineno"> 35</span> The name of the class template is `name_type_traits` and the specialization must</div><div class="line"><a name="l00036"></a><span class="lineno"> 36</span> be such that it exposes a static constexpr data member named `value` having type</div><div class="line"><a name="l00037"></a><span class="lineno"> 37</span> either `ENTT_ID_TYPE` or `entt::hashed_string::hash_type`. Its value is the user</div><div class="line"><a name="l00038"></a><span class="lineno"> 38</span> defined unique identifier assigned to the specific type.<br/></div><div class="line"><a name="l00039"></a><span class="lineno"> 39</span> Identifiers are not to be sequentially generated in this case.</div><div class="line"><a name="l00040"></a><span class="lineno"> 40</span> </div><div class="line"><a name="l00041"></a><span class="lineno"> 41</span> As an example:</div><div class="line"><a name="l00042"></a><span class="lineno"> 42</span> </div><div class="line"><a name="l00043"></a><span class="lineno"> 43</span> ```cpp</div><div class="line"><a name="l00044"></a><span class="lineno"> 44</span> struct my_type { /* ... */ };</div><div class="line"><a name="l00045"></a><span class="lineno"> 45</span> </div><div class="line"><a name="l00046"></a><span class="lineno"> 46</span> template<></div><div class="line"><a name="l00047"></a><span class="lineno"> 47</span> struct entt::named_type_traits<my_type> {</div><div class="line"><a name="l00048"></a><span class="lineno"> 48</span>  static constexpr auto value = "my_type"_hs;</div><div class="line"><a name="l00049"></a><span class="lineno"> 49</span> };</div><div class="line"><a name="l00050"></a><span class="lineno"> 50</span> ```</div><div class="line"><a name="l00051"></a><span class="lineno"> 51</span> </div><div class="line"><a name="l00052"></a><span class="lineno"> 52</span> Because of the rules of the language, the specialization must reside in the</div><div class="line"><a name="l00053"></a><span class="lineno"> 53</span> global namespace or in the `entt` namespace. There is no way to change this rule</div><div class="line"><a name="l00054"></a><span class="lineno"> 54</span> unfortunately, because it doesn't depend on the library itself.</div><div class="line"><a name="l00055"></a><span class="lineno"> 55</span> </div><div class="line"><a name="l00056"></a><span class="lineno"> 56</span> The good aspect of this approach is that it's not intrusive at all. The other</div><div class="line"><a name="l00057"></a><span class="lineno"> 57</span> way around was in fact forcing users to inherit all their classes from a common</div><div class="line"><a name="l00058"></a><span class="lineno"> 58</span> base. Something to avoid, at least from my point of view.<br/></div><div class="line"><a name="l00059"></a><span class="lineno"> 59</span> However, despite the fact that it's not intrusive, it would be great if it was</div><div class="line"><a name="l00060"></a><span class="lineno"> 60</span> also easier to use and a bit less error-prone. This is why a bunch of macros</div><div class="line"><a name="l00061"></a><span class="lineno"> 61</span> exist to ease defining named types.</div><div class="line"><a name="l00062"></a><span class="lineno"> 62</span> </div><div class="line"><a name="l00063"></a><span class="lineno"> 63</span> ## Do not mix types</div><div class="line"><a name="l00064"></a><span class="lineno"> 64</span> </div><div class="line"><a name="l00065"></a><span class="lineno"> 65</span> Someone might think that this trick is valid only for the types to push across</div><div class="line"><a name="l00066"></a><span class="lineno"> 66</span> boundaries. This isn't how things work. In fact, the problem is more complex</div><div class="line"><a name="l00067"></a><span class="lineno"> 67</span> than that.<br/></div><div class="line"><a name="l00068"></a><span class="lineno"> 68</span> As a rule of thumb, users should never mix named and non-named types. Whenever</div><div class="line"><a name="l00069"></a><span class="lineno"> 69</span> a type is given a name, all the types must be given a name. As an example,</div><div class="line"><a name="l00070"></a><span class="lineno"> 70</span> consider the `registry` class template: in case it is pushed across boundaries,</div><div class="line"><a name="l00071"></a><span class="lineno"> 71</span> all the types of components should be assigned a name to avoid subtle bugs.</div><div class="line"><a name="l00072"></a><span class="lineno"> 72</span> </div><div class="line"><a name="l00073"></a><span class="lineno"> 73</span> Indeed, this constraint can be relaxed in many cases. However, it is difficult</div><div class="line"><a name="l00074"></a><span class="lineno"> 74</span> to define a general rule to follow that is not the most stringent, unless users</div><div class="line"><a name="l00075"></a><span class="lineno"> 75</span> know exactly what they are doing. Therefore, I won't elaborate on giving further</div><div class="line"><a name="l00076"></a><span class="lineno"> 76</span> details on the topic.</div><div class="line"><a name="l00077"></a><span class="lineno"> 77</span> </div><div class="line"><a name="l00078"></a><span class="lineno"> 78</span> # Macros, macros everywhere</div><div class="line"><a name="l00079"></a><span class="lineno"> 79</span> </div><div class="line"><a name="l00080"></a><span class="lineno"> 80</span> The library comes with a set of predefined macros to use to declare named types</div><div class="line"><a name="l00081"></a><span class="lineno"> 81</span> or export already existing ones. In particular:</div><div class="line"><a name="l00082"></a><span class="lineno"> 82</span> </div><div class="line"><a name="l00083"></a><span class="lineno"> 83</span> * `ENTT_NAMED_TYPE` can be used to assign a name to already existing types. This</div><div class="line"><a name="l00084"></a><span class="lineno"> 84</span>  macro must be used in the global namespace even when the types to be named are</div><div class="line"><a name="l00085"></a><span class="lineno"> 85</span>  not.</div><div class="line"><a name="l00086"></a><span class="lineno"> 86</span> </div><div class="line"><a name="l00087"></a><span class="lineno"> 87</span>  ```cpp</div><div class="line"><a name="l00088"></a><span class="lineno"> 88</span>  ENTT_NAMED_TYPE(my_type)</div><div class="line"><a name="l00089"></a><span class="lineno"> 89</span>  ENTT_NAMED_TYPE(ns::another_type)</div><div class="line"><a name="l00090"></a><span class="lineno"> 90</span>  ```</div><div class="line"><a name="l00091"></a><span class="lineno"> 91</span> </div><div class="line"><a name="l00092"></a><span class="lineno"> 92</span> * `ENTT_NAMED_STRUCT` can be used to define and export a struct at the same</div><div class="line"><a name="l00093"></a><span class="lineno"> 93</span>  time. It accepts also an optional namespace in which to define the given type.</div><div class="line"><a name="l00094"></a><span class="lineno"> 94</span>  This macro must be used in the global namespace.</div><div class="line"><a name="l00095"></a><span class="lineno"> 95</span> </div><div class="line"><a name="l00096"></a><span class="lineno"> 96</span>  ```cpp</div><div class="line"><a name="l00097"></a><span class="lineno"> 97</span>  ENTT_NAMED_STRUCT(my_type, { /* struct definition */})</div><div class="line"><a name="l00098"></a><span class="lineno"> 98</span>  ENTT_NAMED_STRUCT(ns, another_type, { /* struct definition */})</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>  ```</div><div class="line"><a name="l00100"></a><span class="lineno"> 100</span> </div><div class="line"><a name="l00101"></a><span class="lineno"> 101</span> * `ENTT_NAMED_CLASS` can be used to define and export a class at the same</div><div class="line"><a name="l00102"></a><span class="lineno"> 102</span>  time. It accepts also an optional namespace in which to define the given type.</div><div class="line"><a name="l00103"></a><span class="lineno"> 103</span>  This macro must be used in the global namespace.</div><div class="line"><a name="l00104"></a><span class="lineno"> 104</span> </div><div class="line"><a name="l00105"></a><span class="lineno"> 105</span>  ```cpp</div><div class="line"><a name="l00106"></a><span class="lineno"> 106</span>  ENTT_NAMED_CLASS(my_type, { /* class definition */})</div><div class="line"><a name="l00107"></a><span class="lineno"> 107</span>  ENTT_NAMED_CLASS(ns, another_type, { /* class definition */})</div><div class="line"><a name="l00108"></a><span class="lineno"> 108</span>  ```</div><div class="line"><a name="l00109"></a><span class="lineno"> 109</span> </div><div class="line"><a name="l00110"></a><span class="lineno"> 110</span> Nested namespaces are supported out of the box as well in all cases. As an</div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span> example:</div><div class="line"><a name="l00112"></a><span class="lineno"> 112</span> </div><div class="line"><a name="l00113"></a><span class="lineno"> 113</span> ```cpp</div><div class="line"><a name="l00114"></a><span class="lineno"> 114</span> ENTT_NAMED_STRUCT(nested::ns, my_type, { /* struct definition */})</div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span> ```</div><div class="line"><a name="l00116"></a><span class="lineno"> 116</span> </div><div class="line"><a name="l00117"></a><span class="lineno"> 117</span> These macros can be used to avoid specializing the `named_type_traits` class</div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span> template. In all cases, the name of the class is used also as a seed to generate</div><div class="line"><a name="l00119"></a><span class="lineno"> 119</span> the compile-time unique identifier.</div><div class="line"><a name="l00120"></a><span class="lineno"> 120</span> </div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span> ## Conflicts</div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span> </div><div class="line"><a name="l00123"></a><span class="lineno"> 123</span> When using macros, unique identifiers are 32/64 bit integers generated by</div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span> hashing strings during compilation. Therefore, conflicts are rare but still</div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span> possible. In case of conflicts, everything simply will get broken at runtime and</div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> the strangest things will probably take place.<br/></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> Unfortunately, there is no safe way to prevent it. If this happens, it will be</div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span> enough to give a different value to one of the conflicting types to solve the</div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span> problem. To do this, users can either assign a different name to the class or</div><div class="line"><a name="l00130"></a><span class="lineno"> 130</span> directly define a specialization for the `named_type_traits` class template.</div><div class="line"><a name="l00131"></a><span class="lineno"> 131</span> </div><div class="line"><a name="l00132"></a><span class="lineno"> 132</span> # Allocations: the dark side of the force</div><div class="line"><a name="l00133"></a><span class="lineno"> 133</span> </div><div class="line"><a name="l00134"></a><span class="lineno"> 134</span> As long as `EnTT` won't support custom allocators, another problem with</div><div class="line"><a name="l00135"></a><span class="lineno"> 135</span> allocations will remain alive instead. This is in fact easily solved, or at</div><div class="line"><a name="l00136"></a><span class="lineno"> 136</span> least it is if one knows it.</div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span> </div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span> To allow users to add types dynamically, the library makes extensive use of type</div><div class="line"><a name="l00139"></a><span class="lineno"> 139</span> erasure techniques and dynamic allocations for pools (whether they are for</div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span> components, events or anything else). The problem occurs when, for example, a</div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span> registry is created on one side of a boundary and a pool is dynamically created</div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span> on the other side. In the best case, everything will crash at the exit, while at</div><div class="line"><a name="l00143"></a><span class="lineno"> 143</span> worst it will do so at runtime.<br/></div><div class="line"><a name="l00144"></a><span class="lineno"> 144</span> To avoid problems, the pools must be generated from the same side of the</div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span> boundary where the object that owns them is also created. As an example, when</div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span> the registry is created in the main executable and used across boundaries for a</div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span> given type of component, the pool for that type must be created before passing</div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span> around the registry itself. To do this is fortunately quite easy, since it is</div><div class="line"><a name="l00149"></a><span class="lineno"> 149</span> sufficient to invoke any of the methods that involve the given type (continuing</div><div class="line"><a name="l00150"></a><span class="lineno"> 150</span> the example with the registry, a call to `reserve` or `size` is more than</div><div class="line"><a name="l00151"></a><span class="lineno"> 151</span> enough).</div><div class="line"><a name="l00152"></a><span class="lineno"> 152</span> </div><div class="line"><a name="l00153"></a><span class="lineno"> 153</span> Maybe one day some dedicated methods will be added that do nothing but create a</div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span> pool for a given type. Until now it has been preferred to keep the API cleaner</div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span> as they are not strictly necessary.</div></div><!-- fragment --></div><!-- contents -->
|
|
<!-- start footer part -->
|
|
<hr class="footer"/><address class="footer"><small>
|
|
Generated by  <a href="http://www.doxygen.org/index.html">
|
|
<img class="footer" src="doxygen.png" alt="doxygen"/>
|
|
</a> 1.8.13
|
|
</small></address>
|
|
</body>
|
|
</html>
|