Boost logo

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.


                       David Abrahams
   dave_at_[hidden] *
Boost support, enhancements, training, and commercial distribution

Boost list run by bdawes at, gregod at, cpdaniel at, john at