Merged L & C issue fixes from trunk to branch.

[SVN r36246]
This commit is contained in:
Andreas Huber
2006-12-02 14:17:26 +00:00
parent a2202df1fe
commit d2b04d968c
8 changed files with 990 additions and 697 deletions
+109 -86
View File
@@ -1,135 +1,158 @@
<html>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Boost Function Object Adapter Library</title>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<title>Boost Function Object Adapter Library</title>
</head>
<body bgcolor="#FFFFFF" text="#000000">
<table border="1" bgcolor="#007F7F" cellpadding="2" summary="">
<tr>
<td bgcolor="#FFFFFF"><img src="../../boost.png" alt=
"boost.png (6897 bytes)" width="277" height="86"></td>
<table border="1" bgcolor="#007F7F" cellpadding="2">
<tr>
<td bgcolor="#FFFFFF"><img src="../../boost.png" alt="boost.png (6897 bytes)" WIDTH="277" HEIGHT="86"></td>
<td><a href="../../index.htm"><font face="Arial" color="#FFFFFF"><big>Home </big></font></a></td>
<td><a href="../libraries.htm"><font face="Arial" color="#FFFFFF"><big>Libraries </big></font></a></td>
<td><a href="../../people/people.htm"><font face="Arial" color="#FFFFFF"><big>People </big></font></a></td>
<td><a href="../../more/faq.htm"><font face="Arial" color="#FFFFFF"><big>FAQ </big></font></a></td>
<td><a href="../../more/index.htm"><font face="Arial" color="#FFFFFF"><big>More </big></font></a></td>
</tr>
</table>
<td><a href="../../index.htm"><font face="Arial" color=
"#FFFFFF"><big>Home</big></font></a></td>
<h1>Function Pointer Adapters</h1>
<td><a href="../libraries.htm"><font face="Arial" color=
"#FFFFFF"><big>Libraries</big></font></a></td>
<p>The header <nobr><a
href="../../boost/functional.hpp">functional.hpp</a></nobr> provides
enhanced versions of both the function pointer adapters from the C++
Standard Library <nobr>(&sect 20.3.7):</nobr></p>
<td><a href="../../people/people.htm"><font face="Arial" color=
"#FFFFFF"><big>People</big></font></a></td>
<ul>
<li><tt>pointer_to_unary_function</tt></li>
<li><tt>pointer_to_binary_function</tt></li>
</ul>
<td><a href="../../more/faq.htm"><font face="Arial" color=
"#FFFFFF"><big>FAQ</big></font></a></td>
<p>As well as the corresponding helper function template:</p>
<td><a href="../../more/index.htm"><font face="Arial" color=
"#FFFFFF"><big>More</big></font></a></td>
</tr>
</table>
<ul>
<li><tt>ptr_fun</tt></li>
</ul>
<h1>Function Pointer Adapters</h1>
<p>However, you should not need to use the adapters in conjunction
with the adapters in this library due to our use of <a
href="function_traits.html">function object traits</a>. You will
however need to use them if your implementation fails to work properly
with our traits classes (due to lack if partial specialisation), or if
you wish to use a function object adapter from a third party.
<p>The header <a href="../../boost/functional.hpp">functional.hpp</a>
provides enhanced versions of both the function pointer adapters from the
C++ Standard Library (&sect;20.3.7):</p>
<h3>Usage</h3>
<ul>
<li><tt>pointer_to_unary_function</tt></li>
<p>If you need to use these adapters, usage is identical to the
standard function pointer adapters. For example,</p>
<li><tt>pointer_to_binary_function</tt></li>
</ul>
<blockquote><pre>
<p>As well as the corresponding helper function template:</p>
<ul>
<li><tt>ptr_fun</tt></li>
</ul>
<p>However, you should not need to use the adapters in conjunction with the
adapters in this library due to our use of <a href=
"function_traits.html">function object traits</a>. You will however need to
use them if your implementation fails to work properly with our traits
classes (due to lack if partial specialisation), or if you wish to use a
function object adapter from a third party.</p>
<h3>Usage</h3>
<p>If you need to use these adapters, usage is identical to the standard
function pointer adapters. For example,</p>
<blockquote>
<pre>
bool bad(std::string foo) { ... }
...
std::vector&lt;std::string&gt; c;
...
std::vector&lt;std::string&gt;::iterator it
= std::find_if(c.begin(), c.end(), std::not1(boost::ptr_fun(bad)));
</pre></blockquote>
</pre>
</blockquote>
<p>Note however that this library contains enhanced <a
href="negators.html">negators</a> that support function object traits,
so the line above could equally be written
<p>Note however that this library contains enhanced <a href=
"negators.html">negators</a> that support function object traits, so the
line above could equally be written</p>
<blockquote><pre>
<blockquote>
<pre>
std::vector&lt;std::string&gt;::iterator it
= std::find_if(c.begin(), c.end(), boost::not1(bad));
</pre></blockquote>
</pre>
</blockquote>
<h3>Argument Types</h3>
<h3>Argument Types</h3>
<p>The standard defines
<nobr><tt>pointer_to_unary_function</tt></nobr> like this
<nobr>(&sect;20.3.8 &para;2):</nobr>
<p>The standard defines <tt>pointer_to_unary_function</tt> like this
(&sect;20.3.8&nbsp;&para;2):</p>
<blockquote><pre>
<blockquote>
<pre>
template &lt;class Arg, class Result&gt;
class pointer_to_unary_function : public unary_function&lt;Arg, Result&gt; {
public:
explicit pointer_to_unary_function(Result (* f)(<strong>Arg</strong>));
Result operator()(<strong>Arg</strong> x) const;
};
</pre></blockquote>
</pre>
</blockquote>
<p>Note that the argument to <nobr><tt>operator()</tt></nobr> is
exactly the same type as the argument to the wrapped function. If this
is a value type, the argument will be passed by value and copied twice.
<nobr><tt>pointer_to_binary_function</tt></nobr> has a similar problem.
<p>Note that the argument to <tt>operator()</tt> is exactly the same type
as the argument to the wrapped function. If this is a value type, the
argument will be passed by value and copied twice.
<tt>pointer_to_binary_function</tt> has a similar problem.</p>
<p>However, if we were to try and eliminate this inefficiency by
instead declaring the argument as <nobr><tt>const Arg&</tt></nobr>, then
if Arg were a reference type, we would have a reference to a reference,
which is currently illegal (but see <a
href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#106">C++
core language issue number 106)</a>
<p>However, if we were to try and eliminate this inefficiency by instead
declaring the argument as <tt>const&nbsp;Arg&amp;</tt>, then if Arg were a
reference type, we would have a reference to a reference, which is
currently illegal (but see <a href=
"http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#106">C++ core
language issue number 106)</a></p>
<p>So the way in which we want to declare the argument for
<nobr><tt>operator()</tt></nobr> depends on whether or not the
wrapped function's argument is a reference. If it
is a reference, we want to declare it simply as
<nobr><tt>Arg</tt></nobr>; if it is a value we want to
declare it as <nobr><tt>const Arg&</tt></nobr>.
<p>So the way in which we want to declare the argument for
<tt>operator()</tt> depends on whether or not the wrapped function's
argument is a reference. If it is a reference, we want to declare it simply
as <tt>Arg</tt>; if it is a value we want to declare it as
<tt>const&nbsp;Arg&amp;</tt>.</p>
<p>The Boost <nobr><a
href="../utility/call_traits.htm">call_traits</a></nobr> class
template contains a <tt><nobr>param_type</nobr></tt> typedef, which
uses partial specialisation to make precisely this decision. By
declaring the <nobr><tt>operator()</tt></nobr> as
<p>The Boost <a href="../utility/call_traits.htm">call_traits</a> class
template contains a <tt>param_type</tt> typedef, which uses partial
specialisation to make precisely this decision. By declaring the
<tt>operator()</tt> as</p>
<blockquote><pre>
<blockquote>
<pre>
Result operator()(typename call_traits&lt;Arg&gt;::param_type x) const
</pre></blockquote>
</pre>
</blockquote>
<p>we achieve the desired result - we improve efficiency without
generating references to references.</p>
<p>we achieve the desired result - we improve efficiency without generating
references to references.</p>
<h3>Limitations</h3>
<h3>Limitations</h3>
<p>The call traits template used to realise this improvement relies
on partial specialisation, so this improvement is only available on
compilers that support that feature. With other compilers, the
argument passed to the function will always be passed by
reference, thus generating the possibility of references to references.
<p>The call traits template used to realise this improvement relies on
partial specialisation, so this improvement is only available on compilers
that support that feature. With other compilers, the argument passed to the
function will always be passed by reference, thus generating the
possibility of references to references.</p>
<hr>
<hr>
<p><a href="http://validator.w3.org/check?uri=referer"><img border="0" src=
"http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01 Transitional"
height="31" width="88"></a></p>
<p>Copyright &copy; 2000 Cadenza New Zealand Ltd. Permission to copy,
use, modify, sell and distribute this document is granted provided
this copyright notice appears in all copies. This document is provided
"as is" without express or implied warranty, and with no claim as to
its suitability for any purpose.</p>
<p>Revised
<!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->02
December, 2006<!--webbot bot="Timestamp" endspan i-checksum="38510" --></p>
<p>Revised 28 June 2000</p>
<p><i>Copyright &copy; 2000 Cadenza New Zealand Ltd.</i></p>
<p><i>Distributed under the Boost Software License, Version 1.0. (See
accompanying file <a href="../../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or
copy at <a href=
"http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>)</i></p>
</body>
</html>