On Jun 5, 2007, at 5:42 AM, Giovanni Piero Deretta wrote:
On 6/5/07, Hervé Brönnimann <hervebronnimann@mac.com> 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