1<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> 2<html> 3<head> 4<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 5<title>Design Rationale</title> 6<link rel="stylesheet" href="../../../doc/src/boostbook.css" type="text/css"> 7<meta name="generator" content="DocBook XSL Stylesheets V1.79.1"> 8<link rel="home" href="../index.html" title="The Boost C++ Libraries BoostBook Documentation Subset"> 9<link rel="up" href="../boost_dll.html" title="Chapter 14. Boost.DLL"> 10<link rel="prev" href="f_a_q_.html" title="F.A.Q."> 11<link rel="next" href="dependencies.html" title="Dependencies"> 12</head> 13<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> 14<table cellpadding="2" width="100%"><tr> 15<td valign="top"><img alt="Boost C++ Libraries" width="277" height="86" src="../../../boost.png"></td> 16<td align="center"><a href="../../../index.html">Home</a></td> 17<td align="center"><a href="../../../libs/libraries.htm">Libraries</a></td> 18<td align="center"><a href="http://www.boost.org/users/people.html">People</a></td> 19<td align="center"><a href="http://www.boost.org/users/faq.html">FAQ</a></td> 20<td align="center"><a href="../../../more/index.htm">More</a></td> 21</tr></table> 22<hr> 23<div class="spirit-nav"> 24<a accesskey="p" href="f_a_q_.html"><img src="../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../boost_dll.html"><img src="../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="dependencies.html"><img src="../../../doc/src/images/next.png" alt="Next"></a> 25</div> 26<div class="section"> 27<div class="titlepage"><div><div><h2 class="title" style="clear: both"> 28<a name="boost_dll.design_rationale"></a><a class="link" href="design_rationale.html" title="Design Rationale">Design Rationale</a> 29</h2></div></div></div> 30<div class="toc"><dl class="toc"> 31<dt><span class="section"><a href="design_rationale.html#boost_dll.design_rationale.abi_portability_across_compilers">ABI 32 portability across compilers</a></span></dt> 33<dt><span class="section"><a href="design_rationale.html#boost_dll.design_rationale.user_s_plugin_api">User's 34 plugin API</a></span></dt> 35<dt><span class="section"><a href="design_rationale.html#boost_dll.design_rationale.performance_and_memory_allocations">Performance 36 and memory allocations</a></span></dt> 37<dt><span class="section"><a href="design_rationale.html#boost_dll.design_rationale.self_loading">Self loading</a></span></dt> 38<dt><span class="section"><a href="design_rationale.html#boost_dll.design_rationale.aliases_vs_mangling">Aliases 39 vs Mangling</a></span></dt> 40</dl></div> 41<div class="section"> 42<div class="titlepage"><div><div><h3 class="title"> 43<a name="boost_dll.design_rationale.abi_portability_across_compilers"></a><a class="link" href="design_rationale.html#boost_dll.design_rationale.abi_portability_across_compilers" title="ABI portability across compilers">ABI 44 portability across compilers</a> 45</h3></div></div></div> 46<p> 47 During discussion of the library a lot of questions were about ABI stability 48 and should the library take care about it. It was decided that making ABI 49 stable could be a useful feature, but it will add a lot of overhead and make 50 the library usage less simple. For those who do not require ABI stability 51 across compilers such feature will be an overkill. 52 </p> 53<p> 54 It was decided to make this library more simple and low level, so that it 55 could be used to make ABI stable plugins system for users that require it 56 still not adding overhead for other users. 57 </p> 58</div> 59<div class="section"> 60<div class="titlepage"><div><div><h3 class="title"> 61<a name="boost_dll.design_rationale.user_s_plugin_api"></a><a class="link" href="design_rationale.html#boost_dll.design_rationale.user_s_plugin_api" title="User's plugin API">User's 62 plugin API</a> 63</h3></div></div></div> 64<p> 65 There are some open C++ plugin systems. Most of them force user to have some 66 predefined API. The problem is that all of those API differ. 67 </p> 68<p> 69 To be more usable Boost.DLL does not force API. It's up to user to design 70 suitable API. 71 </p> 72</div> 73<div class="section"> 74<div class="titlepage"><div><div><h3 class="title"> 75<a name="boost_dll.design_rationale.performance_and_memory_allocations"></a><a class="link" href="design_rationale.html#boost_dll.design_rationale.performance_and_memory_allocations" title="Performance and memory allocations">Performance 76 and memory allocations</a> 77</h3></div></div></div> 78<p> 79 Some methods of the library use <code class="computeroutput"><span class="identifier">boost</span><span class="special">::</span><span class="identifier">filesystem</span><span class="special">::</span><span class="identifier">path</span></code> 80 or return <code class="computeroutput"><span class="identifier">std</span><span class="special">::</span><span class="identifier">vector</span><span class="special"><</span><span class="identifier">std</span><span class="special">::</span><span class="identifier">string</span><span class="special">></span></code>. This may look non optimal at first, 81 but there is a reason to do so. 82 </p> 83<p> 84 <code class="computeroutput"><span class="identifier">boost</span><span class="special">::</span><span class="identifier">filesystem</span><span class="special">::</span><span class="identifier">path</span></code> allows to transparently use Unicode 85 strings with non-Unicode ones. Using it provides a more user-friendly interface 86 for the library while the performance overhead is not noticeable because 87 of a slow file system operations that occur in <code class="computeroutput"><span class="identifier">boost</span><span class="special">::</span><span class="identifier">filesystem</span><span class="special">::</span><span class="identifier">path</span></code> 88 accepting methods. 89 </p> 90<p> 91 <code class="computeroutput"><span class="identifier">std</span><span class="special">::</span><span class="identifier">vector</span><span class="special"><</span><span class="identifier">std</span><span class="special">::</span><span class="identifier">string</span><span class="special">></span></code> variables are returned by the <code class="computeroutput"><span class="identifier">library_info</span></code> methods. Querying a library 92 is a slow procedure anyway: it randomly reads parts of file from disc and 93 executes algorithms that sometimes have linear complexity from sections or 94 exported symbols count. Returning <code class="computeroutput"><span class="identifier">std</span><span class="special">::</span><span class="identifier">vector</span><span class="special"><</span><span class="identifier">std</span><span class="special">::</span><span class="identifier">string</span><span class="special">></span></code> simplifies implementation and does not 95 require from user to keep an instance of <code class="computeroutput"><span class="identifier">library_info</span></code> 96 after query. Having not a very noticeable performance overhead in rarely 97 called methods seems reasonable. 98 </p> 99<p> 100 Other methods are assumed to be hot paths and optimized as much as possible. 101 </p> 102</div> 103<div class="section"> 104<div class="titlepage"><div><div><h3 class="title"> 105<a name="boost_dll.design_rationale.self_loading"></a><a class="link" href="design_rationale.html#boost_dll.design_rationale.self_loading" title="Self loading">Self loading</a> 106</h3></div></div></div> 107<p> 108 There is a good big reason to make self loading via <code class="computeroutput"><span class="identifier">shared_library</span><span class="special">(</span><span class="identifier">program_location</span><span class="special">())</span></code> instead of having some <code class="computeroutput"><span class="identifier">shared_library</span><span class="special">::</span><span class="identifier">load_self</span><span class="special">()</span></code> member method. That reason is the requirement 109 to have an ability to call <code class="computeroutput"><span class="identifier">shared_library</span><span class="special">(</span><span class="identifier">this_line_location</span><span class="special">())</span></code> from any place, even from the main binary. 110 We need that to link plugins into the binary and to create a transparent 111 reference counting mechanism. 112 </p> 113<p> 114 Making multiple interfaces that do exactly the same things looks unreasonable 115 to me, that's why <code class="computeroutput"><span class="identifier">shared_library</span><span class="special">(</span><span class="identifier">program_location</span><span class="special">())</span></code> and <code class="computeroutput"><span class="identifier">shared_library</span><span class="special">(</span><span class="identifier">this_line_location</span><span class="special">())</span></code> are used without <code class="computeroutput"><span class="identifier">shared_library</span><span class="special">::</span><span class="identifier">load_self</span><span class="special">()</span></code>. 116 </p> 117</div> 118<div class="section"> 119<div class="titlepage"><div><div><h3 class="title"> 120<a name="boost_dll.design_rationale.aliases_vs_mangling"></a><a class="link" href="design_rationale.html#boost_dll.design_rationale.aliases_vs_mangling" title="Aliases vs Mangling">Aliases 121 vs Mangling</a> 122</h3></div></div></div> 123<p> 124 Mangling depends on source code, for example <code class="computeroutput"><span class="string">"boost::foo"</span></code> 125 could be <code class="computeroutput"><span class="identifier">foo</span></code> function or 126 <code class="computeroutput"><span class="identifier">foo</span></code> variable. Depending on 127 that knowledge it must be mangled in different ways. More problems arise 128 if <code class="computeroutput"><span class="identifier">foo</span></code> is an overloaded function 129 that accepts parameters: <code class="computeroutput"><span class="string">"boost::foo(variant<int, 130 short>)"</span></code>. In that case full name of parameter must 131 be specified, which could be <code class="computeroutput"><span class="identifier">boost</span><span class="special">::</span><span class="identifier">variant</span><span class="special"><</span><span class="keyword">int</span><span class="special">,</span> 132 <span class="keyword">short</span><span class="special">></span></code> 133 or <code class="computeroutput"><span class="identifier">variant</span><span class="special"><</span><span class="keyword">int</span><span class="special">,</span> <span class="keyword">short</span><span class="special">,</span> <span class="identifier">void_</span><span class="special">,</span> <span class="identifier">void_</span><span class="special">></span></code> ... 134 </p> 135<p> 136 There was an idea to allow user to forward declare function and generate 137 mangled name from it: 138 </p> 139<p> 140</p> 141<pre class="programlisting"><span class="keyword">namespace</span> <span class="identifier">boost</span> <span class="special">{</span> <span class="keyword">void</span> <span class="identifier">foo</span><span class="special">(</span><span class="identifier">variant</span><span class="special"><</span><span class="keyword">int</span><span class="special">,</span> <span class="keyword">short</span><span class="special">>);</span> <span class="special">}</span> 142 143<span class="identifier">std</span><span class="special">::</span><span class="identifier">string</span> <span class="identifier">mangled_name</span> <span class="special">=</span> <span class="identifier">boost</span><span class="special">::</span><span class="identifier">dll</span><span class="special">::</span><span class="identifier">magic_mangle</span><span class="special">(</span><span class="identifier">boost</span><span class="special">::</span><span class="identifier">foo</span><span class="special">);</span> 144</pre> 145<p> 146 </p> 147<p> 148 But that idea has epic failed because of linker problems and no reliable 149 way to get mangled symbol name from compiler internals at compile time. 150 </p> 151<p> 152 That's why aliases were considered a lesser evil: 153 </p> 154<p> 155</p> 156<pre class="programlisting"><span class="identifier">BOOST_DLL_ALIAS</span><span class="special">(</span><span class="identifier">boost</span><span class="special">::</span><span class="identifier">foo</span><span class="special">,</span> <span class="identifier">foo_variant</span><span class="special">)</span> <span class="comment">// in plugin</span> 157<span class="string">"foo_variant"</span> <span class="comment">// in plugin importer</span> 158</pre> 159<p> 160 </p> 161</div> 162</div> 163<table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr> 164<td align="left"></td> 165<td align="right"><div class="copyright-footer">Copyright © 2014 Renato Tegon Forti, Antony Polukhin<br>Copyright © 2015 Antony Polukhin<br>Copyright © 2016 Antony Polukhin, Klemens Morgenstern<br>Copyright © 2017-2019 Antony Polukhin<p> 166 Distributed under the Boost Software License, Version 1.0. (See accompanying 167 file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) 168 </p> 169</div></td> 170</tr></table> 171<hr> 172<div class="spirit-nav"> 173<a accesskey="p" href="f_a_q_.html"><img src="../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../boost_dll.html"><img src="../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="dependencies.html"><img src="../../../doc/src/images/next.png" alt="Next"></a> 174</div> 175</body> 176</html> 177
