| <html> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=US-ASCII"> |
| <title>Frequently Asked Questions</title> |
| <link rel="stylesheet" href="../../../doc/src/boostbook.css" type="text/css"> |
| <meta name="generator" content="DocBook XSL Stylesheets V1.75.2"> |
| <link rel="home" href="../index.html" title="The Boost C++ Libraries BoostBook Documentation Subset"> |
| <link rel="up" href="../function.html" title="Chapter 7. Boost.Function"> |
| <link rel="prev" href="../boost/function_equal.html" title="Function template function_equal"> |
| <link rel="next" href="misc.html" title="Miscellaneous Notes"> |
| </head> |
| <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> |
| <table cellpadding="2" width="100%"><tr> |
| <td valign="top"><img alt="Boost C++ Libraries" width="277" height="86" src="../../../boost.png"></td> |
| <td align="center"><a href="../../../index.html">Home</a></td> |
| <td align="center"><a href="../../../libs/libraries.htm">Libraries</a></td> |
| <td align="center"><a href="http://www.boost.org/users/people.html">People</a></td> |
| <td align="center"><a href="http://www.boost.org/users/faq.html">FAQ</a></td> |
| <td align="center"><a href="../../../more/index.htm">More</a></td> |
| </tr></table> |
| <hr> |
| <div class="spirit-nav"> |
| <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> |
| </div> |
| <div class="section"> |
| <div class="titlepage"><div><div><h2 class="title" style="clear: both"> |
| <a name="function.faq"></a>Frequently Asked Questions</h2></div></div></div> |
| <div class="qandaset"> |
| <a name="id1284468"></a><dl> |
| <dt>1. <a href="faq.html#id1284470">Why can't I compare |
| boost::function objects with |
| operator== or |
| operator!=?</a> |
| </dt> |
| <dt>2. <a href="faq.html#id1284823">I see void pointers; is this [mess] type safe?</a> |
| </dt> |
| <dt>3. <a href="faq.html#id1284844">Why are there workarounds for void returns? C++ allows them!</a> |
| </dt> |
| <dt>4. <a href="faq.html#id1284895">Why (function) cloning?</a> |
| </dt> |
| <dt>5. <a href="faq.html#id1284915">How much overhead does a call through boost::function incur?</a> |
| </dt> |
| </dl> |
| <table border="0" width="100%" summary="Q and A Set"> |
| <col align="left" width="1%"> |
| <col> |
| <tbody> |
| <tr class="question"> |
| <td align="left" valign="top"> |
| <a name="id1284470"></a><a name="id1284472"></a><p><b>1.</b></p> |
| </td> |
| <td align="left" valign="top"><p>Why can't I compare |
| <code class="computeroutput"><a class="link" href="../boost/function.html" title="Class template function">boost::function</a></code> objects with |
| <code class="computeroutput">operator==</code> or |
| <code class="computeroutput">operator!=</code>?</p></td> |
| </tr> |
| <tr class="answer"> |
| <td align="left" valign="top"></td> |
| <td align="left" valign="top"> |
| <p>Comparison between <code class="computeroutput"><a class="link" href="../boost/function.html" title="Class template function">boost::function</a></code> |
| objects cannot be implemented "well", and therefore will not be |
| implemented. The typical semantics requested for <code class="computeroutput">f == |
| g</code> given <code class="computeroutput"><a class="link" href="../boost/function.html" title="Class template function">boost::function</a></code> objects |
| <code class="computeroutput">f</code> and <code class="computeroutput">g</code> are:</p> |
| <div class="itemizedlist"><ul class="itemizedlist" type="disc"> |
| <li class="listitem">If <code class="computeroutput">f</code> and <code class="computeroutput">g</code> |
| store function objects of the same type, use that type's |
| <code class="computeroutput">operator==</code> to compare |
| them.</li> |
| <li class="listitem">If <code class="computeroutput">f</code> and <code class="computeroutput">g</code> |
| store function objects of different types, return |
| <code class="computeroutput">false</code>.</li> |
| </ul></div> |
| <p>The problem occurs when the type of the function objects |
| stored by both <code class="computeroutput">f</code> and <code class="computeroutput">g</code> doesn't have an |
| <code class="computeroutput">operator==</code>: we would like the expression <code class="computeroutput">f == |
| g</code> to fail to compile, as occurs with, e.g., the standard |
| containers. However, this is not implementable for |
| <code class="computeroutput"><a class="link" href="../boost/function.html" title="Class template function">boost::function</a></code> because it necessarily |
| "erases" some type information after it has been assigned a |
| function object, so it cannot try to call |
| <code class="computeroutput">operator==</code> later: it must either find a way to call |
| <code class="computeroutput">operator==</code> now, or it will never be able to call it |
| later. Note, for instance, what happens if you try to put a |
| <code class="computeroutput">float</code> value into a |
| <code class="computeroutput"><a class="link" href="../boost/function.html" title="Class template function">boost::function</a></code> object: you will get an |
| error at the assignment operator or constructor, not in |
| <code class="computeroutput">operator()</code>, because the function-call expression |
| must be bound in the constructor or assignment operator.</p> |
| <p>The most promising approach is to find a method of |
| determining if <code class="computeroutput">operator==</code> can be called for a |
| particular type, and then supporting it only when it is |
| available; in other situations, an exception would be |
| thrown. However, to date there is no known way to detect if an |
| arbitrary operator expression <code class="computeroutput">f == g</code> is suitably |
| defined. The best solution known has the following undesirable |
| qualities:</p> |
| <div class="orderedlist"><ol class="orderedlist" type="1"> |
| <li class="listitem">Fails at compile-time for objects where |
| <code class="computeroutput">operator==</code> is not accessible (e.g., because it is |
| <code class="computeroutput">private</code>).</li> |
| <li class="listitem">Fails at compile-time if calling |
| <code class="computeroutput">operator==</code> is ambiguous.</li> |
| <li class="listitem">Appears to be correct if the |
| <code class="computeroutput">operator==</code> declaration is correct, even though |
| <code class="computeroutput">operator==</code> may not compile.</li> |
| </ol></div> |
| <p>All of these problems translate into failures in the |
| <code class="computeroutput"><a class="link" href="../boost/function.html" title="Class template function">boost::function</a></code> constructors or |
| assignment operator, <span class="emphasis"><em>even if the user never invokes |
| operator==</em></span>. We can't do that to users.</p> |
| <p>The other option is to place the burden on users that want |
| to use <code class="computeroutput">operator==</code>, e.g., by providing an |
| <code class="computeroutput">is_equality_comparable</code> trait they may |
| specialize. This is a workable solution, but is dangerous in |
| practice, because forgetting to specialize the trait will result |
| in unexpected exceptions being thrown from |
| <code class="computeroutput"><a class="link" href="../boost/function.html" title="Class template function">boost::function</a></code>'s |
| <code class="computeroutput">operator==</code>. This essentially negates the usefulness |
| of <code class="computeroutput">operator==</code> in the context in which it is most |
| desired: multitarget callbacks. The |
| <a class="link" href="../signals.html" title="Chapter 18. Boost.Signals">Signals</a> library has a way around |
| this.</p> |
| </td> |
| </tr> |
| <tr class="question"> |
| <td align="left" valign="top"> |
| <a name="id1284823"></a><a name="id1284825"></a><p><b>2.</b></p> |
| </td> |
| <td align="left" valign="top"><p>I see void pointers; is this [mess] type safe?</p></td> |
| </tr> |
| <tr class="answer"> |
| <td align="left" valign="top"></td> |
| <td align="left" valign="top"><p>Yes, <code class="computeroutput">boost::function</code> is type |
| safe even though it uses void pointers and pointers to functions |
| returning void and taking no arguments. Essentially, all type |
| information is encoded in the functions that manage and invoke |
| function pointers and function objects. Only these functions are |
| instantiated with the exact type that is pointed to by the void |
| pointer or pointer to void function. The reason that both are required |
| is that one may cast between void pointers and object pointers safely |
| or between different types of function pointers (provided you don't |
| invoke a function pointer with the wrong type). </p></td> |
| </tr> |
| <tr class="question"> |
| <td align="left" valign="top"> |
| <a name="id1284844"></a><a name="id1284846"></a><p><b>3.</b></p> |
| </td> |
| <td align="left" valign="top"><p>Why are there workarounds for void returns? C++ allows them!</p></td> |
| </tr> |
| <tr class="answer"> |
| <td align="left" valign="top"></td> |
| <td align="left" valign="top"> |
| <p>Void returns are permitted by the C++ standard, as in this code snippet: |
| </p> |
| <pre class="programlisting">void f(); |
| void g() { return f(); }</pre> |
| <p> |
| </p> |
| <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: |
| </p> |
| <pre class="programlisting">int f(); |
| void g() { return f(); }</pre> |
| <p> |
| </p> |
| <p> In essence, not using void returns allows |
| <code class="computeroutput">boost::function</code> to swallow a return value. This is |
| consistent with allowing the user to assign and invoke functions and |
| function objects with parameters that don't exactly match.</p> |
| </td> |
| </tr> |
| <tr class="question"> |
| <td align="left" valign="top"> |
| <a name="id1284895"></a><a name="id1284897"></a><p><b>4.</b></p> |
| </td> |
| <td align="left" valign="top"><p>Why (function) cloning?</p></td> |
| </tr> |
| <tr class="answer"> |
| <td align="left" valign="top"></td> |
| <td align="left" valign="top"><p>In November and December of 2000, the issue of cloning |
| vs. reference counting was debated at length and it was decided |
| that cloning gave more predictable semantics. I won't rehash the |
| discussion here, but if it cloning is incorrect for a particular |
| application a reference-counting allocator could be used.</p></td> |
| </tr> |
| <tr class="question"> |
| <td align="left" valign="top"> |
| <a name="id1284915"></a><a name="id1284917"></a><p><b>5.</b></p> |
| </td> |
| <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> |
| </tr> |
| <tr class="answer"> |
| <td align="left" valign="top"></td> |
| <td align="left" valign="top"> |
| <p>The cost of <code class="computeroutput">boost::function</code> can be reasonably |
| consistently measured at around 20ns +/- 10 ns on a modern >2GHz |
| platform versus directly inlining the code.</p> |
| <p>However, the performance of your application may benefit |
| from or be disadvantaged by <code class="computeroutput">boost::function</code> |
| depending on how your C++ optimiser optimises. Similar to a |
| standard function pointer, differences of order of 10% have been |
| noted to the benefit or disadvantage of using |
| <code class="computeroutput">boost::function</code> to call a function that contains a |
| tight loop depending on your compilation circumstances.</p> |
| <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> |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| </div> |
| </div> |
| <table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr> |
| <td align="left"><p><small>Last revised: November 03, 2006 at 19:41:10 +0000</small></p></td> |
| <td align="right"><div class="copyright-footer">Copyright © 2001-2004 Douglas Gregor<p>Use, modification and distribution is subject to the Boost |
| Software License, Version 1.0. (See accompanying file |
| <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> |
| </div></td> |
| </tr></table> |
| <hr> |
| <div class="spirit-nav"> |
| <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> |
| </div> |
| </body> |
| </html> |