Boost logo

Boost :

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 {
   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);


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
> > > 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 :).
> 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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at