boost_1_45_0/doc/html/function/faq.html - nest-learning-thermostat/5.0/boost - Git at Google

 <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&#160;7.&#160;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&#160;18.&#160;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 &gt;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 &#169; 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>
	<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>