"Tobias Schwinger" <tschwinger@neoscientists.org> wrote in message news:ckdcqh$imj$1@sea.gmane.org...
Jonathan Turkanis wrote:
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote in message news:ckbu5h$acq$1@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:
I meant what has to happen _inside_ the function_arguments metafunction. And the fact that it has to be defined at the point of this code:
<snip>
However, I guess you are talking about another as_sequence distinct from mpl::as_sequence...
Yes, I misunderstood the question. I don't like the idea of 'overloading' mpl::as_sequence this way, but generating sequences from function types vice versa seems like a legitimate request. I'm still not sure I see the difficulty, though.
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
I should add to this: - it contains (almost) no broken compiler workarounds - it doesn't allow arities above BOOST_MPL_LIMIT_VECTOR_SIZE - it doesn't use the native TT macros. project
I am currently working on. However, I'd like to know your opinion about it.
I'll have a closer look at it this evening.
Thanks, Jonathan