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