Boost logo

Boost :

From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2007-06-07 21:49:02

On Jun 7, 2007, at 2:22 PM, Emil Dotchevski wrote:
> In the implementation I posted, I opted for a parallel line of
> allocator
> support functions next to the original allocator-less functions. I
> liked
> this better because no allocator-related stuff is ever instantiated
> unless
> the user passes an allocator (and most users don't.)

Okay, that makes sense.

> The problem is that most boost::function tests do not use
> allocators. So
> while the allocator code should work (because it got tested in its
> original
> form), in it's current form it has only been proven to pass the
> allocator_test.cpp, which is rather simplistic.


> To really test everything, one needs to run all tests with the
> following
> variations:
> - pointer to function
> - pointer to member function
> - function object that fits the small object optimization
> - function object that does not fit the small object optimization
> - all of the above variations using an user-supplied allocator.

function_test and function_n_test test most of these, but without the
user-supplied allocator. You could probably hack up those.

Thanks for implementing this, and so quickly!

Looking briefly through the code... I see that you're not actually
storing the value of the allocator object itself along with the
function object. Was that decision intentional, or were you just
following the behavior of the existing boost::function?

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.

        - Doug

Boost list run by bdawes at, gregod at, cpdaniel at, john at