Re: Callbacks Again

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-16 18:11:12

--- In boost_at_[hidden], Gary Powell <Gary.Powell_at_s...> wrote:
> 
> > 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.
> Yes, this style was used in the ScopeGuard, and it works
> well with Lambda functors, and std binders.

ScopeGuard is yet another specialized use of callbacks that would be 
better suited by using a generic implementation :).  My slightly more 
advanced version of ScopeGuard would benefit even more from using a 
generic callback implementation.

> > 2.  The callback type(s) should be templatized on the return type 
and 
> > argument types, but not on the functor type to simplify useage.
> There may be issues with partial declaration of the functor, but in 
general
> it makes using one very easy.

I'm not sure I understand what you mean by "partial declaration of 
the functor".
 
> > 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.
> If the callback is a "base pointer" to a callback this should be 
trivial.
> The Janitor class that is in ScopeGuard does this using an 
auto_ptr<>.

Most of the requirements should be at least relatively trivial to 
obtain.  I just want to make sure that even the trivial requirements 
are thought out and covered in the final implemenation.
 
> > 4.  A callback should itself be a functor.
> This falls out of requirement #2.

It does logically, but not technically.  Requirement #2 doesn't 
require that the callback contain an operator() used to invoke the 
callback, for instance.  Again, I'm trying to be complete here.
 
> > 5.  Compiler type coercion should be possible to apply to the 
functor 
> > that the callback wraps for all parameters and the return value.
> The lambda library has such tools. (Peter's version does too.) We 
recently
> added the 4 std casts as well.

I'm not completely sure that we're exactly on the same wave length 
here.  If I'm not mistaken, the functionality you're discussing is 
the ability to modify a functor to meet certain requirements, while 
the callback itself does not need such external modifications.  What 
I'm talking about is insuring that the internal functor need not 
match exactly the types specified by the callback so long as the 
types are all coercable at compile time.  This could be done using 
the LL stuff internally, but I think that's probably overkill and I 
worry about portability.  As you know LL is unfortunately not 
portable to several compilers, including that one we all love to hate 
(or is that hate to love?).
 
> > 6.  Executing a callback should be nearly as efficient as 
executing 
> > the contained functor.
> This is also very compiler dependent. But in general should be a  
pointer
> deference, and then the function call.

Again, I'm trying to be complete here.  Most implementation will 
result in a single level of indirection being added.  However, I've 
seen some that go beyond this and I want to insure that one of the 
requirements is to not do so with our implemenation.
 
> > (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.)
> > 
> If there is any support that LL could provide to make this easier 
I'm
> willing to help out. Jaakko and I are dealing with some of these 
issues
> right now.

Well, your experience will probably be very helpful to the 
discussion, and probably of help to who ever winds up tackling this 
one :).  However, I'm hoping that the implementation does not rely on 
LL because I really want this concept to work on VC++ (and other non-
compliant compilers).  I think LL will be GREATLY beneficial in using 
callbacks, but I hope it's not a requirement for implementing them.

Bill Kempf