On Jun 7, 2007, at 10:21 PM, Emil Dotchevski wrote:
I am storing the allocator, in struct functor_wrapper from function_base.hpp, but it has a partial specialization for std::allocator which doesn't store the allocator, and perhaps that's what you saw. Please take another look:
http://www.revergestudios.com/boost-function/function_base.hpp
Of course if the function object can use the small object optimization, the functor_wrapper template is not used and no copy of the allocator is stored in the boost::function.
Ah, right. I was looking at part of the code where the allocator wasn't being passed on, but of course that part of the code didn't need to do any allocation. Two comments: (1) Often, one inherits from the allocator rather than storing it in a member. That way, if the allocator type is empty, we don't need to use up any storage. (2) Visual C++ strikes again: we'll have to #ifdef out these allocator versions for Microsoft's compiler prior to version 7.1, both because of the reliance on partial specialization of class templates and because of the use of rebind.
I haven't done a thorough review of the code, but I'd be inclined to move boost::function toward this approach. It's a better extension to tr1::function than the existing code, and it might be the right way for C++0x's "function" to go. If you're interested in this feature going into the next standard, I suggest writing a short proposal to the C++ Library Working Group for this extension.
Will do.
Looking forward to it. If you write it soon, it should get on the agenda for the July meeting of the C++ committee. I expect it will be easily accepted. - Doug