Planet
navi homePPSaboutscreenshotsdownloaddevelopmentforum

source: downloads/boost_1_33_1/doc/html/function/faq.html @ 25

Last change on this file since 25 was 12, checked in by landauf, 17 years ago

added boost
File size: 11.8 KB
Line 
1<html>
2<head>
3<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
4<title>Frequently Asked Questions</title>
5<link rel="stylesheet" href="../boostbook.css" type="text/css">
6<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
7<link rel="start" href="../index.html" title="The Boost C++ Libraries">
8<link rel="up" href="../function.html" title="Chapter 4. Boost.Function">
9<link rel="prev" href="../function_equal.html" title="Function template function_equal">
10<link rel="next" href="misc.html" title="Miscellaneous Notes">
11</head>
12<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
13<table cellpadding="2" width="100%">
14<td valign="top"><img alt="boost.png (6897 bytes)" width="277" height="86" src="../../../boost.png"></td>
15<td align="center"><a href="../../../index.htm">Home</a></td>
16<td align="center"><a href="../../../libs/libraries.htm">Libraries</a></td>
17<td align="center"><a href="../../../people/people.htm">People</a></td>
18<td align="center"><a href="../../../more/faq.htm">FAQ</a></td>
19<td align="center"><a href="../../../more/index.htm">More</a></td>
20</table>
21<hr>
22<div class="spirit-nav">
23<a accesskey="p" href="../function_equal.html"><img src="../images/prev.png" alt="Prev"></a><a accesskey="u" href="../function.html"><img src="../images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../images/home.png" alt="Home"></a><a accesskey="n" href="misc.html"><img src="../images/next.png" alt="Next"></a>
24</div>
25<div class="section" lang="en">
26<div class="titlepage"><div><div><h3 class="title">
27<a name="function.faq"></a>Frequently Asked Questions</h3></div></div></div>
28<div class="qandaset">
29<dl>
30<dt>1. <a href="faq.html#id2699084">Why can't I compare
31    boost::function objects with
32    operator== or
33    operator!=?</a>
34</dt>
35<dt>2. <a href="faq.html#id2699424">I see void pointers; is this [mess] type safe?</a>
36</dt>
37<dt>3. <a href="faq.html#id2699448">Why are there workarounds for void returns? C++ allows them!</a>
38</dt>
39<dt>4. <a href="faq.html#id2699490">Why (function) cloning?</a>
40</dt>
41<dt>5. <a href="faq.html#id2699504">How much overhead does a call through boost::function incur?</a>
42</dt>
43</dl>
44<table border="0" summary="Q and A Set">
45<col align="left" width="1%">
46<tbody>
47<tr class="question">
48<td align="left" valign="top">
49<a name="id2699084"></a><a name="id2699085"></a><b>1.</b>
50</td>
51<td align="left" valign="top"><p>Why can't I compare
52    <code class="computeroutput"><a href="../boost/function.html" title="Class template function">boost::function</a></code> objects with
53    <code class="computeroutput">operator==</code> or
54    <code class="computeroutput">operator!=</code>?</p></td>
55</tr>
56<tr class="answer">
57<td align="left" valign="top"><b></b></td>
58<td align="left" valign="top">
59<p>Comparison between <code class="computeroutput"><a href="../boost/function.html" title="Class template function">boost::function</a></code>
60      objects cannot be implemented "well", and therefore will not be
61      implemented. The typical semantics requested for <code class="computeroutput">f ==
62      g</code> given <code class="computeroutput"><a href="../boost/function.html" title="Class template function">boost::function</a></code> objects
63      <code class="computeroutput">f</code> and <code class="computeroutput">g</code> are:</p>
64<div class="itemizedlist"><ul type="disc">
65<li>If <code class="computeroutput">f</code> and <code class="computeroutput">g</code>
66          store function objects of the same type, use that type's
67          <code class="computeroutput">operator==</code> to compare
68          them.</li>
69<li>If <code class="computeroutput">f</code> and <code class="computeroutput">g</code>
70          store function objects of different types, return
71          <code class="computeroutput">false</code>.</li>
72</ul></div>
73<p>The problem occurs when the type of the function objects
74      stored by both <code class="computeroutput">f</code> and <code class="computeroutput">g</code> doesn't have an
75      <code class="computeroutput">operator==</code>: we would like the expression <code class="computeroutput">f ==
76      g</code> to fail to compile, as occurs with, e.g., the standard
77      containers. However, this is not implementable for
78      <code class="computeroutput"><a href="../boost/function.html" title="Class template function">boost::function</a></code> because it necessarily
79      "erases" some type information after it has been assigned a
80      function object, so it cannot try to call
81      <code class="computeroutput">operator==</code> later: it must either find a way to call
82      <code class="computeroutput">operator==</code> now, or it will never be able to call it
83      later. Note, for instance, what happens if you try to put a
84      <code class="computeroutput">float</code> value into a
85      <code class="computeroutput"><a href="../boost/function.html" title="Class template function">boost::function</a></code> object: you will get an
86      error at the assignment operator or constructor, not in
87      <code class="computeroutput">operator()</code>, because the function-call expression
88      must be bound in the constructor or assignment operator.</p>
89<p>The most promising approach is to find a method of
90      determining if <code class="computeroutput">operator==</code> can be called for a
91      particular type, and then supporting it only when it is
92      available; in other situations, an exception would be
93      thrown. However, to date there is no known way to detect if an
94      arbitrary operator expression <code class="computeroutput">f == g</code> is suitably
95      defined. The best solution known has the following undesirable
96      qualities:</p>
97<div class="orderedlist"><ol type="1">
98<li>Fails at compile-time for objects where
99        <code class="computeroutput">operator==</code> is not accessible (e.g., because it is
100        <code class="computeroutput">private</code>).</li>
101<li>Fails at compile-time if calling
102        <code class="computeroutput">operator==</code> is ambiguous.</li>
103<li>Appears to be correct if the
104        <code class="computeroutput">operator==</code> declaration is correct, even though
105        <code class="computeroutput">operator==</code> may not compile.</li>
106</ol></div>
107<p>All of these problems translate into failures in the
108      <code class="computeroutput"><a href="../boost/function.html" title="Class template function">boost::function</a></code> constructors or
109      assignment operator, <span class="emphasis"><em>even if the user never invokes
110      operator==</em></span>. We can't do that to users.</p>
111<p>The other option is to place the burden on users that want
112      to use <code class="computeroutput">operator==</code>, e.g., by providing an
113      <code class="computeroutput">is_equality_comparable</code> trait they may
114      specialize. This is a workable solution, but is dangerous in
115      practice, because forgetting to specialize the trait will result
116      in unexpected exceptions being thrown from
117      <code class="computeroutput"><a href="../boost/function.html" title="Class template function">boost::function</a></code>'s
118      <code class="computeroutput">operator==</code>. This essentially negates the usefulness
119      of <code class="computeroutput">operator==</code> in the context in which it is most
120      desired: multitarget callbacks. The
121      <a href="../signals.html" title="Chapter 9. Boost.Signals">Signals</a> library has a way around
122      this.</p>
123</td>
124</tr>
125<tr class="question">
126<td align="left" valign="top">
127<a name="id2699424"></a><a name="id2699425"></a><b>2.</b>
128</td>
129<td align="left" valign="top"><p>I see void pointers; is this [mess] type safe?</p></td>
130</tr>
131<tr class="answer">
132<td align="left" valign="top"><b></b></td>
133<td align="left" valign="top"><p>Yes, <code class="computeroutput">boost::function</code> is type
134safe even though it uses void pointers and pointers to functions
135returning void and taking no arguments. Essentially, all type
136information is encoded in the functions that manage and invoke
137function pointers and function objects. Only these functions are
138instantiated with the exact type that is pointed to by the void
139pointer or pointer to void function. The reason that both are required
140is that one may cast between void pointers and object pointers safely
141or between different types of function pointers (provided you don't
142invoke a function pointer with the wrong type).  </p></td>
143</tr>
144<tr class="question">
145<td align="left" valign="top">
146<a name="id2699448"></a><a name="id2699449"></a><b>3.</b>
147</td>
148<td align="left" valign="top"><p>Why are there workarounds for void returns? C++ allows them!</p></td>
149</tr>
150<tr class="answer">
151<td align="left" valign="top"><b></b></td>
152<td align="left" valign="top">
153<p>Void returns are permitted by the C++ standard, as in this code snippet:
154</p>
155<pre class="programlisting">void f();
156void g() { return f(); }</pre>
157<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:
158</p>
159<pre class="programlisting">int f();
160void g() { return f(); }</pre>
161<p> In essence, not using void returns allows
162<code class="computeroutput">boost::function</code> to swallow a return value. This is
163consistent with allowing the user to assign and invoke functions and
164function objects with parameters that don't exactly match.</p>
165</td>
166</tr>
167<tr class="question">
168<td align="left" valign="top">
169<a name="id2699490"></a><a name="id2699492"></a><b>4.</b>
170</td>
171<td align="left" valign="top"><p>Why (function) cloning?</p></td>
172</tr>
173<tr class="answer">
174<td align="left" valign="top"><b></b></td>
175<td align="left" valign="top"><p>In November and December of 2000, the issue of cloning
176      vs. reference counting was debated at length and it was decided
177      that cloning gave more predictable semantics. I won't rehash the
178      discussion here, but if it cloning is incorrect for a particular
179      application a reference-counting allocator could be used.</p></td>
180</tr>
181<tr class="question">
182<td align="left" valign="top">
183<a name="id2699504"></a><a name="id2699505"></a><b>5.</b>
184</td>
185<td align="left" valign="top"><p>How much overhead does a call through <code class="computeroutput"><a href="../boost/function.html" title="Class template function">boost::function</a></code> incur?</p></td>
186</tr>
187<tr class="answer">
188<td align="left" valign="top"><b></b></td>
189<td align="left" valign="top">
190<p>The cost of <code class="computeroutput">boost::function</code> can be reasonably
191      consistently measured at around 20ns +/- 10 ns on a modern &gt;2GHz
192      platform versus directly inlining the code.</p>
193<p>However, the performance of your application may benefit
194      from or be disadvantaged by <code class="computeroutput">boost::function</code>
195      depending on how your C++ optimiser optimises.  Similar to a
196      standard function pointer, differences of order of 10% have been
197      noted to the benefit or disadvantage of using
198      <code class="computeroutput">boost::function</code> to call a function that contains a
199      tight loop depending on your compilation circumstances.</p>
200<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>
201</td>
202</tr>
203</tbody>
204</table>
205</div>
206</div>
207<table width="100%"><tr>
208<td align="left"><small><p>Last revised: February 18, 2004 at 06:37:13 GMT</p></small></td>
209<td align="right"><small>Copyright © 2001-2004 Douglas Gregor</small></td>
210</tr></table>
211<hr>
212<div class="spirit-nav">
213<a accesskey="p" href="../function_equal.html"><img src="../images/prev.png" alt="Prev"></a><a accesskey="u" href="../function.html"><img src="../images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../images/home.png" alt="Home"></a><a accesskey="n" href="misc.html"><img src="../images/next.png" alt="Next"></a>
214</div>
215</body>
216</html>
Note: See TracBrowser for help on using the repository browser.