mirror of
https://github.com/boostorg/function.git
synced 2025-07-23 09:27:14 +02:00
The old HTML Function documentation has been removed. The file index.html
redirects to $BOOST_ROOT/doc/html/function.html, the new home for the Function library documentation [SVN r17467]
This commit is contained in:
Douglas Gregor
44
doc/faq.html
44
doc/faq.html
@ -1,44 +0,0 @@
|
|||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
||||||
<html>
|
|
||||||
<head>
|
|
||||||
<title>Boost.Function Frequently Asked Questions</title>
|
|
||||||
</head>
|
|
||||||
|
|
||||||
<body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080">
|
|
||||||
<h1><IMG SRC="../../../c++boost.gif" WIDTH="276" HEIGHT="86">boost::function Frequently Asked Questions</h1>
|
|
||||||
|
|
||||||
<h2>Q: I see void pointers; is this [mess] type safe?</h2>
|
|
||||||
<p>Yes, <code>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).
|
|
||||||
|
|
||||||
<h2>Q: Why are there workarounds for void returns? C++ allows them!</h2>
|
|
||||||
<p>Void returns are permitted by the C++ standard, as in this code snippet:
|
|
||||||
<pre>
|
|
||||||
void f();
|
|
||||||
void g() { return f(); }
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
<p> One reason for not using void returns is that not all compilers support them. In fact, very few compilers seem to support this trivial feature. Additionally, <code>boost::function</code> is more flexible because it does not use void returns. Consider the following code:
|
|
||||||
<pre>
|
|
||||||
int do_something(int);
|
|
||||||
|
|
||||||
boost::function<void, int> f;
|
|
||||||
f = do_something;
|
|
||||||
</pre>
|
|
||||||
<p> This is a valid usage of <code>boost::function</code> because void returns are not used. With void returns, we would attempting to compile ill-formed code similar to:
|
|
||||||
<pre>
|
|
||||||
int f();
|
|
||||||
void g() { return f(); }
|
|
||||||
</pre>
|
|
||||||
<p> In essence, not using void returns allows <code>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.
|
|
||||||
|
|
||||||
<h2>Q: Why (function) cloning? </h2>
|
|
||||||
<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.
|
|
||||||
|
|
||||||
<hr>
|
|
||||||
<address><a href="mailto:gregod@cs.rpi.edu">Doug Gregor</a></address>
|
|
||||||
<!-- Created: Fri Feb 16 09:30:41 EST 2001 -->
|
|
||||||
<!-- hhmts start -->
|
|
||||||
Last modified: Wed Nov 7 15:11:52 EST 2001
|
|
||||||
<!-- hhmts end -->
|
|
||||||
</body>
|
|
||||||
</html>
|
|
||||||
@ -1,271 +0,0 @@
|
|||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
||||||
<html>
|
|
||||||
<head>
|
|
||||||
<title>Boost.Function Reference Manual</title>
|
|
||||||
</head>
|
|
||||||
|
|
||||||
<body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080">
|
|
||||||
|
|
||||||
<h1><IMG SRC="../../../c++boost.gif" WIDTH="276" HEIGHT="86">Boost.Function Reference Manual</h1>
|
|
||||||
|
|
||||||
<h2><a name="header">Header <code><<a href="../../../boost/function.hpp">boost/function.hpp</a>></code> synopsis</a></h2>
|
|
||||||
<p> Here <code><i>MAX_ARGS</i></code> is an implementation-defined constant that defines the maximum number of function arguments supported by Boost.Function and will be at least 10. The <code><i>MAX_ARGS</i></code> constant referred to in this document need not have any direct representation in the library.
|
|
||||||
|
|
||||||
<pre>
|
|
||||||
<b>namespace</b> boost {
|
|
||||||
<b>class</b> <a href="#function_base">function_base</a> <em> // Deprecated</em>
|
|
||||||
{
|
|
||||||
<a href="#empty"><b>bool</b> empty() <b>const</b></a>;
|
|
||||||
};
|
|
||||||
|
|
||||||
// For <i>N</i> in [0, <i>MAX_ARGS</i>]
|
|
||||||
<b>template</b><<b>typename</b> Signature,
|
|
||||||
<b>typename</b> Arg1,
|
|
||||||
<b>typename</b> Arg2,
|
|
||||||
<i>...</i>
|
|
||||||
<b>typename</b> Arg<i>N</i>,
|
|
||||||
<b>typename</b> Allocator = std::allocator<<b>void</b>> >
|
|
||||||
<b>class</b> <a href="#functionN">function<i>N</i></a> : <b>public</b> <a href="#function_base">function_base</a>
|
|
||||||
{
|
|
||||||
<b>typedef</b> <em>implementation-defined</em> safe_bool;
|
|
||||||
|
|
||||||
<b>public</b>:
|
|
||||||
<b>typedef</b> ResultType result_type; <em>// <a href="#novoid">[1]</a></em>
|
|
||||||
<b>typedef</b> Allocator allocator_type;
|
|
||||||
|
|
||||||
<b>typedef</b> Arg1 argument_type; <i>// If N == 1</i>
|
|
||||||
|
|
||||||
<b>typedef</b> Arg1 first_argument_type; <i>// If N == 2</i>
|
|
||||||
<b>typedef</b> Arg2 second_argument_type; <i>// If N == 2</i>
|
|
||||||
|
|
||||||
<b>typedef</b> Arg1 arg1_type;
|
|
||||||
<b>typedef</b> Arg2 arg2_type;
|
|
||||||
.
|
|
||||||
.
|
|
||||||
.
|
|
||||||
<b>typedef</b> Arg<em>N</em> arg<em>N</em>_type;
|
|
||||||
|
|
||||||
<b>enum</b> { arity = <em>N</em> };
|
|
||||||
|
|
||||||
<i>// Construction</i>
|
|
||||||
<a href="#functionN_default"><b>explicit</b> function<i>N</i>()</a>;
|
|
||||||
<a href="#functionN_copy">function<i>N</i>(<b>const</b> function<i>N</i><b>&</b>)</a>;
|
|
||||||
<a href="#functionN_target"><b>template</b><<b>typename</b> F> function<i>N</i>(F)</a>;
|
|
||||||
<a href="#functionN_target_ref"><b>template</b><<b>typename</b> F> function<i>N</i>(reference_wrapper<F>)</a>;
|
|
||||||
|
|
||||||
<i>// Assignment</i>
|
|
||||||
<a href="#functionN_copy_assn">function<i>N</i><b>&</b> <b>operator</b>=(<b>const</b> function<i>N</i><b>&</b>)</a>;
|
|
||||||
<a href="#functionN_target_assn"><b>template</b><<b>typename</b> F> function<i>N</i><b>&</b> <b>operator</b>=(F)</a>;
|
|
||||||
<a href="#functionN_target_ref_assn"><b>template</b><<b>typename</b> F> function<i>N</i><b>&</b> <b>operator</b>=(reference_wrapper<F>)</a>;
|
|
||||||
<a href="#functionN_swap"><b>void</b> swap(function<i>N</i><b>&</b>)</a>;
|
|
||||||
<a href="#functionN_clear"><b>void</b> clear()</a>;
|
|
||||||
|
|
||||||
<i>// Boolean context</i>
|
|
||||||
<a href="#bool"><b>operator</b> safe_bool() <b>const</b></a>;
|
|
||||||
<a href="#not"><b>bool</b> <b>operator!</b>() <b>const</b></a>;
|
|
||||||
|
|
||||||
<i>// Invocation</i>
|
|
||||||
<a href="#functionN_call_const">result_type <b>operator</b>()(Arg1 a1, Arg2 a2, <i>...</i>, Arg<i>N</i> a<i>N</i>) <b>const</b></a>;
|
|
||||||
};
|
|
||||||
|
|
||||||
<b>template</b><<b>typename</b> ResultType,
|
|
||||||
<b>typename</b> Arg1,
|
|
||||||
<b>typename</b> Arg2,
|
|
||||||
<i>...</i>
|
|
||||||
<b>typename</b> Arg<i>N</i>,
|
|
||||||
<b>typename</b> Allocator>
|
|
||||||
<b>void</b> <a href="#swap_functionN">swap</a>(function<em>N</em><ResultType, Arg1, Arg2, <i>...</i>, Arg<i>N</i>, Allocator><b>&</b>,
|
|
||||||
function<em>N</em><ResultType, Arg1, Arg2, <i>...</i>, Arg<i>N</i>, Allocator><b>&</b>);
|
|
||||||
|
|
||||||
// For any <i>N</i> in [0, <i>MAX_ARGS</i>]
|
|
||||||
<b>template</b><<b>typename</b> Signature, <em>// Function type: ResultType (Arg1, Arg2, ..., Arg<em>N</em>)</em>
|
|
||||||
<b>typename</b> Allocator = std::allocator<<b>void</b>> >
|
|
||||||
<b>class</b> <a href="#function">function</a> : <b>public</b> <a href="#functionN">function<i>N</i></a><ResultType, Arg1, Arg2, <i>...</i>, Arg<i>N</i>, Allocator>
|
|
||||||
{
|
|
||||||
<i>// Construction</i>
|
|
||||||
function();
|
|
||||||
function(<b>const</b> function<b>&</b>);
|
|
||||||
function(<b>const</b> function<i>N</i><ResultType, Arg1, Arg2, ..., Arg<i>N</i>, Allocator><b>&</b>);
|
|
||||||
<b>template</b><<b>typename</b> F> function<i>N</i>(F);
|
|
||||||
|
|
||||||
<i>// Assignment</i>
|
|
||||||
function<b>&</b> <b>operator</b>=(<b>const</b> function<b>&</b>);
|
|
||||||
function<b>&</b> <b>operator</b>=(<b>const</b> function<i>N</i><ResultType, Arg1, Arg2, ..., Arg<i>N</i>, Allocator><b>&</b>);
|
|
||||||
<b>template</b><<b>typename</b> F> function<b>&</b> <b>operator</b>=(F);
|
|
||||||
};
|
|
||||||
|
|
||||||
<b>template</b><<b>typename</b> Signature, <b>typename</b> Allocator>
|
|
||||||
<b>void</b> <a href="#swap_function">swap</a>(function<Signature, Allocator><b>&</b>,
|
|
||||||
function<Signature, Allocator><b>&</b>);
|
|
||||||
}
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
<h2>Definitions</h2>
|
|
||||||
<p>
|
|
||||||
<ul>
|
|
||||||
<li><a name="compatible"></a>A function object <code>f</code> is <em>compatible</em> if for the given set of argument types <code>Arg1</code>, <code>Arg2</code>, ..., <code>Arg<em>N</em></code> and a return type <code>ResultType</code>, the appropriate following function is well-formed:
|
|
||||||
<pre>
|
|
||||||
<em>// if ResultType is not <b>void</b></em>
|
|
||||||
ResultType foo(Arg1 arg1, Arg2 arg2, ..., Arg<em>N</em> arg<em>N</em>)
|
|
||||||
{
|
|
||||||
<b>return</b> f(arg1, arg2, ..., arg<em>N</em>);
|
|
||||||
}
|
|
||||||
|
|
||||||
<em>// if ResultType is <b>void</b></em>
|
|
||||||
ResultType foo(Arg1 arg1, Arg2 arg2, ..., Arg<em>N</em> arg<em>N</em>)
|
|
||||||
{
|
|
||||||
f(arg1, arg2, ..., arg<em>N</em>);
|
|
||||||
}
|
|
||||||
</pre>
|
|
||||||
<p> A special provision is made for pointers to member functions. Though they are not function objects, Boost.Function will adapt them internally to function objects. This requires that a pointer to member function of the form <code>R (X::*mf)(Arg1, Arg2, ..., Arg<em>N</em>) <em>cv-quals</em></code> be adapted to a function object with the following function call operator overloads:
|
|
||||||
<pre>
|
|
||||||
<b>template</b><<b>typename P</b>>
|
|
||||||
R <b>operator</b>()(<em>cv-quals</em> P& x, Arg1 arg1, Arg2 arg2, ..., Arg<em>N</em> arg<em>N</em>) <b>const</b>
|
|
||||||
{
|
|
||||||
<b>return</b> (*x).*mf(arg1, arg2, ..., arg<em>N</em>);
|
|
||||||
}
|
|
||||||
</pre>
|
|
||||||
<li><a name="stateless"></a>A function object <code>f</code> of type <code>F</code> is <em>stateless</em> if it is a function pointer or if <a href="../../type_traits/index.htm#properties"><code>boost::is_stateless<T></code></a> is true. The construction of or copy to a Boost.Function object from a stateless function object will not cause exceptions to be thrown and will not allocate any storage.</li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<h2><a name="function_base">Class <code>function_base</code></a></h2>
|
|
||||||
<p> Class <code>function_base</code> is the common base class for all Boost.Function objects. Objects of type <code>function_base</code> may not be created directly.
|
|
||||||
<p> <font color=red>Note: the use of this class by users is deprecated. This class will become an implementation detail in the future.</font>
|
|
||||||
<p> <a name="empty"><code><b>bool</b> empty() <b>const</b></code></a>
|
|
||||||
<ul>
|
|
||||||
<li><b>Returns</b>: <code>true</code> if the function object has a target, <code>false</code> otherwise.</li>
|
|
||||||
<li><b>Throws</b>: will not throw.</li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<h2><a name="functionN">Class template <code>function<i>N</i></code></a></h2>
|
|
||||||
<p> Class template <code>function<i>N</i></code> is actually a family of related classes <code>function0</code>, <code>function1</code>, etc., up to some implementation-defined maximum. In this context, <code><i>N</i></code> refers to the number of parameters and <code>f</code> refers to the implicit object parameter.
|
|
||||||
|
|
||||||
<p> <a name="functionN_default"><code><b>explicit</b> function<i>N</i>();</code></a>
|
|
||||||
<ul>
|
|
||||||
<li><b>Postconditions</b>: <code>f.<a href="#empty">empty</a>()</code>.</li>
|
|
||||||
<li><b>Throws</b>: will not throw.</li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p> <a name="functionN_copy"><code>function<i>N</i>(<b>const</b> function<i>N</i><b>&</b> g);</code></a>
|
|
||||||
<ul>
|
|
||||||
<li><b>Postconditions</b>: <code>f</code> contains a copy of the <code>g</code>'s target, if it has one, or is empty if <code>g.<a href="#empty">empty</a>()</code>. </li>
|
|
||||||
<li><b>Throws</b>: will not throw unless copying the target of <code>g</code> throws.</li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p> <a name="functionN_target"><code><b>template</b><<b>typename</b> F> function<i>N</i>(F g);</code></a>
|
|
||||||
<ul>
|
|
||||||
<li><b>Requires</b>: <code>g</code> is a <a href="#compatible">compatible</a> function object.</li>
|
|
||||||
<li><b>Postconditions</b>: <code>f</code> targets a copy of <code>g</code> if <code>g</code> is nonempty, or <code>f.<a href="#empty">empty</a>()</code> if <code>g</code> is empty.</li>
|
|
||||||
<li><b>Throws</b>: will not throw when <code>g</code> is <a href="#stateless">stateless</a>; otherwise, may throw when a copy of <code>g</code> is made.</li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p> <a name="functionN_target_ref"><code><b>template</b><<b>typename</b> F> function<i>N</i>(<a href="../../bind/ref.html">reference_wrapper</a><F> g);</code></a>
|
|
||||||
<ul>
|
|
||||||
<li><b>Requires</b>: <code>g.get()</code> is a <a href="#compatible">compatible</a> function object.</li>
|
|
||||||
<li><b>Postconditions</b>: <code>this</code> object targets <code>g</code> (<em>not</em> a copy of <code>g.get()</code>) if <code>g.get()</code> is nonempty, or <code>this->empty()</code> if <code>g.get()</code> is empty.</li>
|
|
||||||
<li><b>Throws</b>: will not throw.</li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p> <a name="functionN_copy_assn"><code>function<i>N</i><b>&</b> <b>operator</b>=(<b>const</b> function<i>N</i><b>&</b> g);</code></a>
|
|
||||||
<ul>
|
|
||||||
<li><b>Postconditions</b>: <code>f</code> targets a copy of <code>g</code>'s target, if it has one, or is empty if <code>g.<a href="#empty">empty</a>()</code>. </li>
|
|
||||||
<li><b>Returns</b>: <code>*this</code>.</li>
|
|
||||||
<li><b>Throws</b>: will not throw when the target of <code>g</code> is a <a href="#stateless">stateless</a> function object or a reference to the function object.</li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p> <a name="functionN_target_assn"><code><b>template</b><<b>typename</b> F> function<i>N</i><b>&</b> <b>operator</b>=(F g);</code></a>
|
|
||||||
<ul>
|
|
||||||
<li><b>Requires</b>: <code>g</code> is a <a href="#compatible">compatible</a> function object.</li>
|
|
||||||
<li><b>Postconditions</b>: <code>f</code> targets a copy of <code>g</code> if <code>g</code> is nonempty, or <code>f.<a href="#empty">empty</a>()</code> if <code>g</code> is empty.</li>
|
|
||||||
<li><b>Returns</b>: <code>*this</code>.</li>
|
|
||||||
<li><b>Throws</b>: will not throw when <code>g</code> is a <a href="#stateless">stateless</a> function object.</li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p> <a name="functionN_target_ref_assn"><code><b>template</b><<b>typename</b> F> function<i>N</i><b>&</b> <b>operator</b>=(<a href="../../bind/ref.html">reference_wrapper</a><F> g);</code></a>
|
|
||||||
<ul>
|
|
||||||
<li><b>Requires</b>: <code>g.get()</code> is a <a href="#compatible">compatible</a> function object.</li>
|
|
||||||
<li><b>Postconditions</b>: <code>f</code> targets <code>g.get()</code> (not a copy of <code>g.get()</code>) if <code>g.get()</code> is nonempty, or <code>f.<a href="#empty">empty</a>()</code> if <code>g.get()</code> is empty.</li>
|
|
||||||
<li><b>Returns</b>: <code>*this</code>.</li>
|
|
||||||
<li><b>Throws</b>: will throw only if the destruction or deallocation of the target of <code>this</code> throws.</li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p> <a name="functionN_swap"><code><b>void</b> swap(function<i>N</i><b>&</b> g);</code></a>
|
|
||||||
<ul>
|
|
||||||
<li><b>Effects</b>: interchanges the targets of <code>f</code> and <code>g</code>. </li>
|
|
||||||
<li><b>Throws</b>: will not throw.</li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p> <a name="functionN_clear"><code><b>void</b> clear(); </code></a>
|
|
||||||
<ul>
|
|
||||||
<li><b>Effects</b>: If <code>!<a href="#empty">empty</a>()</code>, deallocates current target.</li>
|
|
||||||
<li><b>Postconditions</b>: <code><a href="#empty">empty</a>()</code>.</li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p> <a name="bool"><code><b>operator</b> safe_bool() <b>const</b></code></a>
|
|
||||||
<ul>
|
|
||||||
<li><b>Returns</b>: <code>safe_bool</code> equivalent of <code>!<a href="#empty">empty</a>()</code></li>
|
|
||||||
<li><b>Throws</b>: will not throw.</li>
|
|
||||||
<li><b>Notes</b>: The <code>safe_bool</code> type can be used in contexts where a <b>bool</b> is expected (e.g., an <b>if</b> condition); however, implicit conversions (e.g., to <b>int</b>) that can occur with <b>bool</b> are not allowed, eliminating some sources of user error.
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p> <a name="not"><code><b>bool</b> <b>operator!</b>() <b>const</b></code></a>
|
|
||||||
<ul>
|
|
||||||
<li><b>Returns</b>: <code>this->empty()</code></li>
|
|
||||||
<li><b>Throws</b>: will not throw.</li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p> <a name="functionN_call_const"><code> result_type <b>operator</b>()(Arg1 a1, Arg2 a2, <i>...</i>, Arg<i>N</i> a<i>N</i>) <b>const</b>;</code></a>
|
|
||||||
<ul>
|
|
||||||
<li><b>Requires</b>: <code>!<a href="#empty">empty</a>()</code>.</li>
|
|
||||||
<li><b>Effects</b>: <i>target</i> is the underlying function target. It is not <code><b>const</b></code> or <code><b>volatile</b></code> qualified.
|
|
||||||
<ol>
|
|
||||||
<li><code>policy_type policy;</code></li>
|
|
||||||
<li><code>policy.precall(this);</code></li>
|
|
||||||
<li><code><i>target</i>(a1, a2, <i>...</i>, a<i>N</i>);</code></li>
|
|
||||||
<li><code>policy.postcall(this);</code></li>
|
|
||||||
</ol>
|
|
||||||
<li><b>Returns</b>: the value returned by <i>target</i>.</li>
|
|
||||||
<li><b>Note</b>: invocation policies have been deprecated and will be removed in a later release.</li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<h2><a name="function">Class template <code>function</code></a></h2>
|
|
||||||
<p> Class template <code>function</code> is a thin wrapper around the numbered class templates <code>function0</code>, <code>function1</code>, etc. It accepts up to <i>MAX_ARGS</i> arguments, but when passed <i>N</i> arguments it will derive from <code>function<i>N</i></code> specialized with the arguments it receives.
|
|
||||||
|
|
||||||
<p> The semantics of all operations in class template <code>function</code> are equivalent to that of the underlying <code>function<i>N</i></code> object, although additional member functions are required to allow proper copy construction and copy assignment of <code>function</code> objects.
|
|
||||||
|
|
||||||
<h2><a name="operations">Operations</a></h2>
|
|
||||||
<p>
|
|
||||||
<pre>
|
|
||||||
<b>template</b><<b>typename</b> ResultType,
|
|
||||||
<b>typename</b> Arg1,
|
|
||||||
<b>typename</b> Arg2,
|
|
||||||
<i>...</i>
|
|
||||||
<b>typename</b> Arg<i>N</i>,
|
|
||||||
<b>typename</b> Allocator>
|
|
||||||
<b>void</b> <a name="swap_functionN">swap</a>(function<i>N</i><ResultType, Arg1, Arg2, <i>...</i>, Arg<i>N</i>, Allocator><b>&</b> f,
|
|
||||||
function<i>N</i><ResultType, Arg1, Arg2, <i>...</i>, Arg<i>N</i>, Allocator><b>&</b> g);
|
|
||||||
</pre>
|
|
||||||
<ul>
|
|
||||||
<li><b>Effects</b>: <code>f.<a href="#functionN_swap">swap</a>(g);</code></li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p>
|
|
||||||
<pre>
|
|
||||||
<b>template</b><<b>typename</b> Signature, <b>typename</b> Allocator>
|
|
||||||
<b>void</b> <a name="swap_function">swap</a>(function<Signature, Allocator><b>&</b> f,
|
|
||||||
function<Signature, Allocator><b>&</b> g);
|
|
||||||
</pre>
|
|
||||||
<ul>
|
|
||||||
<li><b>Effects</b>: <code>f.<a href="#functionN_swap">swap</a>(g);</code></li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<hr>
|
|
||||||
<p><a name="novoid">[1]</a> On compilers not supporting void returns, when the <code>ReturnType</code> is <b>void</b>, the <code>result_type</code> of a Boost.Function object is implementation-defined.
|
|
||||||
<hr>
|
|
||||||
<address><a href="mailto:gregod@cs.rpi.edu">Douglas Gregor</a></address>
|
|
||||||
<!-- Created: Fri Jul 13 10:57:20 EDT 2001 -->
|
|
||||||
<!-- hhmts start -->
|
|
||||||
Last modified: Fri Sep 6 14:46:50 EDT 2002
|
|
||||||
<!-- hhmts end -->
|
|
||||||
</body>
|
|
||||||
</html>
|
|
||||||
@ -1,258 +0,0 @@
|
|||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
||||||
<html>
|
|
||||||
<head>
|
|
||||||
<title>Boost.Function Tutorial</title>
|
|
||||||
</head>
|
|
||||||
|
|
||||||
<body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080">
|
|
||||||
|
|
||||||
<h1><IMG SRC="../../../c++boost.gif" WIDTH="276" HEIGHT="86">Boost.Function Tutorial</h1>
|
|
||||||
|
|
||||||
<p> Boost.Function has two syntactical forms: the preferred form and the compatibility form. The preferred form fits more closely with the C++ language and reduces the number of separate template parameters that need to be considered, often improving readability; however, the preferred form is not supported on all platforms due to compiler bugs. The compatible form will work on all compilers supported by Boost.Function. Consult the table below to determine which syntactic form to use for your compiler.
|
|
||||||
|
|
||||||
<center>
|
|
||||||
<table border=1 cellspacing=1>
|
|
||||||
<tr><th bgcolor="#008080">Preferred Syntax</th><th bgcolor="#008080">Compatible Syntax</th></tr>
|
|
||||||
<tr>
|
|
||||||
<td>
|
|
||||||
<ul>
|
|
||||||
<li>GNU C++ 2.95.x, 3.0.x, 3.1.x</li>
|
|
||||||
<li>Comeau C++ 4.2.45.2</li>
|
|
||||||
<li>SGI MIPSpro 7.3.0</li>
|
|
||||||
<li>Intel C++ 5.0, 6.0</li>
|
|
||||||
<li>Compaq's cxx 6.2</li>
|
|
||||||
</ul>
|
|
||||||
</td>
|
|
||||||
<td>
|
|
||||||
<ul>
|
|
||||||
<li>Microsoft Visual C++ 6.0, 7.0</li>
|
|
||||||
<li>Borland C++ 5.5.1</li>
|
|
||||||
<li>Sun WorkShop 6 update 2 C++ 5.3</li>
|
|
||||||
<li>Metrowerks CodeWarrior 8.1</li>
|
|
||||||
</ul>
|
|
||||||
</td>
|
|
||||||
</tr>
|
|
||||||
</table>
|
|
||||||
</center>
|
|
||||||
|
|
||||||
<p> If your compiler does not appear in this list, please try the preferred syntax and report your results to the Boost list so that we can keep this table up-to-date.
|
|
||||||
|
|
||||||
<a name="preferred"><h2>Basic Usage</h2></a>
|
|
||||||
<p> A function wrapper is defined simply by instantiating the <code>function</code> class template with the desired return type and argument types, formulated as a C++ function type. Any number of arguments may be supplied, up to some implementation-defined limit (10 is the default maximum). The following declares a function object wrapper <code>f</code> that takes two <code>int</code> parameters and returns a <code>float</code>:
|
|
||||||
<center>
|
|
||||||
<table border=1 cellspacing=1>
|
|
||||||
<tr><th bgcolor="#008080">Preferred Syntax</th><th bgcolor="#008080">Compatible Syntax</th></tr>
|
|
||||||
<tr>
|
|
||||||
<td>
|
|
||||||
<pre>
|
|
||||||
boost::<a href="reference.html#function">function</a><float (int x, int y)> f;
|
|
||||||
</pre>
|
|
||||||
</td>
|
|
||||||
<td>
|
|
||||||
<pre>
|
|
||||||
boost::<a href="reference.html#functionN">function2</a><float, int, int> f;
|
|
||||||
</pre>
|
|
||||||
</td>
|
|
||||||
</tr>
|
|
||||||
</table>
|
|
||||||
</center>
|
|
||||||
|
|
||||||
<p> By default, function object wrappers are empty, so we can create a
|
|
||||||
function object to assign to <code>f</code>:
|
|
||||||
|
|
||||||
<pre>
|
|
||||||
struct int_div {
|
|
||||||
float operator()(int x, int y) const { return ((float)x)/y; };
|
|
||||||
};
|
|
||||||
|
|
||||||
f = int_div();
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
<p> Now we can use <code>f</code> to execute the underlying function object
|
|
||||||
<code>int_div</code>:
|
|
||||||
<pre>
|
|
||||||
std::cout << f(5, 3) << std::endl;
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
<p> We are free to assign any compatible function object to <code>f</code>. If <code>int_div</code> had been declared to take two <code>long</code> operands,
|
|
||||||
the implicit conversions would have been applied to the arguments without any user interference. The only limit on the types of arguments is that they be CopyConstructible, so we can even use references and arrays:
|
|
||||||
<center>
|
|
||||||
<table border=1 cellspacing=1>
|
|
||||||
<tr><th bgcolor="#008080">Preferred Syntax</th><th bgcolor="#008080">Compatible Syntax</th></tr>
|
|
||||||
<tr>
|
|
||||||
<td>
|
|
||||||
<pre>
|
|
||||||
boost::function<void (int values[], int n, int& sum, float& avg)> sum_avg;
|
|
||||||
</pre>
|
|
||||||
</td>
|
|
||||||
<td>
|
|
||||||
<pre>
|
|
||||||
boost::function4<void, int[], int, int&, float> sum_avg;
|
|
||||||
</pre>
|
|
||||||
</td>
|
|
||||||
</tr>
|
|
||||||
</table>
|
|
||||||
</center>
|
|
||||||
|
|
||||||
<pre>
|
|
||||||
void do_sum_avg(int values[], int n, int& sum, float& avg)
|
|
||||||
{
|
|
||||||
sum = 0;
|
|
||||||
for (int i = 0; i < n; i++)
|
|
||||||
sum += values[i];
|
|
||||||
avg = (float)sum / n;
|
|
||||||
}
|
|
||||||
|
|
||||||
sum_avg = &do_sum_avg;
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
<p> Invoking a function object wrapper that does not actually contain a function object is a precondition violation, much like trying to call through a null function pointer. We can check for an empty function object wrapper by querying its <code><a href="reference.html#empty">empty</a>()</code> method or, more succinctly, by using it in a boolean context: if it evaluates true, it contains a function object target, i.e.,
|
|
||||||
<pre>
|
|
||||||
if (f)
|
|
||||||
std::cout << f(5, 3) << std::endl;
|
|
||||||
else
|
|
||||||
std::cout << "f has no target, so it is unsafe to call" << std::endl;
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
<p> We can clear out a function target using the <code><a href="reference.html#functionN_clear">clear</a>()</code> member function.
|
|
||||||
|
|
||||||
<h3>Free functions</h3>
|
|
||||||
<p> Free function pointers can be considered singleton function objects with const function call operators, and can therefore be directly used with the function object wrappers:
|
|
||||||
<pre>
|
|
||||||
float mul_ints(int x, int y) { return ((float)x) * y; }
|
|
||||||
f = &mul_ints;
|
|
||||||
</pre>
|
|
||||||
|
|
||||||
<p> Note that the <code>&</code> isn't really necessary unless you happen to be using Microsoft Visual C++ version 6.
|
|
||||||
|
|
||||||
<h3>Member functions</h3>
|
|
||||||
<a name="member_func">
|
|
||||||
<p> In many systems, callbacks often call to member functions of a particular
|
|
||||||
object. This is often referred to as "argument binding", and is beyond the scope of Boost.Function. The use of member functions directly, however, is supported, so the following code is valid:
|
|
||||||
|
|
||||||
<center>
|
|
||||||
<table border=1 cellspacing=1>
|
|
||||||
<tr><th bgcolor="#008080">Preferred Syntax</th><th bgcolor="#008080">Compatible Syntax</th></tr>
|
|
||||||
<tr>
|
|
||||||
<td>
|
|
||||||
<pre>
|
|
||||||
struct X {
|
|
||||||
int foo(int);
|
|
||||||
};
|
|
||||||
|
|
||||||
boost::function<int (X*, int)> f;
|
|
||||||
|
|
||||||
f = &X::foo;
|
|
||||||
|
|
||||||
X x;
|
|
||||||
f(&x, 5);
|
|
||||||
</pre>
|
|
||||||
</td>
|
|
||||||
<td>
|
|
||||||
<pre>
|
|
||||||
struct X {
|
|
||||||
int foo(int);
|
|
||||||
};
|
|
||||||
|
|
||||||
boost::function2<int, X*, int> f;
|
|
||||||
|
|
||||||
f = &X::foo;
|
|
||||||
|
|
||||||
X x;
|
|
||||||
f(&x, 5);
|
|
||||||
</pre>
|
|
||||||
</td>
|
|
||||||
</tr>
|
|
||||||
</table>
|
|
||||||
</center>
|
|
||||||
|
|
||||||
<p> Several libraries exist that support argument binding. Three such libraries are summarized below:
|
|
||||||
<ul>
|
|
||||||
<li> <a href="../../bind/bind.html">Boost.Bind</a>. This library allows binding of arguments for any function object. It is lightweight and very portable.</li>
|
|
||||||
|
|
||||||
<li> The C++ Standard library. Using <code>std::bind1st</code> and <code>std::mem_fun</code> together one can bind the object of a pointer-to-member function for use with Boost.Function:
|
|
||||||
<center>
|
|
||||||
<table border=1 cellspacing=1>
|
|
||||||
<tr><th bgcolor="#008080">Preferred Syntax</th><th bgcolor="#008080">Compatible Syntax</th></tr>
|
|
||||||
<tr>
|
|
||||||
<td>
|
|
||||||
<pre>
|
|
||||||
struct X {
|
|
||||||
int foo(int);
|
|
||||||
};
|
|
||||||
|
|
||||||
boost::function<int (int)> f;
|
|
||||||
X x;
|
|
||||||
f = std::bind1st(std::mem_fun(&X::foo), &x);
|
|
||||||
|
|
||||||
f(5); // Call x.foo(5)</pre>
|
|
||||||
</td>
|
|
||||||
<td>
|
|
||||||
<pre>
|
|
||||||
struct X {
|
|
||||||
int foo(int);
|
|
||||||
};
|
|
||||||
|
|
||||||
boost::function1<int, int> f;
|
|
||||||
X x;
|
|
||||||
f = std::bind1st(std::mem_fun(&X::foo), &x);
|
|
||||||
|
|
||||||
f(5); // Call x.foo(5)</pre>
|
|
||||||
</td>
|
|
||||||
</tr>
|
|
||||||
</table>
|
|
||||||
</center>
|
|
||||||
</li>
|
|
||||||
|
|
||||||
<li><a href="../../lambda/doc/index.html">The Boost.Lambda library</a>. This library provides a powerful composition mechanism to construct function objects that uses very natural C++ syntax. Lambda requires a compiler that is reasonably conformant to the C++ standard. </li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<h3>References to Functions</h3>
|
|
||||||
<p> In some cases it is expensive (or semantically incorrect) to have
|
|
||||||
Boost.Function clone a function object. In such cases, it is possible
|
|
||||||
to request that Boost.Function keep only a reference to the actual
|
|
||||||
function object. This is done using the <a
|
|
||||||
href="../../bind/ref.html"><code>ref</code></a> and <a
|
|
||||||
href="../../bind/ref.html"><code>cref</code></a> functions to wrap a
|
|
||||||
reference to a function object:
|
|
||||||
<center>
|
|
||||||
<table border=1 cellspacing=1>
|
|
||||||
<tr><th bgcolor="#008080">Preferred Syntax</th><th bgcolor="#008080">Compatible Syntax</th></tr>
|
|
||||||
<tr>
|
|
||||||
<td>
|
|
||||||
<pre>
|
|
||||||
stateful_type a_function_object;
|
|
||||||
boost::function<int (int)> f;
|
|
||||||
f = ref(a_function_object);
|
|
||||||
|
|
||||||
boost::function<int (int)> f2(f);
|
|
||||||
</pre>
|
|
||||||
</td>
|
|
||||||
<td>
|
|
||||||
<pre>
|
|
||||||
stateful_type a_function_object;
|
|
||||||
boost::function1<int, int> f;
|
|
||||||
f = ref(a_function_object);
|
|
||||||
|
|
||||||
boost::function1<int, int> f2(f);
|
|
||||||
</pre>
|
|
||||||
</td>
|
|
||||||
</tr>
|
|
||||||
</table>
|
|
||||||
</center>
|
|
||||||
|
|
||||||
Here, <code>f</code> will not make a copy of
|
|
||||||
<code>a_function_object</code>, nor will <code>f2</code> when it is
|
|
||||||
targeted to <code>f</code>'s reference to
|
|
||||||
<code>a_function_object</code>. Additionally, when using references to
|
|
||||||
function objects, Boost.Function will not throw exceptions during
|
|
||||||
assignment or construction.
|
|
||||||
|
|
||||||
<hr>
|
|
||||||
<address><a href="mailto:gregod@cs.rpi.edu">Douglas Gregor</a></address>
|
|
||||||
<!-- Created: Fri Jul 13 12:47:11 EDT 2001 -->
|
|
||||||
<!-- hhmts start -->
|
|
||||||
Last modified: Wed Jan 29 08:49:02 EST 2003
|
|
||||||
<!-- hhmts end -->
|
|
||||||
</body>
|
|
||||||
</html>
|
|
||||||
142
index.html
142
index.html
@ -1,137 +1,9 @@
|
|||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
|
||||||
<html>
|
<html>
|
||||||
<head>
|
<head>
|
||||||
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
<meta http-equiv="refresh" content="0; URL=../../doc/html/function.html">
|
||||||
<link rel="stylesheet" type="text/css" href="../../boost.css">
|
</head>
|
||||||
<title>Boost.Function</title>
|
<body>
|
||||||
</head>
|
Automatic redirection failed, please go to
|
||||||
|
<a href="../../doc/html/function.html">../../doc/html/function.html</a>
|
||||||
<body>
|
</body>
|
||||||
|
|
||||||
<h1><img src="../../c++boost.gif" width="276" height="86" alt="C++ Boost">Header <<a HREF="../../boost/function.hpp">boost/function.hpp</a>></h1>
|
|
||||||
|
|
||||||
<p> The header <<a HREF="../../boost/function.hpp">boost/function.hpp</a>> includes a family of class templates that are function object wrappers. The notion is similar to a generalized callback. It shares features with function pointers in that both define a call interface (e.g., a function taking two integer arguments and returning a floating-point value) through which some implementation can be called, and the implementation that is invoked may change throughout the course of the program.
|
|
||||||
|
|
||||||
<p> Generally, any place in which a function pointer would be used to defer a call or make a callback, Boost.Function can be used instead to allow the user greater flexibility in the implementation of the target. Targets can be any 'compatible' function object (or function pointer), meaning that the arguments to the interface designated by Boost.Function can be converted to the arguments of the target function object.
|
|
||||||
|
|
||||||
<ul>
|
|
||||||
<li><a href="#compatibility">Compatibility Note</a></li>
|
|
||||||
<li><a href="doc/tutorial.html">Tutorial</a></li>
|
|
||||||
<li><a href="doc/reference.html">Reference manual</a></li>
|
|
||||||
<li><a href="#vspointers">Boost.Function vs. Function Pointers</a></li>
|
|
||||||
<li><a href="#performance">Performance</a></li>
|
|
||||||
<li><a href="#portability">Portability</a></li>
|
|
||||||
<li><a href="#design">Design rationale</a></li>
|
|
||||||
<li><a href="#acknowledgements">Acknowledgements</a></li>
|
|
||||||
<li><a href="doc/faq.html">Frequently Asked Questions</a></li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<h2><a name="compatibility">Compatibility Note</a></h2>
|
|
||||||
<p> <b>Version 1.30.0</b>: All deprecated features have been removed
|
|
||||||
from Boost.Function.
|
|
||||||
|
|
||||||
<p> <b>Version 1.29.0</b>: Boost.Function has been partially redesigned to minimize the interface and make it cleaner. Several seldom- or never-used features of the older Boost.Function have been deprecated and will be removed in the near future. Here is a list of features that have been deprecated, the likely impact of the deprecations, and how to adjust your code:
|
|
||||||
<ul>
|
|
||||||
<li>The <code>boost::function</code> class template syntax has
|
|
||||||
changed. The old syntax, e.g., <code>boost::function<int, float,
|
|
||||||
double, std::string></code>, has been changed to a more natural
|
|
||||||
syntax <code>boost::function<int (float, double,
|
|
||||||
std::string)></code>, where all return and argument types are
|
|
||||||
encoded in a single function type parameter. Any other template
|
|
||||||
parameters (e.g., the <code>Allocator</code>) follow this single
|
|
||||||
parameter.
|
|
||||||
|
|
||||||
<p> The resolution to this change depends on the
|
|
||||||
abilities of your compiler: if your compiler supports template
|
|
||||||
partial specialization and can parse function types (most do), modify
|
|
||||||
your code to use the newer
|
|
||||||
syntax (preferable) or directly use one of the
|
|
||||||
<code>function<em>N</em></code> classes whose syntax has not
|
|
||||||
changed. If your compiler does not support template partial
|
|
||||||
specialization or function types, you must take the latter option and
|
|
||||||
use the numbered Boost.Function classes. This option merely requires
|
|
||||||
changing types such as <code>boost::function<void, int, int></code>
|
|
||||||
to <code>boost::function2<void, int, int></code> (adding the number of
|
|
||||||
function arguments to the end of the class name).
|
|
||||||
|
|
||||||
<p> Support for the old syntax with the
|
|
||||||
<code>boost::function</code> class template will persist for a short
|
|
||||||
while, but will eventually be removed so that we can provide better
|
|
||||||
error messages and link compatibility. </li>
|
|
||||||
|
|
||||||
<li>The invocation
|
|
||||||
policy template parameter (<code>Policy</code>) has been deprecated
|
|
||||||
and will be removed. There is no direct equivalent to this rarely
|
|
||||||
used feature.</li> <li>The mixin template parameter
|
|
||||||
(<code>Mixin</code>) has been deprecated and will be removed. There
|
|
||||||
is not direct equivalent to this rarely used feature.</li> <li>The
|
|
||||||
<code>set</code> methods have been deprecated and will be
|
|
||||||
removed. Use the assignment operator instead.</li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p> To aid in porting to the new syntax and removing the use of deprecated features, define the preprocessor macro <code>BOOST_FUNCTION_NO_DEPRECATED</code>. This macro makes all deprecated features unavailable. A program compiled with <code>BOOST_FUNCTION_NO_DEPRECATED</code> will likely be prepared when the deprecated features are removed.
|
|
||||||
|
|
||||||
<h2><a name="vspointers">Boost.Function vs. Function Pointers</a></h2>
|
|
||||||
<p>Boost.Function has several advantages over function pointers, namely:
|
|
||||||
|
|
||||||
<ul>
|
|
||||||
<li>Boost.Function allows arbitrary compatible function objects to be targets (instead of requiring an exact function signature).</li>
|
|
||||||
<li>Boost.Function may be used with argument-binding and other function object construction libraries.</li>
|
|
||||||
<li>Boost.Function has predictible debug behavior when an empty function object is called. </li>
|
|
||||||
<li>Boost.Function can be adapted to perform operations before and after each call, allowing, for instance, synchronization primitives to be made part of the function type.</li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p> And, of course, function pointers have several advantages over Boost.Function:
|
|
||||||
|
|
||||||
<ul>
|
|
||||||
<li> Function pointers are smaller (the size of one pointer instead of three) </li>
|
|
||||||
<li> Function pointers are faster (Boost.Function may require two calls through function pointers) </li>
|
|
||||||
<li> Function pointers are backward-compatible with C libraries.</li>
|
|
||||||
<li> More readable error messages. </li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
|
|
||||||
<p> The above two lists were adapted from comments made by Darin Adler.
|
|
||||||
|
|
||||||
<h2><a name="performance">Performance</a></h2>
|
|
||||||
<h3>Function object wrapper size</h3>
|
|
||||||
<p> Function object wrappers will be the size of two function pointers plus one function pointer or data pointer (whichever is larger). On common 32-bit platforms, this amounts to 12 bytes per wrapper. Additionally, the function object target will be allocated on the heap.
|
|
||||||
|
|
||||||
<h3>Copying efficiency</h3>
|
|
||||||
<p> Copying function object wrappers may require allocating memory for a copy of the function object target. The default allocator may be replaced with a faster custom allocator or one may choose to allow the function object wrappers to only store function object targets by reference (using <a href="../bind/ref.html"><code>ref</code></a>) if the cost of this cloning becomes prohibitive.
|
|
||||||
|
|
||||||
<h3>Invocation efficiency</h3>
|
|
||||||
<p> With a properly inlining compiler, an invocation of a function object requires one call through a function pointer. If the call is to a free function pointer, an additional call must be made to that function pointer (unless the compiler has very powerful interprocedural analysis).
|
|
||||||
|
|
||||||
<h2><a name="portability">Portability</a></h2>
|
|
||||||
<p> The function object wrappers have been designed to be as portable as possible, and to support many compilers even when they do not support the C++ standard well. The following compilers have passed all of the test cases included with <code>boost::function</code>.
|
|
||||||
<ul>
|
|
||||||
<li>GCC 2.95.3</li>
|
|
||||||
<li>GCC 3.0</li>
|
|
||||||
<li>SGI MIPSpro 7.3.0</li>
|
|
||||||
<li>Borland C++ 5.5.1</li>
|
|
||||||
<li>Comeau C++ 4.2.45.2</li>
|
|
||||||
<li>Metrowerks Codewarrior 6.1</li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p> The following compilers work with <code>boost::function</code>, but have some problems:
|
|
||||||
<ul>
|
|
||||||
<li>Microsoft Visual C++ 6.0 (service pack 5): allocators not supported, some problems with <code>boost::function</code> class template (numbered variants seem to work)</li>
|
|
||||||
<li>Intel C++ 5.0: allocators not supported</li>
|
|
||||||
</ul>
|
|
||||||
|
|
||||||
<p> If your compiler is not listed, there is a small set of tests to stress the capabilities of the <code>boost::function</code> library. A standards-compliant compiler should compile the code without any modifications, but if you find you run into problems please submit a bug report.
|
|
||||||
|
|
||||||
<h2><a name="design">Design rationale</a></h2>
|
|
||||||
<h3>Combatting virtual function bloat</h3>
|
|
||||||
<p> The use of virtual functions tends to cause 'code bloat' on many compilers. When a class contains a virtual function, it is necessary to emit an additional function that classifies the type of the object. It has been our experience that these auxiliary functions increase the size of the executable significantly when many <code>boost::function</code> objects are used.
|
|
||||||
|
|
||||||
<p> In Boost.Function, an alternative but equivalent approach was taken using free functions instead of virtual functions. The Boost.Function object essentially holds two pointers to make a valid target call: a void pointer to the function object it contains and a void pointer to an "invoker" that can call the function object, given the function pointer. This invoker function performs the argument and return value conversions Boost.Function provides. A third pointer points to a free function called the "manager", which handles the cloning and destruction of function objects. The scheme is typesafe because the only functions that actually handle the function object, the invoker and the manager, are instantiated given the type of the function object, so they can safely cast the incoming void pointer (the function object pointer) to the appropriate type.
|
|
||||||
|
|
||||||
<h2><a name="acknowledgements">Acknowledgements</a></h2>
|
|
||||||
<p> Many people were involved in the construction of this library. William Kempf, Jesse Jones and Karl Nelson were all extremely helpful in isolating an interface and scope for the library. John Maddock managed the formal review, and many reviewers gave excellent comments on interface, implementation, and documentation.
|
|
||||||
|
|
||||||
<hr>
|
|
||||||
<address><a href="mailto:gregod@cs.rpi.edu">Doug Gregor</a></address>
|
|
||||||
</body>
|
|
||||||
</html>
|
</html>
|
||||||
|
|||||||
Reference in New Issue
Block a user