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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk