RE: [boost] Re: Callbacks Again

From: Gary Powell (Gary.Powell_at_[hidden])
Date: 2000-11-16 18:43:09

> > > 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".
> 
for a functor like:

template <class fn>
class functor {
public:
   template<class RET, class Arg>
   RET operator()(Arg &a)
   { return fn(a); }
};

int foo(int);
int i;

I think there are problems with
  functor< int (*)(int) > *callback = new functor<int (*)(int)> (&foo);

  callback<int>(i);

that have to do with the member template operator()() not being fully
defined at the time of the call to new. But I don't have the exact problem
in front of me, only a memory of being bitten with this. But it could have
been some other issue. (I've been bitten by so many compiler/language issues
that I just have the basic screaming nightmares....) And it may be that with
some more layers of templates its not a problem.... Again, this is an area
I'm looking over again after several months off doing other things with LL.
And I may still be dreaming about past problems that have nothing to do with
this.
>  
> > > 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.
> 
Well, I think you may have difficulty implementing it so
that your #5 issue is also taken care of as well, without
using a functor, or some miserable casting at the time of construction.
>  
> > > 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 is the same problem from a different angle. LL has a ret<Type>()
operation that tells the operator()() what the return type is supposed to
be, without a cast, just coercion. There are also
static_cast<Type>(expression) operations as well.

I think as long as you don't do anything here you'll be fine. Especially if
we can work out #2.

>  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?). (hate is too weak a word. Loath?)
>   
> Well, your experience will probably be very helpful to the 
> discussion, and probably of help to who ever winds up tackling this 
> one :). 
Thanks!
>  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). 
Agreed. Also LL at this time only supports up to 3 unbound arguments in the
callback. Not a limitation I'd like in my callbacks.

>  I think LL will be GREATLY beneficial in using 
> callbacks, but I hope it's not a requirement for implementing them.
me neither, but I hate to see people have to resolve the same problems over
again. Also MSVC will catch up eventually, they always keep plugging along
even if it appears to be at a really slow pace.

  -gary-

gary.powell_at_[hidden]