]>
Commit | Line | Data |
---|---|---|
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> |