[boost] Boost.Function evolution

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-04-17 10:31:47

My tail is starting to itch.

Thread safety is an absolute must for the next revision of Boost.Function, 
and this addition will require a new ThreadingPolicy template parameter. 
Since this will break source compatibility, I think we should use this as an 
excuse to clean up some cruft.

Namely, (invocation) policies and mixins. Has anyone used either the Policy 
or the Mixin? I personally haven't ever used either parameter; at times I've 
thought they might be the right solution, but every time I found a better way.
Unless someone speaks for the utility of these features, they will disappear 
in the next revision.

So the template signature for the new Boost.Function will be:

  template<typename R, typename T1, typename T2, ..., typename TN,
           typename ThreadingPolicy, typename Allocator>
  class functionN;

If you've never used a custom mixin or invocation policy, and you've only 
used the named template parameter approach to changing the allocator (e.g., 
boost::function<...>::allocator<MyAllocator>::type), source code 
compatibility will be retained.

In addition to thread-safety, I expect the default allocator to change with 
the introduction of a more generalized small string optimization. Instead of 
handling small objects directly in Boost.Function (e.g., stateless function 
objects and function pointers), a new small string optimization allocator 
will be created that will become the default. This will mean that more types 
of small objects can be optimized, and also that the threshold deciding "what 
is a small object?" will be user-controlled.

Comments, questions, and desparate pleas for Mixin and Policy all welcome.

        Doug