libs/function/doc/faq.xml

   1 <?xml version="1.0" encoding="utf-8"?>
   2 <!--
   3    Copyright (c) 2002 Douglas Gregor <doug.gregor -at- gmail.com>
   4
   5    Distributed under the Boost Software License, Version 1.0.
   6    (See accompanying file LICENSE_1_0.txt or copy at
   7    http://www.boost.org/LICENSE_1_0.txt)
   8   -->
   9 <!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
  10   "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd">
  11 <section id="function.faq" last-revision="$Date$">
  12   <title>Frequently Asked Questions</title>
  13
  14 <qandaset>
  15   <qandaentry>
  16     <question><para>Why can't I compare
  17     <classname>boost::function</classname> objects with
  18     <code>operator==</code> or
  19     <code>operator!=</code>?</para></question>
  20
  21     <answer>
  22       <para>Comparison between <classname>boost::function</classname>
  23       objects cannot be implemented "well", and therefore will not be
  24       implemented. The typical semantics requested for <code>f ==
  25       g</code> given <classname>boost::function</classname> objects
  26       <code>f</code> and <code>g</code> are:</para>
  27         <itemizedlist>
  28           <listitem><simpara>If <code>f</code> and <code>g</code>
  29           store function objects of the same type, use that type's
  30           <code>operator==</code> to compare
  31           them.</simpara></listitem>
  32
  33           <listitem><simpara>If <code>f</code> and <code>g</code>
  34           store function objects of different types, return
  35           <code>false</code>.</simpara></listitem>
  36         </itemizedlist>
  37       <para>The problem occurs when the type of the function objects
  38       stored by both <code>f</code> and <code>g</code> doesn't have an
  39       <code>operator==</code>: we would like the expression <code>f ==
  40       g</code> to fail to compile, as occurs with, e.g., the standard
  41       containers. However, this is not implementable for
  42       <classname>boost::function</classname> because it necessarily
  43       "erases" some type information after it has been assigned a
  44       function object, so it cannot try to call
  45       <code>operator==</code> later: it must either find a way to call
  46       <code>operator==</code> now, or it will never be able to call it
  47       later. Note, for instance, what happens if you try to put a
  48       <code>float</code> value into a
  49       <classname>boost::function</classname> object: you will get an
  50       error at the assignment operator or constructor, not in
  51       <code>operator()</code>, because the function-call expression
  52       must be bound in the constructor or assignment operator.</para>
  53
  54       <para>The most promising approach is to find a method of
  55       determining if <code>operator==</code> can be called for a
  56       particular type, and then supporting it only when it is
  57       available; in other situations, an exception would be
  58       thrown. However, to date there is no known way to detect if an
  59       arbitrary operator expression <code>f == g</code> is suitably
  60       defined. The best solution known has the following undesirable
  61       qualities:</para>
  62
  63       <orderedlist>
  64         <listitem><simpara>Fails at compile-time for objects where
  65         <code>operator==</code> is not accessible (e.g., because it is
  66         <code>private</code>).</simpara></listitem>
  67
  68         <listitem><simpara>Fails at compile-time if calling
  69         <code>operator==</code> is ambiguous.</simpara></listitem>
  70
  71         <listitem><simpara>Appears to be correct if the
  72         <code>operator==</code> declaration is correct, even though
  73         <code>operator==</code> may not compile.</simpara></listitem>
  74       </orderedlist>
  75
  76       <para>All of these problems translate into failures in the
  77       <classname>boost::function</classname> constructors or
  78       assignment operator, <emphasis>even if the user never invokes
  79       operator==</emphasis>. We can't do that to users.</para>
  80
  81       <para>The other option is to place the burden on users that want
  82       to use <code>operator==</code>, e.g., by providing an
  83       <code>is_equality_comparable</code> trait they may
  84       specialize. This is a workable solution, but is dangerous in
  85       practice, because forgetting to specialize the trait will result
  86       in unexpected exceptions being thrown from
  87       <classname>boost::function</classname>'s
  88       <code>operator==</code>. This essentially negates the usefulness
  89       of <code>operator==</code> in the context in which it is most
  90       desired: multitarget callbacks. The
  91       <libraryname>Signals</libraryname> library has a way around
  92       this.</para>
  93     </answer>
  94   </qandaentry>
  95
  96   <qandaentry>
  97     <question><para>I see void pointers; is this [mess] type safe?</para></question>
  98     <answer>
  99 <para>Yes, <computeroutput>boost::function</computeroutput> is type
 100 safe even though it uses void pointers and pointers to functions
 101 returning void and taking no arguments. Essentially, all type
 102 information is encoded in the functions that manage and invoke
 103 function pointers and function objects. Only these functions are
 104 instantiated with the exact type that is pointed to by the void
 105 pointer or pointer to void function. The reason that both are required
 106 is that one may cast between void pointers and object pointers safely
 107 or between different types of function pointers (provided you don't
 108 invoke a function pointer with the wrong type).  </para>
 109     </answer>
 110   </qandaentry>
 111
 112   <qandaentry>
 113     <question><para>Why are there workarounds for void returns? C++ allows them!</para></question>
 114     <answer><para>Void returns are permitted by the C++ standard, as in this code snippet:
 115 <programlisting>void f();
 116 void g() { return f(); }</programlisting>
 117     </para>
 118
 119     <para> This is a valid usage of <computeroutput>boost::function</computeroutput> because void returns are not used. With void returns, we would attempting to compile ill-formed code similar to:
 120 <programlisting>int f();
 121 void g() { return f(); }</programlisting>
 122 </para>
 123
 124 <para> In essence, not using void returns allows
 125 <computeroutput>boost::function</computeroutput> to swallow a return value. This is
 126 consistent with allowing the user to assign and invoke functions and
 127 function objects with parameters that don't exactly match.</para>
 128
 129     </answer>
 130   </qandaentry>
 131
 132   <qandaentry>
 133     <question><para>Why (function) cloning?</para></question>
 134     <answer>
 135       <para>In November and December of 2000, the issue of cloning
 136       vs. reference counting was debated at length and it was decided
 137       that cloning gave more predictable semantics. I won't rehash the
 138       discussion here, but if it cloning is incorrect for a particular
 139       application a reference-counting allocator could be used.</para>
 140     </answer>
 141   </qandaentry>
 142
 143   <qandaentry>
 144     <question><para>How much overhead does a call through <code><classname>boost::function</classname></code> incur?</para></question>
 145     <answer>
 146       <para>The cost of <code>boost::function</code> can be reasonably
 147       consistently measured at around 20ns +/- 10 ns on a modern >2GHz
 148       platform versus directly inlining the code.</para>
 149
 150       <para>However, the performance of your application may benefit
 151       from or be disadvantaged by <code>boost::function</code>
 152       depending on how your C++ optimiser optimises.  Similar to a
 153       standard function pointer, differences of order of 10% have been
 154       noted to the benefit or disadvantage of using
 155       <code>boost::function</code> to call a function that contains a
 156       tight loop depending on your compilation circumstances.</para>
 157
 158       <para>[Answer provided by Matt Hurd. See <ulink url="http://article.gmane.org/gmane.comp.lib.boost.devel/33278"/>]</para>
 159     </answer>
 160   </qandaentry>
 161 </qandaset>
 162
 163 </section>