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.