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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
