From: Jesse Jones (jejones_at_[hidden])
Date: 2000-11-17 17:30:45
>> >1. Need to allow traditional functor types as the callback so that
>> >function pointers, standard functors, hand coded functors and
>> >Library style functors can all be used with relative ease.
>> I'd go with allowing callbacks to be constructed with either a
>> an object/member function pointer. The second is probably
>> it's such a common operation that it should be very easy to do.
>mem_fun, LL et. al. take care of the object/member function pointer,
>so it's redundant IMHO.
mem_fun won't quite cut it. For a method call it requires that the object
be passed in as you call the callback. This means that you can't call
arbitrary callbacks from non-template code. Very bad.
>> >3. Copying a callback should be quick, on par with copying a
>> >function pointer. This is not gauranteed with functors but becomes
>> >somewhat important with callbacks that may be stored, copied and
>> >passed around frequently in some cases.
>> We probably also want to be able to test for equality. Possibly
>Hmmm... interesting idea, but I'm not so sure about that. You can't
>compare functors created with the standard library, for instance.
>And ordering makes little sense, unless it's a partial ordering, like
>that provided by std::type_info. Comparison and ordering are going
>to be hard nuts to crack here given that standard functors don't
Hickey's original library included ordering, but I've never used it. I'm
not sure I've even used equality tests although that seems more useful.
>> >4. A callback should itself be a functor.
>> Along the same lines it's very useful to be able to bind one or more
>> arguments. This is pretty easy to do even without a full blown
>It's outside of the callback concept, however. Binding just results
>in a new functor that wraps the original.
>It's best handled by other
>libraries such as the standard library and LL, since such libraries
>can do a better job of addressing the issue than we're likely to do
>in this specialized case.
The standard library isn't good enough because it's highly desirable to
call the callbacks from non-template code. I'm not sure about the LL, but
one obvious objection is that it's less portable than some bind functions
targeted at just callback objects.
>I'd appreciate it. Even if others think we need more thought before
>finalizing this, it's a concept that I think is needed sooner than
>later in Boost so it's time we started looking at real world
>implementations and discussing the theories/particulars.
OK, I'll upload something to the vault later tonight.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk