boostorg/function
1
0
Fork 1
mirror of https://github.com/boostorg/function.git synced 2025-07-29 20:37:14 +02:00
Code Issues Packages Projects Releases Wiki Activity

Answer the eternal operator== question.

Browse Source 
[SVN r20356]
This commit is contained in:
Douglas Gregor
2003-10-12 16:02:26 +00:00
parent b8d943ec27
commit 2c708069e8
1 changed files with 81 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

81
doc/faq.xml
View File

@ -5,6 +5,87 @@
<title>Frequently Asked Questions</title>
<qandaset>
<qandaentry>
<question><para>Why can't I compare
<classname>boost::function</classname> objects with
<code>operator==</code> or
<code>operator!=</code>?</para></question>
<answer>
<para>Comparison between <classname>boost::function</classname>
objects cannot be implemented "well", and therefore will not be
implemented. The typical semantics requested for <code>f ==
g</code> given <classname>boost::function</classname> objects
<code>f</code> and <code>g</code> are:</para>
<itemizedlist>
<listitem><simpara>If <code>f</code> and <code>g</code>
store function objects of the same type, use that type's
<code>operator==</code> to compare
them.</simpara></listitem>
<listitem><simpara>If <code>f</code> and <code>g</code>
store function objects of different types, return
<code>false</code>.</simpara></listitem>
</itemizedlist>
<para>The problem occurs when the type of the function objects
stored by both <code>f</code> and <code>g</code> doesn't have an
<code>operator==</code>: we would like the expression <code>f ==
g</code> to fail to compile, as occurs with, e.g., the standard
containers. However, this is not implementable for
<classname>boost::function</classname> because it necessarily
"erases" some type information after it has been assigned a
function object, so it cannot try to call
<code>operator==</code> later: it must either find a way to call
<code>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>float</code> value into a
<classname>boost::function</classname> object: you will get an
error at the assignment operator or constructor, not in
<code>operator()</code>, because the function-call expression
must be bound in the constructor or assignment operator.</para>
<para>The most promising approach is to find a method of
determining if <code>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>f == g</code> is suitably
defined. The best solution known has the following undesirable
qualities:</para>
<orderedlist>
<listitem><simpara>Fails at compile-time for objects where
<code>operator==</code> is not accessible (e.g., because it is
<code>private</code>).</simpara></listitem>
<listitem><simpara>Fails at compile-time if calling
<code>operator==</code> is ambiguous.</simpara></listitem>
<listitem><simpara>Appears to be correct if the
<code>operator==</code> declaration is correct, even though
<code>operator==</code> may not compile.</simpara></listitem>
</orderedlist>
<para>All of these problems translate into failures in the
<classname>boost::function</classname> constructors or
assignment operator, <emphasis>even if the user never invokes
operator==</emphasis>. We can't do that to users.</para>
<para>The other option is to place the burden on users that want
to use <code>operator==</code>, e.g., by providing an
<code>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
<classname>boost::function</classname>'s
<code>operator==</code>. This essentially negates the usefulness
of <code>operator==</code> in the context in which it is most
desired: multitarget callbacks. The
<libraryname>Signals</libraryname> library has a way around
this.</para>
</answer>
</qandaentry>
<qandaentry>
<question><para>I see void pointers; is this [mess] type safe?</para></question>
<answer>