Re: [boost] Re: Callbacks Again

From: Jesse Jones (jejones_at_[hidden])
Date: 2000-11-17 18:31:35

>> My (and I think William's version) handle free functions in the
>same way as
>> functors are handled. Member functions need a bit more. I think
>they should
>> be rolled into the core callback code, but William is so far
>unpersuaded.
>
>I think functors handle this.  Every functor library has a way to
>generate a "closure" form of functor.  It seems wrong to duplicate
>effort, especially when libraries specifically designed to addresss
>this are likely to do a better job of it.  However, I'm not hard
>nosed about it, so give counter arguments for why they should be
>addressed.

My major qualm is that the LL is too bleeding edge. I'd hate to have to use
callbacks wih MSVC (or CodeWarrior?) without being able to bind arguments.

>> >> This makes it tougher to include the bool
>> >>   conversion (how do we know if a functor has a real target or
>> >>   not?), which I consider essential.
>> >
>> >The bool conversion can be handled by inclusion of a default
>> >constructor that sets the "impl" pointer to null.
>>
>> Yep (of course a const void* conversion would be better than bool).
>
>Would it?  Didn't we decide the opposite for boost::any?

Yep. Now that I think about it void*'s aren't quite right here either. If
all you had were free functions you could return the function address. This
would still allow you to compare differently typed callbacks, but at least
you'd get the correct results. However you can't really do this with
functors...

The bool conversion operator is bad because it allows you to use a callback
anywhere an integral expression can be used. I guess we should do like any
did and use an empty method.

>I think we're crossing wires here.  A closure is simple to implement,
>at least minimally.  However, libraries like Lambda do a better job
>than the "minimalist" approach, and if you've looked at their
>implementation you must agree that they are a "tremendous amount of
>effort" :).

Certainly enough to scare me. :-) But the vast majority of callbacks need
nothing more than a minimalist approach, ie something that allows you to
bind one or more arguments of an arbitrary callback.

  -- Jesse