RE: [boost] Callbacks Again

From: Saltwell, Erik (esaltwell_at_[hidden])
Date: 2000-11-16 17:59:41

Can you provide more details on 'the Kubrick article'? 
I'm interested.

> -----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
> 
> 
>