Header <boost/function.hpp>Header <boost/function.hpp>The header <boost/function.hpp> 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.
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.
function family A wrapper is defined simply by specializing a function object with the desired return type and argument types. 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 f that takes two int parameters and returns a float:
boost::function<float, int, int> f;
By default, function object wrappers are empty, so we can create a
function object to assign to f:
struct int_div { float operator()(int x, int y) const { return ((float)x)/y; }; };
f = int_div();
Now we can use f to execute the underlying function object
int_div:
std::cout << f(5, 3) << std::endl;
We are free to assign any compatible function object to f. If int_div had been declared to take two long operands,
the implicit conversions would have been applied without any user interference.
Invoking a function object wrapper that does not actually contain a function object is a precondition violation. We can check for an empty function object wrapper by querying its empty() method or, more succinctly, by using it in a boolean context: if it evaluates true, it contains a function object target, i.e.,
if (f)
std::cout << f(5, 3) << std::endl;
else
std::cout << "f has no target" << std::endl;
We can clear out a function target using the clear() member functor.
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:
float mul_ints(int x, int y) { return ((float)x) * y; }
f = &mul_ints;
In many systems, callbacks often call to member functions of a particular object. Handling argument binding is beyond the scope of Boost.Function. However, there are several libraries that perform 'argument binding', including
std::bind1st and std::mem_fun together one can bind the object of a pointer-to-member function for use with Boost.Function:
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)function family The header <boost/function.hpp> defines the primary entry point to the function object wrappers, the class template boost::function. This class template is essentially a thin wrapper around a set of similar numbered function object wrappers, boost::function0, boost::function1, etc., where the number indicates the number of arguments passed to the function object target. The declaration of f above could also be written as:
boost::function2<float, int, int> f;
The numbered class templates contain most of the implementation and are each distinct class templates. They may be helpful if used in shared libraries, where the number of arguments supported by Boost.Function may change between revisions. Additionally, some compilers (e.g., Microsoft Visual C++ 6.0) have been known to be incapable of compiling boost::function in some instances but are able to handle the numbered variants.
Each function object wrapper type (that has N actual arguments) supports the following operations:
| Syntax | Semantics |
|---|---|
f = func_obj; f.set(func_obj); |
Clears out f's current target and retargets f to a copy of func_obj. |
f.clear(); |
Removes f's target, if it has one. |
(bool)f !f.empty() |
The conversion to bool evaluates true if a target exists, whereas empty() returns true if no target exists. |
f(a1, a2, ..., aN) |
Invoke f's current target with the given arguments.
|
swap(f1, f2); f1.swap(f2); |
Swap the targets of f1 and f2, which must be of the same type. No exceptions will be thrown.
|
Additionally, function object wrappers may be default-constructed (as empty) or constructed from any compatible function object. They are copy constructible and copy-assignable.
All function object wrappers derive from boost::function_base, which implements the empty() member function and the bool conversion. Additionally, no other class may inherit boost::function_base, so user code may rely on the implicit base pointer conversion to determine if a type is a boost::function type or one of its variants.
The boost::function family supports additional customization by means of policies, mixins, and allocators. The specific usage of each of these will be explained in later sections, but they share a common problem: how to replace each default with your own version.
For the numbered function object wrappers, one need only specify the new classes as a template parameter in the appropriate position. The following is a general definition for each of the numbered function object wrappers:
template<typename Return,
typename Arg1,
typename Arg2,
...
typename ArgN,
typename Policy = empty_function_policy,
typename Mixin = empty_function_mixin,
typename Allocator = std::allocator<function_base>
> class functionN { /* ... */ };
With boost::function it is not so clear, because support for an arbitrary number of parameters means that it is impossible to specify just the last parameter, but not 5 of the parameters in between. Therefore, boost::function doubles as a generative interface for the underlying numbered class templates that uses named template parameters. For instance, to specify both a policy and an allocator for a function object wrapper f taking an int and returning an int, use:
function<int, int>::policy<MyPolicy>::allocator<MyAllocator>::type f;
The named template parameters policy, mixin and allocator each take one template parameter (the replacement class) and may be nested as above to generate a function object wrapper. The ::type at the end accesses the actual type that fits the given properties.
Policies define what happens directly before and directly after an invocation of a function object target is made. A policy must have two member functions, precall and postcall, each of which must be able to accept a const function object wrapper pointer. The following policy will print "before" prior to execution and "after" afterwards:
struct print_policy {
void precall(const boost::function_base*) { std::cout << "before"; }
void postcall(const boost::function_base*) { std::cout << "after"; }
};
A new instance of the policy class will be created prior to calling the function object target and will be preserved until after the call has returned. Therefore, for any invocation the precall and postcall will be executed on the same policy class instance; however, policy class instances will not be kept between target invocations.
Policies are further described in the Boost discussion on generic programming techniques.
The function object wrappers allow any class to be "mixed in" as a base class. This allows extra members and/or functionality to be included by the user. This can be used, for instance, to overcome the limitations of policies by storing data between invocations in a base class instead of in a static member of a policy class.
The function object wrappers allow the user to specify a new allocator to handle the cloning of function object targets (when the wrappers are copied). The allocators used are the same as the C++ standard library allocators. The wrappers assume the allocators are stateless, and will create a new instance each time they are used (because they are rebound very often). This shares the semantics of most standard library implementations, and is explicitly allowed by the C++ standard.
Synchronization of callbacks in a multithreaded environment is extremely important. Using mixins and policies, a Boost.Function object may implement its own synchronization policy that ensures that only one thread can be in the callback function at any given point in time.
We will use the prototype Boost.Threads library for its recursive_mutex. Since the mutex is on a per-callback basis, we will add a mutex to the boost::function by mixin it in with this mixin class:
class SynchronizedMixin {
mutable boost::recursive_mutex mutex;
};
Next, we create a policy that obtains a lock before the target is called (via the precall function) and releases the lock after the target has been called (via the postcall function):
class SynchronizedPolicy {
std::auto_ptr<boost::recursive_mutex::lock> lock;
void precall(const SynchronizedMixin* f)
{
lock.reset(new boost::recursive_mutex::lock(f->mutex));
}
void postcall(const SynchronizedMixin* f)
{
lock.reset();
}
};
The use of std::auto_ptr ensures that the lock will be destroyed (and therefore released) if an exception is thrown by the target function. Now we can use the policy and mixin together to create a synchronized callback:
boost::function2<float, int, int, SynchronizedPolicy, SynchronizedMixin> f;
Boost.Function has several advantages over function pointers, namely:
The above two lists were adapted from comments made by Darin Adler.
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.
Copying function object wrappers requires allocating member for a copy of the function object target. The default allocator may be replaced with a faster custom allocator if the cost of this cloning becomes prohibitive.
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).
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 testcases included with boost::function.
The following compilers work with boost::function, but have some problems:
boost::function class template (numbered variants seem to work) If your compiler is not listed, there is a small set of tests to stress the capabilities of the boost::function library. A standards-compliant compiler should compile the code without any modifications, but if you find you run into problems the following macros can be defined to adapt the function object wrappers to a broken compiler:
| Macro name | Effect and symptoms |
|---|---|
| BOOST_FUNCTION_USE_VIRTUAL_FUNCTIONS | When enabled, this macro uses virtual functions instead of the default function pointers. In most cases, this will generate larger executables. However, if a compiler optimizes virtual function calls well it may result in smaller, faster executables. Enabling this macro also fixes some code generation problems in some compilers... |
| BOOST_WEAK_FUNCTION_TEMPLATE_ORDERING | boost::function stresses function template ordering more than most compilers can handle. If your compiler is having trouble with free function pointer assignments, try defining this macro |
| BOOST_NO_DEPENDENT_BASE_LOOKUP | If your compiler cannot seem to find operators defined in a dependent base class (i.e., if you are trying to use boost::function operators and your compiler isn't finding them), try defining this macro |
| BOOST_NO_DEPENDENT_NESTED_DERIVATIONS | If your compiler can't handle the code in the function_traits_builder class, try defining this. |
| BOOST_WEAK_CONVERSION_OPERATORS | If expressions such as !f (for a boost::function object f) fail, try to define this. Note that this may allow some meaningless expressions to compile, such as f+4. |
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 boost::function objects are used.
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.
A compiler with strong interprocedural analysis could significantly reduce the overhead associated with virtual function calls such that the alternative used by Boost.Function is less efficient. No compiler has yet been found where this is true, but when it does occur the BOOST_FUNCTION_USE_VIRTUAL_FUNCTIONS macro can be defined to revert to the simpler implementation based on virtual functions.
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.