Re: [boost] [function] allocator template parameter question

From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2007-06-05 09:38:38

On Jun 5, 2007, at 5:42 AM, Giovanni Piero Deretta wrote:
> On 6/5/07, Hervé Brönnimann <hervebronnimann_at_[hidden]> wrote:
>> [...]
>> Btw, the overhead you add by this technique is a virtual function
>> call for all management-related functions (cloning, destroying, etc.)
>> including for functions which do not care about allocator (function
>> pointers, member functions and functors with small buffer
>> optimization).  In fact, I think that this cost may be undesirable at
>> several levels because it also will prevent a number of optimizations
>> since polymorphic dispatch cuts the compiler off from compile-time
>> resolution.
>
> Aren't these operations (cloning, destroying, invocation, etc.)
> already currently implemented using a set of function pointers (at
> least they were last time I looked)?

Yes, these operations already have to be implemented using function  
pointers, because boost::function does not know statically what type  
of function object it will store. So, making the allocator  
dynamically change just means moving the allocator itself into the  
same place where the function object is stored: there will be no  
additional performance cost.

> Anyways, I do not think that the allocator trick require virtual
> functions, probably the existing type erasure can be used to also
> accommodate the allocator.

Yes.

>> So it may be best to provide two function class
>> templates, one without and one with allocators.
>
> Oh, no please! What makes boost::function (and shared_ptr btw) very  
> good
> is the "one type fits all" design that allows it to be passed between
> unrelated libraries. Let's keep it that way.

Right.

        - Doug