From: Saltwell, Erik (esaltwell_at_[hidden])
Date: 2000-11-16 17:59:41
Can you provide more details on 'the Kubrick article'?
> -----Original Message-----
> From: William Kempf [SMTP:sirwillard_at_[hidden]]
> Sent: Thursday, November 16, 2000 5:35 PM
> To: boost_at_[hidden]
> Subject: [boost] Callbacks Again
> I want to move onto discussing the Thread Concept very shortly, and
> so I've implemented a preliminary version in the recently checked in
> Win32 threads implementation file. The main thrust of this
> particular implementation is that instead of creating a thread on a C
> callback (a C function pointer) we'll instead create the thread on a
> C++ callback (a functor that can be created through various means
> including use of the Lambda Library). The current implementation
> uses a very generic/simple approach for storing the functor as a
> callback class instance which can be passed as a pointer to the
> actual underlying C callback internally. This implementation works,
> but it's not worth much more than a quick hack for the specific needs
> of a general concept that we all agree should be added to boost (at
> least I gather that from recent postings).
> 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 I
> can get my hands on and it seems they all take different approaches
> (the Kubrick article covers several of them), each with varying pros
> and cons. I'd like to describe what requirements I think our version
> 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 Lambda
> Library style functors can all be used with relative ease.
> 2. The callback type(s) should be templatized on the return type and
> argument types, but not on the functor type to simplify useage.
> 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.
> 4. A callback should itself be a functor.
> 5. Compiler type coercion should be possible to apply to the functor
> that the callback wraps for all parameters and the return value.
> 6. Executing a callback should be nearly as efficient as executing
> the contained functor.
> Do you agree or disagree with any of the above? What other
> requirements should there be? Any other ideas or comments? Is there
> someone interested in submitting an implementation for Boost? (I'm
> chewing on several Boost related things right now, so if there's
> someone else interested in tackling this I'd prefer it. If there
> isn't then I'll have to tackle it, because this is going to be a
> fundamental requirement for threads.)
> Bill Kempf
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk