From: Edward Diener (eddielee_at_[hidden])
Date: 2006-01-15 11:15:43
Alex Besogonov wrote:
> Peter Dimov wrote:
>> Most of the time is probably due to function<>'s dynamic dispatch mechanism;
>> I'm not sure how FastDelegate can help.
> I've tried to hack it into function<> myself but I've failed :)
>
> I'm thinking of something like:
> ======================
> union function_buffer
> {
> //FastDelegate
> FastDelegateData delegate_data;
>
> // For pointers to function objects
> void* obj_ptr;
>
> // For pointers to std::type_info objects
> // (get_functor_type_tag, check_functor_type_tag).
> const void* const_obj_ptr;
>
> // For function pointers of all kinds
> mutable void (*func_ptr)();
>
> // For bound member pointers
> struct bound_memfunc_ptr_t {
> void (X::*memfunc_ptr)(int);
> void* obj_ptr;
> } bound_memfunc_ptr;
>
> // To relax aliasing constraints
> mutable char data;
> };
> ======================
> 'delegate_data' should be used if we're creating a delegate (i.e.
> pointer to method with bound 'this' pointer). It's called a 'closure' in
> Borland-speak.
I would be careful using FastDelegate as an adjunct to Boost
function/bind. It is very dependent on knowledge of compiler member
function pointer sizes and uses "hacks" based on that knowledge to
achieve its speed. Boost should try to stay clear of low-level compiler
dependent knowledge whenever it can, sacrificing a little extra speed
for greater stability. Of course if it is an optional choice for
end-users, then it is more understandable but even then end-users should
be duly notified of the issues involved. This is not in any way a
putdown of FastDelegate but Boost function/bind is richer in
functionality and therefore pays the price of being slower. Of course
speed is important but not if it means less stability of implementation.