Re: [boost] about function.hpp

From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-05-06 02:57:29

>Taking the address of a function instantiates
>it, and instantiation of equal() requires that operator== be available in
>FunctionObj. The concept check library relies on this behavior (taking the
>address of a function requires instantiation) to check its constraints.

Right.

>3) There's more to this as well - the two function0 objects don't necessarily
>have targets of the same type, so a manager check would be necessary.
>Additionally, we could have:
>
>int my_fun(int);
>function<void, int> f1 = &my_fun;
>function<int, int> f2 = &my_fun;
>
>And we'd probably want to have (my_fun == my_fun), which makes things even
>nastier.

Well the function objects are distinct types so I don't think anyone 
will complain if you can't compare the two.

>The only way I can see to handle operator== without requiring it of all
>function objects is to do it dynamically by keeping track of the
>std::type_info associated with the contained function object/pointer and
>using it for dynamic dispatch to an operator==; this would require a bit of
>user maintenance, though.

Yeah, I see now why you thought it was a sticky problem. I think it's 
time to decide on what we're trying to achieve here. It seems to me 
that that are two problem domains boost::function is trying to 
address. The first, let's call it the callback domain, is used for 
things like button click handlers, timer callbacks, and other sorts 
of notifications. It will usually only be applied to member function 
pointers and occasionally free functions (and functors that contain 
one of these and one or more bound arguments). The second, let's call 
it the functor domain, deals more with generic programming using 
things like std::transform. In this domain function objects are used 
more heavily.

It'd be great if we could address these two domains with a single 
class, but it seems like we're going to have to make a trade-off 
somewhere. Personally I think that callbacks are used a lot more 
often than functors. And being able to compare two callbacks *is* 
useful functionality. If this requires that clients have to define an 
operator== for function objects that would be unpleasant, but worth 
the ugliness from my POV.

   -- Jesse