From: David Bergman (davidb_at_[hidden])
Date: 2002-11-22 13:38:51
In general, accomplishing the mapping Dave sought seems to be a game of
traversing alternative argument sets, properly embedded in template
definitions, such as in Boost.Lambda.
The problem would then be "reduced" ("converted" is a better word, since
the resultant problem is not exactly simple...) to have a meta tool for
traversing those templated argument sets. It looks like we have such a
tool in MPL.
It would be nice if one could use one template choice for each argument,
to not have to write down N^M (where N are the number of types supported
in this reverse type mapping, and M the maximum number of arguments
supported) templates... I know a lot of this machinery is to be found in
[mailto:boost-bounces_at_[hidden]] On Behalf Of Anthony Williams
Sent: Friday, November 22, 2002 4:05 AM
To: Boost mailing list
Subject: [boost] Standard interface for adaptable function objects?
David Abrahams writes:
> Do we have any precedent for ways to find out what the arity and
> argument types of an arbitrary function object is (I'm not talking
> about function pointers, here, but "functors")?
Given that a functor might support more than one argument set, the only
can think of is to say "do you support this argument set?" rather than
argument set do you accept?"; in which case you can use the mechanism
implemented in boost.lambda, and in my function composition library, to
the return type --- have a member template that takes a typelist
arguments you wish to pass, and returns the corresponding return type
that argument set is valid, or something else (such as
where it isn't (assuming you want to do something else in the case where
isn't, rather than just abort compilation)
Does this give you what you want?
-- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk