|
Boost : |
From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-10-10 17:31:29
"Tobias Schwinger" <tschwinger_at_[hidden]> wrote in message
news:ckbu5h$acq$1_at_sea.gmane.org...
> Alexander Nasonov wrote:
> > I have one addition to '[type_traits] "member_function_pointer_traits" ?'
> > thread started long time ago (29 Jul 2004) by Tobias Schwinger.
> > Is it makes sense to modify as_sequence to convert function type into a
> > sequence? Eg:
> > as_sequence<R (T0,T1)> ---> vector<R,T0,T1>
> > as_sequence<R(*)(T0,T1)> ---> vector<R,T0,T1>
> > as_sequence<R(&)(T0,T1)> ---> vector<R,T0,T1>
> >
> > as_sequence<R(C::*)(T0,T1)> ---> vector<R,C,T0,T1>
>
> as_sequence<R(T0,T1)> reads great, but this would add a lot to the
> complexity of 'as_sequence':
>
> First we have to idenitify if T is some sort of function (ptr/ref) type.
> Although there are ways to detect (not decompose, that is) functions and
> even member function pointers without using an unrolled cascades of
> specializations for different function arities, it requires a very
> standard compliant compiler.
> As we need to decompose the type and wrap its components into a vector
> in case it turns out to be a function anyway, we will instantiate one of
> these (more than 100) specializations.
I don't understand why this would be hard. Here's how I would do it:
template<typename F>
struct as_sequence_non_member {
typedef typename
mpl::push_front<
typename
function_arguments<
F
>::type,
typename
function_result<
F
>::type
>::type type;
};
template<typename F>
struct as_sequence_member {
typedef typename
mpl::push_front<
typename
function_arguments<
F
>::type,
typename
function_class<
F
>::type
>::type result;
typedef typename
mpl::push_front<
result,
typename
function_result<
F
>::type
>::type result;
};
template<typename F>
struct as_sequence
: mpl::if_<
is_member_function_pointer<F>,
as_sequence_member<F>
as_sequence_non_member
>::type
{ };
Last night I realized I needed the ability to manipulate function types as
sequences, so I wrote a small library to do it. I just finished documenting it:
http://home.comcast.net/~jturkanis/function_traits/
It differs from your library as follows:
- it splits up the metafunction signature into several metafunctions
- it allows function types to be constructed from sequences
- it doesn't handle volatility.
It's not really meant to compete with your proposal -- I wrote it for a project
I am currently working on. However, I'd like to know your opinion about it.
Best Regards,
Jonathan
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk