mergme

[SVN r53280]
Improve documentation on the size/efficiency of boost::function objects
2009-05-26 14:05:46 +00:00 · 2008-04-28 14:11:46 +00:00 · 2008-04-17 15:49:39 +00:00 · 2008-04-04 12:26:53 +00:00 · 2008-03-27 19:44:37 +00:00 · 2007-12-06 18:39:06 +00:00
2 changed files with 5 additions and 4 deletions
@@ -24,7 +24,7 @@
 <para> And, of course, function pointers have several advantages over Boost.Function:

 <itemizedlist spacing="compact">
-    <listitem><para> Function pointers are smaller (the size of one pointer instead of three) </para></listitem>
+    <listitem><para> Function pointers are smaller (the size of one pointer instead of four or more) </para></listitem>
    <listitem><para> Function pointers are faster (Boost.Function may require two calls through function pointers) </para></listitem>
    <listitem><para> Function pointers are backward-compatible with C libraries.</para></listitem>
    <listitem><para> More readable error messages. </para></listitem>
@@ -37,12 +37,12 @@

 <section>
  <title>Function object wrapper size</title>
-<para> 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.</para>
+  <para> Function object wrappers will be the size of a struct containing a member function pointer and two data pointers. The actual size can vary significantly depending on the underlying platform; on 32-bit Mac OS X with GCC, this amounts to 16 bytes, while it is 32 bytes Windows with Visual C++. Additionally, the function object target may be allocated on the heap, if it cannot be placed into the small-object buffer in the <code>boost::function</code> object.</para>
 </section>

 <section>
  <title>Copying efficiency</title>
-<para> 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 <computeroutput>ref</computeroutput>) if the cost of this cloning becomes prohibitive.</para>
+  <para> 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 <computeroutput>ref</computeroutput>) if the cost of this cloning becomes prohibitive. Small function objects can be stored within the <code>boost::function</code> object itself, improving copying efficiency.</para>
 </section>

 <section>
@@ -11,7 +11,7 @@
 #define BOOST_FUNCTION_PROLOGUE_HPP
 #  include <cassert>
 #  include <algorithm>
-#  include <functional> // unary_function, binary_function
+#  include <boost/config/no_tr1/functional.hpp> // unary_function, binary_function
 #  include <boost/throw_exception.hpp>
 #  include <boost/config.hpp>
 #  include <boost/function/function_base.hpp>
@@ -22,4 +22,5 @@
 #  include <boost/preprocessor/cat.hpp>
 #  include <boost/preprocessor/repeat.hpp>
 #  include <boost/preprocessor/inc.hpp>
+#  include <boost/type_traits/is_void.hpp>
 #endif // BOOST_FUNCTION_PROLOGUE_HPP
Author	SHA1	Message	Date
Troy D. Straszheim	fc8fdac0fd	mergme [SVN r53280]	2009-05-26 14:05:46 +00:00
Douglas Gregor	04040ae566	Improve documentation on the size/efficiency of boost::function objects [SVN r44852]	2008-04-28 14:11:46 +00:00
John Maddock	fe2d04e954	Change <functional> include so that it still works when Boost.TR1 is in the include path. [SVN r44506]	2008-04-17 15:49:39 +00:00
Douglas Gregor	0936dbdd03	Add missing include for is_void [SVN r44030]	2008-04-04 12:26:53 +00:00
Douglas Gregor	adb7b0a214	Change Boost.Function allocator behavior, from Emil Dotchevski [SVN r43884]	2008-03-27 19:44:37 +00:00
Douglas Gregor	cead36cd5b	Disable more Visual C++ warnings in Function headers. Fixes #1416 [SVN r41798]	2007-12-06 18:39:06 +00:00
Douglas Gregor	81e558491b	Merge lots of copyrights [SVN r40811]	2007-11-05 21:22:29 +00:00
John Maddock	2378ba59e7	Fix for Borland compilers. [SVN r39657]	2007-10-02 17:41:35 +00:00
Douglas Gregor	53b95c386d	Finalizes the fix to Bug #1260 , making vtable_base an actual POD type (oops) and playing more nicely with reinterpret_cast (thanks to Brad King for the fixes). [SVN r39285]	2007-09-14 21:05:46 +00:00
Douglas Gregor	3312c7ffcd	function_template.hpp: - Pass-by-reference internally, when we can. Fixes #1067 [SVN r39244]	2007-09-13 19:06:53 +00:00
Douglas Gregor	de27ae9697	function/function_base.hpp, function/function_template.hpp: - Switch from dynamic initialization of the vtable pointer to static initialization (Fixes #1260) - Handle member pointers properly, only using mem_fn within the invoker to deal with all of the messy bits of calling member pointers [SVN r39240]	2007-09-13 17:38:58 +00:00
Douglas Gregor	a7b9940f15	Handle GCC's -fno-exceptions properly. Fixes #1198 [SVN r39061]	2007-08-29 19:06:11 +00:00
Douglas Gregor	e4f165a4e8	Disable MSVC warning about native code generation. Fixes #1163 [SVN r39060]	2007-08-29 18:59:16 +00:00
Douglas Gregor	80a3f47099	Committed patch to eliminate warnings with GCC's -Wundef. Fixes #1197 [SVN r38827]	2007-08-21 15:35:19 +00:00