RE: [boost] Standard interface for adaptable function objects?

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
MPL.

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[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
way I
can think of is to say "do you support this argument set?" rather than
"what
argument set do you accept?"; in which case you can use the mechanism
implemented in boost.lambda, and in my function composition library, to
deduce
the return type --- have a member template that takes a typelist
representing the
arguments you wish to pass, and returns the corresponding return type
where
that argument set is valid, or something else (such as
invalid_argument_set)
where it isn't (assuming you want to do something else in the case where
it
isn't, rather than just abort compilation)

Does this give you what you want?

Anthony
-- 
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