On 09/04/2011 16:48, Joel Falcou wrote:

I was thinking lately that it is a shame we can't do the following :

boost::mpl::transform< SomeSequence, _1&>

instead of the lengthy

boost::mpl::transform< SomeSequence, add_reference<_1> >

same goes for *, const, volatile :

boost::mpl::transform< SomeSequence, volatile _1**&>

Some time ago I did some work on a metafunction to perform overload resolution. In the process of emulating and supporting template functions, I ended up with something I like to call 'type patterns' as a byproduct. It allows to query as well as create types based on 'type patterns', as the OP suggest, in a less verbose way. For example: matches< int( _1, _, _1 ), T >::type is T a function type returning int, taking three parameters, where the first and the last one are of the same type, and the second one is of any type? If so, which type is _1? replace< int( _1, _2, _1 ), list< int, float > >::type create a function type with signature int( int, float, int ) The core of it is a metafunction that decomposes the type declaration into an AST, and applies a visitor function to it. AFAIR, it considered const and volatile modifiers, pointers and references, arrays, pointers to member, function types, and even templates. Perhaps its time for me to dig such code, and polish it up to boost standards. Would it be interest in adding something like this to MPL? Agustín K-ballo Bergé.- http://talesofcpp.blogspot.com

Hi Joel, On Sat, 09 Apr 2011 14:48:57 -0500, Joel Falcou <joel.falcou@lri.fr> wrote:

I was thinking lately that it is a shame we can't do the following :

boost::mpl::transform< SomeSequence, _1&>

instead of the lengthy

boost::mpl::transform< SomeSequence, add_reference<_1> >

same goes for *, const, volatile :

boost::mpl::transform< SomeSequence, volatile _1**&>

Could it be possible to get such a behavior in MPL by having a pass of replacing type qualifier by corresponding metafunction until none are left then apply the lambda ?

I considered supporting exactly this type of transformations as a part of the standard lambda expansion behavior and ultimately decided against it due to [what seemed to me as] a relatively infrequent need for this type of code and its limited expressive power: e.g. if you want to *remove* type qualifiers, you are back to using type traits library. Throw in function types and pointers, which are obviously doable but also expensive in terms of number of specializations, and the whole thing suddenly looks much less attractive :), at least as a built-in mechanism. On the other hand, may be I'm overestimating the size/complexity/compile-time cost of implementing this. I guess somebody needs to measure and see :).

In the same vein, having a MPL trandform turning a sequence of std::vector into their corresponding value_type require out of line small metafunction to be written. I guess a macro like

BOOST_MPL_ADAPTED_PLACEHOLDER( v, (type)(value_type)(reference)(const_reference) )

builds a whoel familly of _v1, ..., _v5 placeholder which behaves like _n and expose typedef called value_type etc ... that resolve to said small lambda function directly.

This would allow for a terse:

boost::mpl::transform< SomeSequence, _v1::reference>

Are these ideas out of the question due to some internals of MPL I missed ?

Definitely not out of question.

Are they worthy a patch ?

Overall, these are reasonable ideas. I have some concerns about the cost I've mentioned above, but other than that, I'd be happy to see these in. -- Aleksey Gurtovoy MetaCommunications Engineering