From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-10-11 10:55:35
"Tobias Schwinger" <tschwinger_at_[hidden]> wrote in message
> Jonathan Turkanis wrote:
> > "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:
> 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:
> However, I guess you are talking about another as_sequence distinct from
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,
> > 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
> > 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.
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.
> > It's not really meant to compete with your proposal -- I wrote it for a
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk