Boost logo

Boost :

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-10-11 01:03:55


"Alexander Nasonov" <alnsn_at_[hidden]> wrote in message
news:20041011052232.GA2287_at_x1000.localdomain...
> Jonathan Turkanis wrote:
> > 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/
>
> Wow! So many in one night! I'll be reading it a whole day :)
>
> I also wrote function_arguments some time ago because I needed it. In
> some situations it fits natural to your needs. For example:
>
> - add call_traits<>::param_type or add_reference to args and return
> a signature
> - add or remove some args from a signature
> - wrap some args

What I needed was the ability to add a parameter of type void* at the beginning
of an arbitrary function pointer type. Of course I could have implemented this
single transformation much more simply, but I like to generalize everything ;-)

> Conversion to mpl::vector and back to signature would slow down
> a compilation. Why waste your time if function_arguments can be
> made as fast as mpl::vector after applying similar optimization
> techniques?

I'm not sure I understand your point. If you're saying that it's possible to
implement mpl::sequence types specially tailored for function types, then I'm
all for it, though I don't really see how to do it. OTOH, if you're saying that
certain mpl algorithms should be reimplemented for function types, I'm not sure
I agree, because it seems like reinventing the wheel.

The regressions tests included in the code I posted contain about 200 static
assertions, many involving mpl::equal, and they still compile quickly.

>
> Alexander Nasonov

Jonathan


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk