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
> > function pointers, standard functors, hand coded functors and
> > 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
> > argument types, but not on the functor type to simplify useage.
> There may be issues with partial declaration of the functor, but in
> it makes using one very easy.
I'm not sure I understand what you mean by "partial declaration of
> > 3. Copying a callback should be quick, on par with copying a
> > function pointer. This is not gauranteed with functors but
> > 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
> The Janitor class that is in ScopeGuard does this using an
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
> > that the callback wraps for all parameters and the return value.
> The lambda library has such tools. (Peter's version does too.) We
> 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
> > the contained functor.
> This is also very compiler dependent. But in general should be a
> 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
> > 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
> willing to help out. Jaakko and I are dealing with some of these
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk