Re: [boost] about function.hpp

From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-05-04 04:01:46

>  > Well you can make it work when the boost::function is pointing to a
>>  free function, a member function pointer, or a functor that supports
>>  operator==. If you got a compile time error when you tried to compare
>>  boost::function's when this didn't hold that would be fine with me.
>
>But making it work at all requires _every_ functor to implement operator==,
>which is too strong a requirement (especially considering that the standard
>library function objects don't have operator==).

The standard's function objects don't have hardly anything. :-)

>See my response to Beman
>regarding the impossibility of passing compile-time information through a
>type-erasing barrier (i.e., virtual functions or taking the address of
>functions). I'd love for someone to find a hole in the argument and supply an
>implementation that can do it ;).

I see your point, but I'm not sure it applies here. Can't you just 
add equality methods to the base function objects (function1 and so 
forth) and delegate the actual comparison to the invoker? The 
function object invokers would then delegate to the function object 
which might result in a compile time error.

>Perhaps a separate concept is required that would include operator==. Maybe
>this is the fundamental difference between boost::function and a
>not-yet-implemented boost::callback?

That would suck. :-) I know there was some talk of callbacks with all 
sorts of crazy features, but I had always hoped that these could be 
built on simpler constructs...

>I believe Peter's bind() is a lot more general than what I was considering,
>In any case, I don't think that adding support for member functions directly
>into to boost::function is the best choice - it seems wrong to add
>functionality that we know will be bested by the binders/lambda library,
>because then boost::function ends up carrying dead weight.

No dead weight. The code can call the binder/lambda library directly. 
It's just a convenience that is IMO justified by how often people 
will attach member functions to callbacks.

   -- Jesse