From: Gary Powell (Gary.Powell_at_[hidden])
Date: 2000-11-17 20:12:41
> > > As for the original templated
> > > constructor, I dislike where an error will occur if an incorrect
> > > functor type is given to the callback, which will be way down in the
> > > detail::callback0_impl::operator() function. Using the more rigid
> > > approach with the three implementation classes, this error will be
> > > picked up when an assignment is attempted.
> > This can be handled with Concept Checking :). No, I don't have code
> > to do this yet, but I don't see any other way to handle arbitrary
> > functors.
> In this case we would probably need a functor_traits class to dig out
> the number and types of arguments. I used a simple FunctorTraits class
> (which contains a "nArgs" value given the number of arguments, a Result
> typedef, and Arg1, Arg2, ..., ArgN typedefs giving the argument types).
> A GetArg<Functor, ArgNum> class gets the appropriate argument type
> (either a type, or "Unused" if ArgNum > nArgs).
The lambda library already does this to generate the correct return types.
We used tuples to hold the arguments, and select functions to do the
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk