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>Frequently Asked Questions</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="../function.html" title="Chapter 16. Boost.Function"> 10<link rel="prev" href="../boost/function_equal.html" title="Function template function_equal"> 11<link rel="next" href="misc.html" title="Miscellaneous Notes"> 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="../boost/function_equal.html"><img src="../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../function.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="misc.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="function.faq"></a>Frequently Asked Questions</h2></div></div></div> 29<div class="qandaset"> 30<a name="id-1.3.17.7.2"></a><dl> 31<dt>1. <a href="faq.html#id-1.3.17.7.2.1">Why can't I compare 32 boost::function objects with 33 operator== or 34 operator!=?</a> 35</dt> 36<dt>2. <a href="faq.html#id-1.3.17.7.2.2">I see void pointers; is this [mess] type safe?</a> 37</dt> 38<dt>3. <a href="faq.html#id-1.3.17.7.2.3">Why are there workarounds for void returns? C++ allows them!</a> 39</dt> 40<dt>4. <a href="faq.html#id-1.3.17.7.2.4">Why (function) cloning?</a> 41</dt> 42<dt>5. <a href="faq.html#id-1.3.17.7.2.5">How much overhead does a call through boost::function incur?</a> 43</dt> 44</dl> 45<table border="0" style="width: 100%;"> 46<colgroup> 47<col align="left" width="1%"> 48<col> 49</colgroup> 50<tbody> 51<tr class="question"> 52<td align="left" valign="top"> 53<a name="id-1.3.17.7.2.1"></a><a name="id-1.3.17.7.2.1.1"></a><p><b>1.</b></p> 54</td> 55<td align="left" valign="top"><p>Why can't I compare 56 <code class="computeroutput"><a class="link" href="../boost/function.html" title="Class template function">boost::function</a></code> objects with 57 <code class="computeroutput">operator==</code> or 58 <code class="computeroutput">operator!=</code>?</p></td> 59</tr> 60<tr class="answer"> 61<td align="left" valign="top"></td> 62<td align="left" valign="top"> 63<p>Comparison between <code class="computeroutput"><a class="link" href="../boost/function.html" title="Class template function">boost::function</a></code> 64 objects cannot be implemented "well", and therefore will not be 65 implemented. The typical semantics requested for <code class="computeroutput">f == 66 g</code> given <code class="computeroutput"><a class="link" href="../boost/function.html" title="Class template function">boost::function</a></code> objects 67 <code class="computeroutput">f</code> and <code class="computeroutput">g</code> are:</p> 68<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "> 69<li class="listitem">If <code class="computeroutput">f</code> and <code class="computeroutput">g</code> 70 store function objects of the same type, use that type's 71 <code class="computeroutput">operator==</code> to compare 72 them.</li> 73<li class="listitem">If <code class="computeroutput">f</code> and <code class="computeroutput">g</code> 74 store function objects of different types, return 75 <code class="computeroutput">false</code>.</li> 76</ul></div> 77<p>The problem occurs when the type of the function objects 78 stored by both <code class="computeroutput">f</code> and <code class="computeroutput">g</code> doesn't have an 79 <code class="computeroutput">operator==</code>: we would like the expression <code class="computeroutput">f == 80 g</code> to fail to compile, as occurs with, e.g., the standard 81 containers. However, this is not implementable for 82 <code class="computeroutput"><a class="link" href="../boost/function.html" title="Class template function">boost::function</a></code> because it necessarily 83 "erases" some type information after it has been assigned a 84 function object, so it cannot try to call 85 <code class="computeroutput">operator==</code> later: it must either find a way to call 86 <code class="computeroutput">operator==</code> now, or it will never be able to call it 87 later. Note, for instance, what happens if you try to put a 88 <code class="computeroutput">float</code> value into a 89 <code class="computeroutput"><a class="link" href="../boost/function.html" title="Class template function">boost::function</a></code> object: you will get an 90 error at the assignment operator or constructor, not in 91 <code class="computeroutput">operator()</code>, because the function-call expression 92 must be bound in the constructor or assignment operator.</p> 93<p>The most promising approach is to find a method of 94 determining if <code class="computeroutput">operator==</code> can be called for a 95 particular type, and then supporting it only when it is 96 available; in other situations, an exception would be 97 thrown. However, to date there is no known way to detect if an 98 arbitrary operator expression <code class="computeroutput">f == g</code> is suitably 99 defined. The best solution known has the following undesirable 100 qualities:</p> 101<div class="orderedlist"><ol class="orderedlist" type="1"> 102<li class="listitem">Fails at compile-time for objects where 103 <code class="computeroutput">operator==</code> is not accessible (e.g., because it is 104 <code class="computeroutput">private</code>).</li> 105<li class="listitem">Fails at compile-time if calling 106 <code class="computeroutput">operator==</code> is ambiguous.</li> 107<li class="listitem">Appears to be correct if the 108 <code class="computeroutput">operator==</code> declaration is correct, even though 109 <code class="computeroutput">operator==</code> may not compile.</li> 110</ol></div> 111<p>All of these problems translate into failures in the 112 <code class="computeroutput"><a class="link" href="../boost/function.html" title="Class template function">boost::function</a></code> constructors or 113 assignment operator, <span class="emphasis"><em>even if the user never invokes 114 operator==</em></span>. We can't do that to users.</p> 115<p>The other option is to place the burden on users that want 116 to use <code class="computeroutput">operator==</code>, e.g., by providing an 117 <code class="computeroutput">is_equality_comparable</code> trait they may 118 specialize. This is a workable solution, but is dangerous in 119 practice, because forgetting to specialize the trait will result 120 in unexpected exceptions being thrown from 121 <code class="computeroutput"><a class="link" href="../boost/function.html" title="Class template function">boost::function</a></code>'s 122 <code class="computeroutput">operator==</code>. This essentially negates the usefulness 123 of <code class="computeroutput">operator==</code> in the context in which it is most 124 desired: multitarget callbacks. The 125 Signals library has a way around 126 this.</p> 127</td> 128</tr> 129<tr class="question"> 130<td align="left" valign="top"> 131<a name="id-1.3.17.7.2.2"></a><a name="id-1.3.17.7.2.2.1"></a><p><b>2.</b></p> 132</td> 133<td align="left" valign="top"><p>I see void pointers; is this [mess] type safe?</p></td> 134</tr> 135<tr class="answer"> 136<td align="left" valign="top"></td> 137<td align="left" valign="top"><p>Yes, <code class="computeroutput">boost::function</code> is type 138safe even though it uses void pointers and pointers to functions 139returning void and taking no arguments. Essentially, all type 140information is encoded in the functions that manage and invoke 141function pointers and function objects. Only these functions are 142instantiated with the exact type that is pointed to by the void 143pointer or pointer to void function. The reason that both are required 144is that one may cast between void pointers and object pointers safely 145or between different types of function pointers (provided you don't 146invoke a function pointer with the wrong type). </p></td> 147</tr> 148<tr class="question"> 149<td align="left" valign="top"> 150<a name="id-1.3.17.7.2.3"></a><a name="id-1.3.17.7.2.3.1"></a><p><b>3.</b></p> 151</td> 152<td align="left" valign="top"><p>Why are there workarounds for void returns? C++ allows them!</p></td> 153</tr> 154<tr class="answer"> 155<td align="left" valign="top"></td> 156<td align="left" valign="top"> 157<p>Void returns are permitted by the C++ standard, as in this code snippet: 158</p> 159<pre class="programlisting">void f(); 160void g() { return f(); }</pre> 161<p> 162 </p> 163<p> This is a valid usage of <code class="computeroutput">boost::function</code> because void returns are not used. With void returns, we would attempting to compile ill-formed code similar to: 164</p> 165<pre class="programlisting">int f(); 166void g() { return f(); }</pre> 167<p> 168</p> 169<p> In essence, not using void returns allows 170<code class="computeroutput">boost::function</code> to swallow a return value. This is 171consistent with allowing the user to assign and invoke functions and 172function objects with parameters that don't exactly match.</p> 173</td> 174</tr> 175<tr class="question"> 176<td align="left" valign="top"> 177<a name="id-1.3.17.7.2.4"></a><a name="id-1.3.17.7.2.4.1"></a><p><b>4.</b></p> 178</td> 179<td align="left" valign="top"><p>Why (function) cloning?</p></td> 180</tr> 181<tr class="answer"> 182<td align="left" valign="top"></td> 183<td align="left" valign="top"><p>In November and December of 2000, the issue of cloning 184 vs. reference counting was debated at length and it was decided 185 that cloning gave more predictable semantics. I won't rehash the 186 discussion here, but if it cloning is incorrect for a particular 187 application a reference-counting allocator could be used.</p></td> 188</tr> 189<tr class="question"> 190<td align="left" valign="top"> 191<a name="id-1.3.17.7.2.5"></a><a name="id-1.3.17.7.2.5.1"></a><p><b>5.</b></p> 192</td> 193<td align="left" valign="top"><p>How much overhead does a call through <code class="computeroutput"><a class="link" href="../boost/function.html" title="Class template function">boost::function</a></code> incur?</p></td> 194</tr> 195<tr class="answer"> 196<td align="left" valign="top"></td> 197<td align="left" valign="top"> 198<p>The cost of <code class="computeroutput">boost::function</code> can be reasonably 199 consistently measured at around 20ns +/- 10 ns on a modern >2GHz 200 platform versus directly inlining the code.</p> 201<p>However, the performance of your application may benefit 202 from or be disadvantaged by <code class="computeroutput">boost::function</code> 203 depending on how your C++ optimiser optimises. Similar to a 204 standard function pointer, differences of order of 10% have been 205 noted to the benefit or disadvantage of using 206 <code class="computeroutput">boost::function</code> to call a function that contains a 207 tight loop depending on your compilation circumstances.</p> 208<p>[Answer provided by Matt Hurd. See <a href="http://article.gmane.org/gmane.comp.lib.boost.devel/33278" target="_top">http://article.gmane.org/gmane.comp.lib.boost.devel/33278</a>]</p> 209</td> 210</tr> 211</tbody> 212</table> 213</div> 214</div> 215<table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr> 216<td align="left"></td> 217<td align="right"><div class="copyright-footer">Copyright © 2001-2004 Douglas Gregor<p>Use, modification and distribution is subject to the Boost 218 Software License, Version 1.0. (See accompanying file 219 <code class="filename">LICENSE_1_0.txt</code> or copy at <a href="http://www.boost.org/LICENSE_1_0.txt" target="_top">http://www.boost.org/LICENSE_1_0.txt</a>)</p> 220</div></td> 221</tr></table> 222<hr> 223<div class="spirit-nav"> 224<a accesskey="p" href="../boost/function_equal.html"><img src="../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../function.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="misc.html"><img src="../../../doc/src/images/next.png" alt="Next"></a> 225</div> 226</body> 227</html> 228
