75 lines
27 KiB
HTML
75 lines
27 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.2.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> * [Runtime reflection system](#runtime-reflection-system)</div><div class="line"><a name="l00014"></a><span class="lineno"> 14</span> * [Allocations: the dark side of the force](#allocations-the-dark-side-of-the-force)</div><div class="line"><a name="l00015"></a><span class="lineno"> 15</span> <!--</div><div class="line"><a name="l00016"></a><span class="lineno"> 16</span> @endcond TURN_OFF_DOXYGEN</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> </div><div class="line"><a name="l00019"></a><span class="lineno"> 19</span> # Introduction</div><div class="line"><a name="l00020"></a><span class="lineno"> 20</span> </div><div class="line"><a name="l00021"></a><span class="lineno"> 21</span> `EnTT` has historically had a limit when used across boundaries on Windows in</div><div class="line"><a name="l00022"></a><span class="lineno"> 22</span> general and on GNU/Linux when default visibility was set to _hidden_. The</div><div class="line"><a name="l00023"></a><span class="lineno"> 23</span> limitation is due mainly to a custom utility used to assign unique, sequential</div><div class="line"><a name="l00024"></a><span class="lineno"> 24</span> identifiers to different types. Unfortunately, this tool is used by several core</div><div class="line"><a name="l00025"></a><span class="lineno"> 25</span> classes (the `registry` among the others) that are thus almost unusable across</div><div class="line"><a name="l00026"></a><span class="lineno"> 26</span> boundaries.<br/></div><div class="line"><a name="l00027"></a><span class="lineno"> 27</span> The reasons for that are beyond the purposes of this document. However, the good</div><div class="line"><a name="l00028"></a><span class="lineno"> 28</span> news is that `EnTT` also offers now a way to overcome this limit and to push</div><div class="line"><a name="l00029"></a><span class="lineno"> 29</span> things across boundaries without problems when needed.</div><div class="line"><a name="l00030"></a><span class="lineno"> 30</span> </div><div class="line"><a name="l00031"></a><span class="lineno"> 31</span> # Named types and traits class</div><div class="line"><a name="l00032"></a><span class="lineno"> 32</span> </div><div class="line"><a name="l00033"></a><span class="lineno"> 33</span> To allow a type to work properly across boundaries when used by a class that</div><div class="line"><a name="l00034"></a><span class="lineno"> 34</span> requires to assign unique identifiers to types, users must specialize a class</div><div class="line"><a name="l00035"></a><span class="lineno"> 35</span> template to literally give a compile-time name to the type itself.<br/></div><div class="line"><a name="l00036"></a><span class="lineno"> 36</span> The name of the class template is `name_type_traits` and the specialization must</div><div class="line"><a name="l00037"></a><span class="lineno"> 37</span> be such that it exposes a static constexpr data member named `value` having type</div><div class="line"><a name="l00038"></a><span class="lineno"> 38</span> either `ENTT_ID_TYPE` or `entt::hashed_string::hash_type`. Its value is the user</div><div class="line"><a name="l00039"></a><span class="lineno"> 39</span> defined unique identifier assigned to the specific type.<br/></div><div class="line"><a name="l00040"></a><span class="lineno"> 40</span> Identifiers are not to be sequentially generated in this case.</div><div class="line"><a name="l00041"></a><span class="lineno"> 41</span> </div><div class="line"><a name="l00042"></a><span class="lineno"> 42</span> As an example:</div><div class="line"><a name="l00043"></a><span class="lineno"> 43</span> </div><div class="line"><a name="l00044"></a><span class="lineno"> 44</span> ```cpp</div><div class="line"><a name="l00045"></a><span class="lineno"> 45</span> struct my_type { /* ... */ };</div><div class="line"><a name="l00046"></a><span class="lineno"> 46</span> </div><div class="line"><a name="l00047"></a><span class="lineno"> 47</span> template<></div><div class="line"><a name="l00048"></a><span class="lineno"> 48</span> struct entt::named_type_traits<my_type> {</div><div class="line"><a name="l00049"></a><span class="lineno"> 49</span>  static constexpr auto value = "my_type"_hs;</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> </div><div class="line"><a name="l00053"></a><span class="lineno"> 53</span> Because of the rules of the language, the specialization must reside in the</div><div class="line"><a name="l00054"></a><span class="lineno"> 54</span> global namespace or in the `entt` namespace. There is no way to change this rule</div><div class="line"><a name="l00055"></a><span class="lineno"> 55</span> unfortunately, because it doesn't depend on the library itself.</div><div class="line"><a name="l00056"></a><span class="lineno"> 56</span> </div><div class="line"><a name="l00057"></a><span class="lineno"> 57</span> The good aspect of this approach is that it's not intrusive at all. The other</div><div class="line"><a name="l00058"></a><span class="lineno"> 58</span> way around was in fact forcing users to inherit all their classes from a common</div><div class="line"><a name="l00059"></a><span class="lineno"> 59</span> base. Something to avoid, at least from my point of view.<br/></div><div class="line"><a name="l00060"></a><span class="lineno"> 60</span> However, despite the fact that it's not intrusive, it would be great if it was</div><div class="line"><a name="l00061"></a><span class="lineno"> 61</span> also easier to use and a bit less error-prone. This is why a bunch of macros</div><div class="line"><a name="l00062"></a><span class="lineno"> 62</span> exist to ease defining named types.</div><div class="line"><a name="l00063"></a><span class="lineno"> 63</span> </div><div class="line"><a name="l00064"></a><span class="lineno"> 64</span> ## Do not mix types</div><div class="line"><a name="l00065"></a><span class="lineno"> 65</span> </div><div class="line"><a name="l00066"></a><span class="lineno"> 66</span> Someone might think that this trick is valid only for the types to push across</div><div class="line"><a name="l00067"></a><span class="lineno"> 67</span> boundaries. This isn't how things work. In fact, the problem is more complex</div><div class="line"><a name="l00068"></a><span class="lineno"> 68</span> than that.<br/></div><div class="line"><a name="l00069"></a><span class="lineno"> 69</span> As a rule of thumb, users should never mix named and non-named types. Whenever</div><div class="line"><a name="l00070"></a><span class="lineno"> 70</span> a type is given a name, all the types must be given a name. As an example,</div><div class="line"><a name="l00071"></a><span class="lineno"> 71</span> consider the `registry` class template: in case it is pushed across boundaries,</div><div class="line"><a name="l00072"></a><span class="lineno"> 72</span> all the types of components should be assigned a name to avoid subtle bugs.</div><div class="line"><a name="l00073"></a><span class="lineno"> 73</span> </div><div class="line"><a name="l00074"></a><span class="lineno"> 74</span> Indeed, this constraint can be relaxed in many cases. However, it is difficult</div><div class="line"><a name="l00075"></a><span class="lineno"> 75</span> to define a general rule to follow that is not the most stringent, unless users</div><div class="line"><a name="l00076"></a><span class="lineno"> 76</span> know exactly what they are doing. Therefore, I won't elaborate on giving further</div><div class="line"><a name="l00077"></a><span class="lineno"> 77</span> details on the topic.</div><div class="line"><a name="l00078"></a><span class="lineno"> 78</span> </div><div class="line"><a name="l00079"></a><span class="lineno"> 79</span> # Macros, macros everywhere</div><div class="line"><a name="l00080"></a><span class="lineno"> 80</span> </div><div class="line"><a name="l00081"></a><span class="lineno"> 81</span> The library comes with a set of predefined macros to use to declare named types</div><div class="line"><a name="l00082"></a><span class="lineno"> 82</span> or export already existing ones. In particular:</div><div class="line"><a name="l00083"></a><span class="lineno"> 83</span> </div><div class="line"><a name="l00084"></a><span class="lineno"> 84</span> * `ENTT_NAMED_TYPE` can be used to assign a name to already existing types. This</div><div class="line"><a name="l00085"></a><span class="lineno"> 85</span>  macro must be used in the global namespace even when the types to be named are</div><div class="line"><a name="l00086"></a><span class="lineno"> 86</span>  not.</div><div class="line"><a name="l00087"></a><span class="lineno"> 87</span> </div><div class="line"><a name="l00088"></a><span class="lineno"> 88</span>  ```cpp</div><div class="line"><a name="l00089"></a><span class="lineno"> 89</span>  ENTT_NAMED_TYPE(my_type)</div><div class="line"><a name="l00090"></a><span class="lineno"> 90</span>  ENTT_NAMED_TYPE(ns::another_type)</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> </div><div class="line"><a name="l00093"></a><span class="lineno"> 93</span> * `ENTT_NAMED_STRUCT` can be used to define and export a struct at the same</div><div class="line"><a name="l00094"></a><span class="lineno"> 94</span>  time. It accepts also an optional namespace in which to define the given type.</div><div class="line"><a name="l00095"></a><span class="lineno"> 95</span>  This macro must be used in the global namespace.</div><div class="line"><a name="l00096"></a><span class="lineno"> 96</span> </div><div class="line"><a name="l00097"></a><span class="lineno"> 97</span>  ```cpp</div><div class="line"><a name="l00098"></a><span class="lineno"> 98</span>  ENTT_NAMED_STRUCT(my_type, { /* struct definition */})</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>  ENTT_NAMED_STRUCT(ns, another_type, { /* struct definition */})</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> </div><div class="line"><a name="l00102"></a><span class="lineno"> 102</span> * `ENTT_NAMED_CLASS` can be used to define and export a class at the same</div><div class="line"><a name="l00103"></a><span class="lineno"> 103</span>  time. It accepts also an optional namespace in which to define the given type.</div><div class="line"><a name="l00104"></a><span class="lineno"> 104</span>  This macro must be used in the global namespace.</div><div class="line"><a name="l00105"></a><span class="lineno"> 105</span> </div><div class="line"><a name="l00106"></a><span class="lineno"> 106</span>  ```cpp</div><div class="line"><a name="l00107"></a><span class="lineno"> 107</span>  ENTT_NAMED_CLASS(my_type, { /* class definition */})</div><div class="line"><a name="l00108"></a><span class="lineno"> 108</span>  ENTT_NAMED_CLASS(ns, another_type, { /* class definition */})</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> </div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span> Nested namespaces are supported out of the box as well in all cases. As an</div><div class="line"><a name="l00112"></a><span class="lineno"> 112</span> example:</div><div class="line"><a name="l00113"></a><span class="lineno"> 113</span> </div><div class="line"><a name="l00114"></a><span class="lineno"> 114</span> ```cpp</div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span> ENTT_NAMED_STRUCT(nested::ns, my_type, { /* struct definition */})</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> </div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span> These macros can be used to avoid specializing the `named_type_traits` class</div><div class="line"><a name="l00119"></a><span class="lineno"> 119</span> template. In all cases, the name of the class is used also as a seed to generate</div><div class="line"><a name="l00120"></a><span class="lineno"> 120</span> the compile-time unique identifier.</div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span> </div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span> ## Conflicts</div><div class="line"><a name="l00123"></a><span class="lineno"> 123</span> </div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span> When using macros, unique identifiers are 32/64 bit integers generated by</div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span> hashing strings during compilation. Therefore, conflicts are rare but still</div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> possible. In case of conflicts, everything simply will get broken at runtime and</div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> the strangest things will probably take place.<br/></div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span> Unfortunately, there is no safe way to prevent it. If this happens, it will be</div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span> enough to give a different value to one of the conflicting types to solve the</div><div class="line"><a name="l00130"></a><span class="lineno"> 130</span> problem. To do this, users can either assign a different name to the class or</div><div class="line"><a name="l00131"></a><span class="lineno"> 131</span> directly define a specialization for the `named_type_traits` class template.</div><div class="line"><a name="l00132"></a><span class="lineno"> 132</span> </div><div class="line"><a name="l00133"></a><span class="lineno"> 133</span> # Runtime reflection system</div><div class="line"><a name="l00134"></a><span class="lineno"> 134</span> </div><div class="line"><a name="l00135"></a><span class="lineno"> 135</span> The runtime reflection system deserves a special mention when it comes to using</div><div class="line"><a name="l00136"></a><span class="lineno"> 136</span> it across boundaries.<br/></div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span> As in all other cases, it's necessary to give a name to the types. However, this</div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span> time this isn't enough to get the job done.</div><div class="line"><a name="l00139"></a><span class="lineno"> 139</span> </div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span> The runtime reflection system is linked to a static context to which the visible</div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span> components are linked. A component is visible when it's given a name, so the</div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span> named components are implicitly visible.<br/></div><div class="line"><a name="l00143"></a><span class="lineno"> 143</span> Different contexts don't relate to each other. Therefore, to allow the use of</div><div class="line"><a name="l00144"></a><span class="lineno"> 144</span> named types across boundaries, a context must also be shared.</div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span> </div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span> Sharing a context is straightforward. First of all, the local one must be</div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span> acquired:</div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span> </div><div class="line"><a name="l00149"></a><span class="lineno"> 149</span> ```</div><div class="line"><a name="l00150"></a><span class="lineno"> 150</span> entt::meta_ctx ctx{};</div><div class="line"><a name="l00151"></a><span class="lineno"> 151</span> ```</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> Then, it must be pushed across boundaries and the receiving space must set it as</div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span> its global context, thus releasing the local one that remains available but is</div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span> no longer referred to by the runtime reflection system:</div><div class="line"><a name="l00156"></a><span class="lineno"> 156</span> </div><div class="line"><a name="l00157"></a><span class="lineno"> 157</span> ```</div><div class="line"><a name="l00158"></a><span class="lineno"> 158</span> entt::meta_ctx::bind(ctx);</div><div class="line"><a name="l00159"></a><span class="lineno"> 159</span> ```</div><div class="line"><a name="l00160"></a><span class="lineno"> 160</span> </div><div class="line"><a name="l00161"></a><span class="lineno"> 161</span> From now on, both spaces will refer to the same context and on it will be</div><div class="line"><a name="l00162"></a><span class="lineno"> 162</span> associated the new visible meta types, no matter _where_ they are created.</div><div class="line"><a name="l00163"></a><span class="lineno"> 163</span> </div><div class="line"><a name="l00164"></a><span class="lineno"> 164</span> A context can also be reset and then associated again locally as:</div><div class="line"><a name="l00165"></a><span class="lineno"> 165</span> </div><div class="line"><a name="l00166"></a><span class="lineno"> 166</span> ```</div><div class="line"><a name="l00167"></a><span class="lineno"> 167</span> entt::meta_ctx::bind{entt::meta_ctx{});</div><div class="line"><a name="l00168"></a><span class="lineno"> 168</span> ```</div><div class="line"><a name="l00169"></a><span class="lineno"> 169</span> </div><div class="line"><a name="l00170"></a><span class="lineno"> 170</span> This is allowed because local and global contexts are separated. Therefore, it's</div><div class="line"><a name="l00171"></a><span class="lineno"> 171</span> always possible to make the local context the current one again.</div><div class="line"><a name="l00172"></a><span class="lineno"> 172</span> </div><div class="line"><a name="l00173"></a><span class="lineno"> 173</span> # Allocations: the dark side of the force</div><div class="line"><a name="l00174"></a><span class="lineno"> 174</span> </div><div class="line"><a name="l00175"></a><span class="lineno"> 175</span> As long as `EnTT` won't support custom allocators, another problem with</div><div class="line"><a name="l00176"></a><span class="lineno"> 176</span> allocations will remain alive instead. This is in fact easily solved, or at</div><div class="line"><a name="l00177"></a><span class="lineno"> 177</span> least it is if one knows it.</div><div class="line"><a name="l00178"></a><span class="lineno"> 178</span> </div><div class="line"><a name="l00179"></a><span class="lineno"> 179</span> To allow users to add types dynamically, the library makes extensive use of type</div><div class="line"><a name="l00180"></a><span class="lineno"> 180</span> erasure techniques and dynamic allocations for pools (whether they are for</div><div class="line"><a name="l00181"></a><span class="lineno"> 181</span> components, events or anything else). The problem occurs when, for example, a</div><div class="line"><a name="l00182"></a><span class="lineno"> 182</span> registry is created on one side of a boundary and a pool is dynamically created</div><div class="line"><a name="l00183"></a><span class="lineno"> 183</span> on the other side. In the best case, everything will crash at the exit, while at</div><div class="line"><a name="l00184"></a><span class="lineno"> 184</span> worst it will do so at runtime.<br/></div><div class="line"><a name="l00185"></a><span class="lineno"> 185</span> To avoid problems, the pools must be generated from the same side of the</div><div class="line"><a name="l00186"></a><span class="lineno"> 186</span> boundary where the object that owns them is also created. As an example, when</div><div class="line"><a name="l00187"></a><span class="lineno"> 187</span> the registry is created in the main executable and used across boundaries for a</div><div class="line"><a name="l00188"></a><span class="lineno"> 188</span> given type of component, the pool for that type must be created before passing</div><div class="line"><a name="l00189"></a><span class="lineno"> 189</span> around the registry itself. To do this is fortunately quite easy, since it is</div><div class="line"><a name="l00190"></a><span class="lineno"> 190</span> sufficient to invoke any of the methods that involve the given type (continuing</div><div class="line"><a name="l00191"></a><span class="lineno"> 191</span> the example with the registry, a call to `reserve` or `size` is more than</div><div class="line"><a name="l00192"></a><span class="lineno"> 192</span> enough).</div><div class="line"><a name="l00193"></a><span class="lineno"> 193</span> </div><div class="line"><a name="l00194"></a><span class="lineno"> 194</span> Maybe one day some dedicated methods will be added that do nothing but create a</div><div class="line"><a name="l00195"></a><span class="lineno"> 195</span> pool for a given type. Until now it has been preferred to keep the API cleaner</div><div class="line"><a name="l00196"></a><span class="lineno"> 196</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>
|