From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-17 09:39:14
--- In boost_at_[hidden], Jesse Jones <jejones_at_a...> wrote:
> >So... before we discuss the thread specific stuff I'd like to first
> >address callbacks. I've read all the articles on the subject that
> >can get my hands on and it seems they all take different approaches
> >(the Kubrick article covers several of them), each with varying
> >and cons. I'd like to describe what requirements I think our
> >of callbacks need to take just to make sure everyone agrees with my
> >opinions before we attempt to create an actual implementation.
> >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.
> >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
> >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.
> >5. Compiler type coercion should be possible to apply to the
> >that the callback wraps for all parameters and the return value.
> This is also very useful. It lets you do things like assign to a
> that takes an int argument a function that takes either an int or a
> Or, alternatively, you can assign a function with two arguments to a
> callback with one if the second argument has a default value.
Exactly. Doesn't cover all the bases but it covers enough to allow
the useage to be more robust. LL and other libraries can then take
care of the corner cases.
> Along the same lines it's useful to assign a function that returns
> to a callback that returns void.
Which will be a frequent "coercion". The specializations for void
returns should make this trivial, so I didn't think to mention it,
but for completeness sake this should be added to my list.
> >Do you agree or disagree with any of the above? What other
> >requirements should there be? Any other ideas or comments? Is
> >someone interested in submitting an implementation for Boost?
> I can submit some code that fulfills all of the goals you mentioned
> as the ones I listed above.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk