forked from boostorg/function
d37903b2e7
- Removed reference and tutorial: now just link to them faq.html: - Moved to doc/faq.html doc/faq.html: - Relative directory fixups doc/reference.html: - Reference manual for Boost.Function doc/tutorial.html: - Tutorial for Boost.Function (the old "Usage" sections) - Additional example showing the use of references and arrays example/bind1st.cpp: example/int_div.cpp: example/sum_avg.cpp: - Examples from tutorial [SVN r10620]
47 lines
3.0 KiB
HTML
47 lines
3.0 KiB
HTML
<!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.
|
|
|
|
<h2>Q: How do I assign from a member function?</h2>
|
|
<p> Member function assignments are not included directly in <code>boost::function</code> because they do not conform to the syntax of function objects. Several libraries exist to wrap member functions in a function object and/or bind the first argument to the member function (the <code>this</code> pointer). A few libraries are <a href="tutorial.html#member_func">described</a> in the <a href="../index.html">Boost.Function</a> documentation.
|
|
|
|
<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: Sat Jul 14 16:00:11 EDT 2001
|
|
<!-- hhmts end -->
|
|
</body>
|
|
</html> |