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

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-11-22 08:16:34

On Thursday 21 November 2002 11:53 am, David Abrahams wrote:
> > 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.

I prefer this one. I also think we should follow Peter's suggestion and go 
with function types to return the signature. They represent a wonderfully 
concise way to express, well, a function signature; we can provide a separate 
function type->argument list/argument tuple metafunction for other uses.

>    For broken compilers we make an overloaded function set which
>    returns such a type sequence, allowing it to work for function pointers

And how do we get that returned type sequence back into a metaprogram?

        Doug