Re: [boost] Boost MPL metafunction shortcut

Subject: Re: [boost] Boost MPL metafunction shortcut
From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2011-04-11 06:18:28

Hi Joel,

On Sat, 09 Apr 2011 14:48:57 -0500, Joel Falcou <joel.falcou_at_[hidden]> 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