258 lines
23 KiB
HTML
258 lines
23 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://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.20"/>
|
|
<meta name="viewport" content="width=device-width, initial-scale=1"/>
|
|
<title>EnTT: Crash Course: poly</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.6.0</span>
|
|
</div>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
<!-- end header part -->
|
|
<!-- Generated by Doxygen 1.8.20 -->
|
|
<script type="text/javascript">
|
|
/* @license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&dn=gpl-2.0.txt GPL-v2 */
|
|
var searchBox = new SearchBox("searchBox", "search",false,'Search');
|
|
/* @license-end */
|
|
</script>
|
|
<script type="text/javascript" src="menudata.js"></script>
|
|
<script type="text/javascript" src="menu.js"></script>
|
|
<script type="text/javascript">
|
|
/* @license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&dn=gpl-2.0.txt GPL-v2 */
|
|
$(function() {
|
|
initMenu('',true,false,'search.php','Search');
|
|
$(document).ready(function() { init_search(); });
|
|
});
|
|
/* @license-end */</script>
|
|
<div id="main-nav"></div>
|
|
<!-- 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><!-- top -->
|
|
<div class="PageDoc"><div class="header">
|
|
<div class="headertitle">
|
|
<div class="title">Crash Course: poly </div> </div>
|
|
</div><!--header-->
|
|
<div class="contents">
|
|
<div class="textblock"><h1><a class="anchor" id="autotoc_md109"></a>
|
|
Introduction</h1>
|
|
<p>Static polymorphism is a very powerful tool in C++, albeit sometimes cumbersome to obtain.<br />
|
|
This module aims to make it simple and easy to use.</p>
|
|
<p>The library allows to define <em>concepts</em> as interfaces to fullfill with concrete classes withouth having to inherit from a common base.<br />
|
|
This is, among others, one of the advantages of static polymorphism in general and of a generic wrapper like that offered by the <code>poly</code> class template in particular.<br />
|
|
What users get is an object that can be passed around as such and not through a reference or a pointer, as happens when it comes to working with dynamic polymorphism.</p>
|
|
<p>Since the <code>poly</code> class template makes use of <code><a class="el" href="classentt_1_1any.html" title="A SBO friendly, type-safe container for single values of any type.">entt::any</a></code> internally, it also supports most of its feature. Among the most important, the possibility to create aliases to existing and thus unmanaged objects. This allows users to exploit the static polymorphism while maintaining ownership of objects.<br />
|
|
Likewise, the <code>poly</code> class template also benefits from the small buffer optimization offered by the <code><a class="el" href="classentt_1_1any.html" title="A SBO friendly, type-safe container for single values of any type.">entt::any</a></code> class and therefore minimizes the number of allocations, avoiding them altogether where possible.</p>
|
|
<h2><a class="anchor" id="autotoc_md110"></a>
|
|
Other libraries</h2>
|
|
<p>There are some very interesting libraries regarding static polymorphism.<br />
|
|
Among all, the two that I prefer are:</p>
|
|
<ul>
|
|
<li><a href="https://github.com/ldionne/dyno"><code>dyno</code></a>: runtime polymorphism done right.</li>
|
|
<li><a href="https://github.com/facebook/folly/blob/master/folly/docs/Poly.md"><code>Poly</code></a>: a class template that makes it easy to define a type-erasing polymorphic object wrapper.</li>
|
|
</ul>
|
|
<p>The former is admittedly an experimental library, with many interesting ideas. I've some doubts about the usefulness of some feature in real world projects, but perhaps my lack of experience comes into play here. In my opinion, its only flaw is the API which I find slightly more cumbersome than other solutions.<br />
|
|
The latter was undoubtedly a source of inspiration for this module, although I opted for different choices in the implementation of both the final API and some feature.</p>
|
|
<p>Either way, the authors are gurus of the C++ community, people I only have to learn from.</p>
|
|
<h1><a class="anchor" id="autotoc_md111"></a>
|
|
Concept and implementation</h1>
|
|
<p>The first thing to do to create a <em>type-erasing polymorphic object wrapper</em> (to use the terminology introduced by Eric Niebler) is to define a <em>concept</em> that types will have to adhere to.<br />
|
|
For this purpose, the library offers a single class that supports both deduced and fully defined interfaces. Although having interfaces deduced automatically is convenient and allows users to write less code in most cases, this has some limitations and it's therefore useful to be able to get around the deduction by providing a custom definition for the static virtual table.</p>
|
|
<p>Once the interface is defined, it will be sufficient to provide a generic implementation to fullfill the concept.<br />
|
|
Also in this case, the library allows customizations based on types or families of types, so as to be able to go beyond the generic case where necessary.</p>
|
|
<h2><a class="anchor" id="autotoc_md112"></a>
|
|
Deduced interface</h2>
|
|
<p>This is how a concept with a deduced interface is introduced:</p>
|
|
<div class="fragment"><div class="line"><span class="keyword">struct </span>Drawable: <a class="code" href="structentt_1_1type__list.html">entt::type_list</a><> {</div>
|
|
<div class="line"> <span class="keyword">template</span><<span class="keyword">typename</span> Base></div>
|
|
<div class="line"> <span class="keyword">struct </span>type: Base {</div>
|
|
<div class="line"> <span class="keywordtype">void</span> draw() { this-><span class="keyword">template</span> invoke<0>(*<span class="keyword">this</span>); }</div>
|
|
<div class="line"> };</div>
|
|
<div class="line"> </div>
|
|
<div class="line"> <span class="comment">// ...</span></div>
|
|
<div class="line">};</div>
|
|
</div><!-- fragment --><p>It's recognizable by the fact that it inherits from an empty type list.<br />
|
|
Functions can also be const, accept any number of paramters and return a type other than <code>void</code>:</p>
|
|
<div class="fragment"><div class="line"><span class="keyword">struct </span>Drawable: <a class="code" href="structentt_1_1type__list.html">entt::type_list</a><> {</div>
|
|
<div class="line"> <span class="keyword">template</span><<span class="keyword">typename</span> Base></div>
|
|
<div class="line"> <span class="keyword">struct </span>type: Base {</div>
|
|
<div class="line"> <span class="keywordtype">bool</span> draw(<span class="keywordtype">int</span> pt)<span class="keyword"> const </span>{ <span class="keywordflow">return</span> this-><span class="keyword">template</span> invoke<0>(*<span class="keyword">this</span>, pt); }</div>
|
|
<div class="line"> };</div>
|
|
<div class="line"> </div>
|
|
<div class="line"> <span class="comment">// ...</span></div>
|
|
<div class="line">};</div>
|
|
</div><!-- fragment --><p>In this case, all parameters must be passed to <code>invoke</code> after the reference to <code>this</code> and the return value is whatever the internal call returns.<br />
|
|
As for <code>invoke</code>, this is a name that is injected into the <em>concept</em> through <code>Base</code>, from which one must necessarily inherit. Since it's also a dependent name, the <code>this-> template</code> form is unfortunately necessary due to the rules of the language. However, there exists also an alternative that goes through an external call:</p>
|
|
<div class="fragment"><div class="line"><span class="keyword">struct </span>Drawable: <a class="code" href="structentt_1_1type__list.html">entt::type_list</a><> {</div>
|
|
<div class="line"> <span class="keyword">template</span><<span class="keyword">typename</span> Base></div>
|
|
<div class="line"> <span class="keyword">struct </span>type: Base {</div>
|
|
<div class="line"> <span class="keywordtype">bool</span> draw()<span class="keyword"> const </span>{ entt::poly_call<0>(*<span class="keyword">this</span>); }</div>
|
|
<div class="line"> };</div>
|
|
<div class="line"> </div>
|
|
<div class="line"> <span class="comment">// ...</span></div>
|
|
<div class="line">};</div>
|
|
</div><!-- fragment --><p>Once the <em>concept</em> is defined, users must provide a generic implementation of it in order to tell the system how any type can satisfy its requirements. This is done via an alias template within the concept itself.<br />
|
|
The index passed as a template parameter to either <code>invoke</code> or <code>poly_call</code> refers to how this alias is defined.</p>
|
|
<h2><a class="anchor" id="autotoc_md113"></a>
|
|
Defined interface</h2>
|
|
<p>A fully defined concept is no different to one for which the interface is deduced, with the only difference that the list of types is not empty this time:</p>
|
|
<div class="fragment"><div class="line"><span class="keyword">struct </span>Drawable: <a class="code" href="structentt_1_1type__list.html">entt::type_list</a><void()> {</div>
|
|
<div class="line"> <span class="keyword">template</span><<span class="keyword">typename</span> Base></div>
|
|
<div class="line"> <span class="keyword">struct </span>type: Base {</div>
|
|
<div class="line"> <span class="keywordtype">void</span> draw() { entt::poly_call<0>(*<span class="keyword">this</span>); }</div>
|
|
<div class="line"> };</div>
|
|
<div class="line"> </div>
|
|
<div class="line"> <span class="comment">// ...</span></div>
|
|
<div class="line">};</div>
|
|
</div><!-- fragment --><p>Again, parameters and return values other than <code>void</code> are allowed. Also, the function type must be const when the method to bind to it is const:</p>
|
|
<div class="fragment"><div class="line"><span class="keyword">struct </span>Drawable: <a class="code" href="structentt_1_1type__list.html">entt::type_list</a><bool(int) const> {</div>
|
|
<div class="line"> <span class="keyword">template</span><<span class="keyword">typename</span> Base></div>
|
|
<div class="line"> <span class="keyword">struct </span>type: Base {</div>
|
|
<div class="line"> <span class="keywordtype">bool</span> draw(<span class="keywordtype">int</span> pt)<span class="keyword"> const </span>{ <span class="keywordflow">return</span> entt::poly_call<0>(*<span class="keyword">this</span>, pt); }</div>
|
|
<div class="line"> };</div>
|
|
<div class="line"> </div>
|
|
<div class="line"> <span class="comment">// ...</span></div>
|
|
<div class="line">};</div>
|
|
</div><!-- fragment --><p>Why should a user fully define a concept if the function types are the same as the deduced ones?<br />
|
|
Because, in fact, this is exactly the limitation that can be worked around by manually defining the static virtual table.</p>
|
|
<p>When things are deduced, there is an implicit constraint.<br />
|
|
If the concept exposes a member function called <code>draw</code> with function type <code>void()</code>, a concept can be satisfied:</p>
|
|
<ul>
|
|
<li>Either by a class that exposes a member function with the same name and the same signature.</li>
|
|
<li>Or through a lambda that makes use of existing member functions from the interface itself.</li>
|
|
</ul>
|
|
<p>In other words, it's not possible to make use of functions not belonging to the interface, even if they are present in the types that fulfill the concept.<br />
|
|
Similarly, it's not possible to deduce a function in the static virtual table with a function type different from that of the associated member function in the interface itself.</p>
|
|
<p>Explicitly defining a static virtual table suppresses the deduction step and allows maximum flexibility when providing the implementation for a concept.</p>
|
|
<h2><a class="anchor" id="autotoc_md114"></a>
|
|
Fullfill a concept</h2>
|
|
<p>The <code>impl</code> alias template of a concept is used to define how it's fulfilled:</p>
|
|
<div class="fragment"><div class="line"><span class="keyword">struct </span>Drawable: <a class="code" href="structentt_1_1type__list.html">entt::type_list</a><> {</div>
|
|
<div class="line"> <span class="comment">// ...</span></div>
|
|
<div class="line"> </div>
|
|
<div class="line"> <span class="keyword">template</span><<span class="keyword">typename</span> Type></div>
|
|
<div class="line"> <span class="keyword">using</span> impl = <a class="code" href="structentt_1_1value__list.html">entt::value_list<&Type::draw></a>;</div>
|
|
<div class="line">};</div>
|
|
</div><!-- fragment --><p>In this case, it's stated that the <code>draw</code> method of a generic type will be enough to satisfy the requirements of the <code>Drawable</code> concept.<br />
|
|
Both member functions and free functions are supported to fullfill concepts:</p>
|
|
<div class="fragment"><div class="line"><span class="keyword">template</span><<span class="keyword">typename</span> Type></div>
|
|
<div class="line"><span class="keywordtype">void</span> print(Type &<span class="keyword">self</span>) { <span class="keyword">self</span>.print(); }</div>
|
|
<div class="line"> </div>
|
|
<div class="line"><span class="keyword">struct </span>Drawable: <a class="code" href="structentt_1_1type__list.html">entt::type_list</a><void()> {</div>
|
|
<div class="line"> <span class="comment">// ...</span></div>
|
|
<div class="line"> </div>
|
|
<div class="line"> <span class="keyword">template</span><<span class="keyword">typename</span> Type></div>
|
|
<div class="line"> <span class="keyword">using</span> impl = <a class="code" href="structentt_1_1value__list.html">entt::value_list<&print<Type></a>>;</div>
|
|
<div class="line">};</div>
|
|
</div><!-- fragment --><p>Likewise, as long as the parameter types and return type support conversions to and from those of the function type referenced in the static virtual table, the actual implementation may differ in its function type since it's erased internally.<br />
|
|
Moreover, the <code>self</code> parameter isn't strictly required by the system and can be left out for free functions if not required.</p>
|
|
<p>Refer to the inline documentation for more details.</p>
|
|
<h1><a class="anchor" id="autotoc_md115"></a>
|
|
Inheritance</h1>
|
|
<p><em>Concept inheritance</em> is straightforward due to how poly looks like in <code>EnTT</code>. Therefore, it's quite easy to build hierarchies of concepts if necessary.<br />
|
|
The only constraint is that all concepts in a hierarchy must belong to the same <em>family</em>, that is, they must be either all deduced or all defined.</p>
|
|
<p>For a deduced concept, inheritance is achieved in a few steps:</p>
|
|
<div class="fragment"><div class="line"><span class="keyword">struct </span>DrawableAndErasable: <a class="code" href="structentt_1_1type__list.html">entt::type_list</a><> {</div>
|
|
<div class="line"> <span class="keyword">template</span><<span class="keyword">typename</span> Base></div>
|
|
<div class="line"> <span class="keyword">struct </span>type: typename Drawable::type<Base> {</div>
|
|
<div class="line"> <span class="keyword">static</span> constexpr <span class="keyword">auto</span> base = std::tuple_size_v<typename entt::poly_vtable<Drawable>::type>;</div>
|
|
<div class="line"> <span class="keywordtype">void</span> erase() { entt::poly_call<base + 0>(*<span class="keyword">this</span>); }</div>
|
|
<div class="line"> };</div>
|
|
<div class="line"> </div>
|
|
<div class="line"> <span class="keyword">template</span><<span class="keyword">typename</span> Type></div>
|
|
<div class="line"> <span class="keyword">using</span> impl = <a class="code" href="namespaceentt.html#a1344cc62598091397018354e6905e431">entt::value_list_cat_t</a><</div>
|
|
<div class="line"> <span class="keyword">typename</span> Drawable::impl<Type>,</div>
|
|
<div class="line"> <a class="code" href="structentt_1_1value__list.html">entt::value_list<&Type::erase></a></div>
|
|
<div class="line"> >;</div>
|
|
<div class="line">};</div>
|
|
</div><!-- fragment --><p>The static virtual table is empty and must remain so.<br />
|
|
On the other hand, <code>type</code> no longer inherits from <code>Base</code> and instead forwards its template parameter to the type exposed by the <em>base class</em>. Internally, the size of the static virtual table of the base class is used as an offset for the local indexes.<br />
|
|
Finally, by means of the <code>value_list_cat_t</code> utility, the implementation consists in appending the new functions to the previous list.</p>
|
|
<p>As for a defined concept instead, also the list of types must be extended, in a similar way to what is shown for the implementation of the above concept.<br />
|
|
To do this, it's useful to declare a function that allows to convert a <em>concept</em> into its underlying <code>type_list</code> object:</p>
|
|
<div class="fragment"><div class="line"><span class="keyword">template</span><<span class="keyword">typename</span>... Type></div>
|
|
<div class="line"><a class="code" href="structentt_1_1type__list.html">entt::type_list</a><Type...> as_type_list(<span class="keyword">const</span> <a class="code" href="structentt_1_1type__list.html">entt::type_list<Type...></a> &);</div>
|
|
</div><!-- fragment --><p>The definition isn't strictly required, since the function will only be used through a <code>decltype</code> as it follows:</p>
|
|
<div class="fragment"><div class="line"><span class="keyword">struct </span>DrawableAndErasable: <a class="code" href="namespaceentt.html#a546467a3662e9a915d5d519ad565e801">entt::type_list_cat_t</a><</div>
|
|
<div class="line"> decltype(as_type_list(std::declval<Drawable>())),</div>
|
|
<div class="line"> entt::type_list<void()></div>
|
|
<div class="line">> {</div>
|
|
<div class="line"> <span class="comment">// ...</span></div>
|
|
<div class="line">};</div>
|
|
</div><!-- fragment --><p>Similar to above, <code>type_list_cat_t</code> is used to concatenate the underlying static virtual table with the new function types.<br />
|
|
Everything else is the same as already shown instead.</p>
|
|
<h1><a class="anchor" id="autotoc_md116"></a>
|
|
Static polymorphism in the wild</h1>
|
|
<p>Once the <em>concept</em> and implementation have been introduced, it will be possible to use the <code>poly</code> class template to contain instances that meet the requirements:</p>
|
|
<div class="fragment"><div class="line"><span class="keyword">using</span> drawable = <a class="code" href="classentt_1_1poly.html">entt::poly<Drawable></a>;</div>
|
|
<div class="line"> </div>
|
|
<div class="line"><span class="keyword">struct </span>circle {</div>
|
|
<div class="line"> <span class="keywordtype">void</span> draw() { <span class="comment">/* ... */</span> }</div>
|
|
<div class="line">};</div>
|
|
<div class="line"> </div>
|
|
<div class="line"><span class="keyword">struct </span>square {</div>
|
|
<div class="line"> <span class="keywordtype">void</span> draw() { <span class="comment">/* ... */</span> }</div>
|
|
<div class="line">};</div>
|
|
<div class="line"> </div>
|
|
<div class="line"><span class="comment">// ...</span></div>
|
|
<div class="line"> </div>
|
|
<div class="line">drawable d{circle{}};</div>
|
|
<div class="line">d->draw();</div>
|
|
<div class="line"> </div>
|
|
<div class="line">d = square{};</div>
|
|
<div class="line">d->draw();</div>
|
|
</div><!-- fragment --><p>The <code>poly</code> class template offers a wide range of constructors, from the default one (which will return an uninitialized <code>poly</code> object) to the copy and move constructor, as well as the ability to create objects in-place.<br />
|
|
Among others, there is a constructor that allows users to wrap unmanaged objects in a <code>poly</code> instance (either const or non-const ones):</p>
|
|
<div class="fragment"><div class="line">circle c;</div>
|
|
<div class="line">drawable d{std::ref(c)};</div>
|
|
</div><!-- fragment --><p>Similarly, it's possible to create non-owning copies of <code>poly</code> from an existing object:</p>
|
|
<div class="fragment"><div class="line">drawable other = as_ref(d);</div>
|
|
</div><!-- fragment --><p>In both cases, although the interface of the <code>poly</code> object doesn't change, it won't construct any element or take care of destroying the referenced objects.</p>
|
|
<p>Note also how the underlying concept is accessed via a call to <code>operator-></code> and not directly as <code>d.draw()</code>.<br />
|
|
This allows users to decouple the API of the wrapper from that of the concept. Therefore, where <code>d.data()</code> will invoke the <code>data</code> member function of the poly object, <code>d->data()</code> will map directly to the functionality exposed by the underlying concept. </p>
|
|
</div></div><!-- contents -->
|
|
</div><!-- PageDoc -->
|
|
<div class="ttc" id="astructentt_1_1type__list_html"><div class="ttname"><a href="structentt_1_1type__list.html">entt::type_list</a></div><div class="ttdoc">A class to use to push around lists of types, nothing more.</div><div class="ttdef"><b>Definition:</b> <a href="core_2type__traits_8hpp_source.html#l00127">type_traits.hpp:127</a></div></div>
|
|
<div class="ttc" id="astructentt_1_1value__list_html"><div class="ttname"><a href="structentt_1_1value__list.html">entt::value_list</a></div><div class="ttdoc">A class to use to push around lists of constant values, nothing more.</div><div class="ttdef"><b>Definition:</b> <a href="core_2type__traits_8hpp_source.html#l00298">type_traits.hpp:298</a></div></div>
|
|
<div class="ttc" id="anamespaceentt_html_a546467a3662e9a915d5d519ad565e801"><div class="ttname"><a href="namespaceentt.html#a546467a3662e9a915d5d519ad565e801">entt::type_list_cat_t</a></div><div class="ttdeci">typename type_list_cat< List... >::type type_list_cat_t</div><div class="ttdoc">Helper type.</div><div class="ttdef"><b>Definition:</b> <a href="core_2type__traits_8hpp_source.html#l00225">type_traits.hpp:225</a></div></div>
|
|
<div class="ttc" id="aclassentt_1_1poly_html"><div class="ttname"><a href="classentt_1_1poly.html">entt::poly</a></div><div class="ttdoc">Static polymorphism made simple and within everyone's reach.</div><div class="ttdef"><b>Definition:</b> <a href="poly_8hpp_source.html#l00176">poly.hpp:176</a></div></div>
|
|
<div class="ttc" id="anamespaceentt_html_a1344cc62598091397018354e6905e431"><div class="ttname"><a href="namespaceentt.html#a1344cc62598091397018354e6905e431">entt::value_list_cat_t</a></div><div class="ttdeci">typename value_list_cat< List... >::type value_list_cat_t</div><div class="ttdoc">Helper type.</div><div class="ttdef"><b>Definition:</b> <a href="core_2type__traits_8hpp_source.html#l00396">type_traits.hpp:396</a></div></div>
|
|
<!-- 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.svg" width="104" height="31" alt="doxygen"/></a> 1.8.20
|
|
</small></address>
|
|
</body>
|
|
</html>
|