|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2002-11-21 11:53:03
Douglas Gregor <gregod_at_[hidden]> writes:
> On Thursday 21 November 2002 11:03 am, David Abrahams wrote:
>> 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")?
>>
>> -Dave
>
> No :(
>
> Lambda has the "sig" member template that, given the set of argument types,
> computes the return type. function_traits will give you the information for a
> function pointer. Boost.Function supplies 'arity' and argI_type.
> std::unary_function and std::binary_function are useful for standard library
> function objects. Basically, it's a big mess, especially when one needs to
> deal with template operator().
So there is a precedent. In fact, there are lots of precedents ;-)
I am about to propose two things, take your pick (not mutually exclusive):
1. That we have a signature_traits<U> whose nested type member is a MPL type
sequence describing return type and arguments. When the source type
is a member function pointer R (T::)(...), element one is T&. The
unspecialized template can look inside U for a signature type
member. It should also have an is_specialized member which is false
if there's no specialization and U doesn't have a nested signature
member that's an MPL sequence.
For broken compilers we make an overloaded function set which
returns such a type sequence, allowing it to work for function pointers
2. That we implement the primary function_traits<U> template to get the
arity and argI_type elements out of U. This would allow it to work
with boost::function<>.
In general I prefer 1 because it allows us to keep a consistent
metafunction interface (single-valued returns) and is more versatile.
However, 1 could be built on top of 2.
Thoughts?
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk