| Home | Libraries | People | FAQ | More

## History & Compatibility Notes

- Version 1.52.0:

  - Move constructors and move assignment operators added (only for compilers with C++11 rvalue references support). Original patch contributed by Antony Polukhin.

- Version 1.37.0:

  - Improved the performance of Boost.Function's swap() operation for large function objects. Original patch contributed by Niels Dekker.

  - Added a new header <boost/function/function_typeof.hpp> that provides support for using the Boost.Typeof library on Boost.Function objects.

  - Added a new header <boost/function/function_fwd.hpp> that provides support for using the Boost.Typeof library on Boost.Function objects.

  - The `target`() function now respects the cv-qualifiers of function objects stored by reference (using `boost::reference_wrapper`), such that a reference to a `const` function object cannot be accessed as a reference to a non-`const` function object.

- Version 1.36.0:

  - Boost.Function now implements allocator support in the same way that is is provided in C++0x, based on C++ committee proposal N2308. This change removes the `Allocator` template parameter of `boost::function` in favor of a constructor that takes an argument. While this is a backward-incompatible change, it is likely to affect only a few users. This change to Function was contributed by Emil Dotchevski, which also authored the corresponding C++ committee proposal.

- Version 1.34.0:

  - Boost.Function now implements a small buffer optimization, which can drastically improve the performance when copying or construction Boost.Function objects storing small function objects. For instance, `bind(&X:foo, &x, _1, _2)` requires no heap allocation when placed into a Boost.Function object. Note that some exception-safety guarantees have changed: assignment provides the basic exception guarantee and `swap()` may throw.

- Version 1.30.0:

  - All features deprecated in version 1.29.0 have been removed from Boost.Function.

  - `boost::function` and `boost::functionN` objects can be assigned to 0 (semantically equivalent to calling `clear()`) and compared against 0 (semantically equivalent to calling `empty()`).

  - The Boost.Function code is now generated entirely by the Preprocessor library, so it is now possible to generate `boost::function` and `boost::functionN` class templates for any number of arguments.

  - The `boost::bad_function_call` exception class was introduced.

- Version 1.29.0: 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:

  - The `boost::function` class template syntax has changed. The old syntax, e.g., `boost::function<int, float, double, std::string>`, has been changed to a more natural syntax `boost::function<int (float, double, std::string)>`, where all return and argument types are encoded in a single function type parameter. Any other template parameters (e.g., the `Allocator`) follow this single parameter.

    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 `functionN` 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 `boost::function<void, int, int>` to `boost::function2<void, int, int>` (adding the number of function arguments to the end of the class name).

    Support for the old syntax with the `boost::function` class template will persist for a short while, but will eventually be removed so that we can provide better error messages and link compatibility.

  - The invocation policy template parameter (`Policy`) has been deprecated and will be removed. There is no direct equivalent to this rarely used feature.

  - The mixin template parameter (`Mixin`) has been deprecated and will be removed. There is not direct equivalent to this rarely used feature.

  - The `set` methods have been deprecated and will be removed. Use the assignment operator instead.