|
Boost : |
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
extraction.
-gary-
gary.powell_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk