Re: [boost] [mpl][fold.html] apply<op, _1, deref<_2> > correction needed.

Subject: Re: [boost] [mpl][fold.html] apply<op, _1, deref<_2> > correction needed.
From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2009-04-05 22:59:06

On Mon, 16 Mar 2009 09:19:25 -0500, Larry Evans  
<cppljevans_at_[hidden]> wrote:
> On 03/16/09 01:34, Aleksey Gurtovoy wrote:
>> Nope, it should have been
>>    typedef iter_fold<s,state,apply2<lambda<op>::type,_1,deref<_2> >  
>>  >::type t;
>>                                  ^ ^^^^^^^^^^^^^^^^
>
> since apply2<op,a1,a2> is derived from
> apply_wrap2<lambda<op>::type,a1,a2>, it would be less
> confusion, at least to me, to just use
> apply_wrap2<lambda<op>::type,_1,deref<_2> >.

Good point. It's also more consistent with the rest of the docs
(e.g.  
http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/unique.html).

Corrected in https://svn.boost.org/trac/boost/changeset/52205.

>> That is:
>>    - 'apply2' instead of 'apply' to workaround "apply + lambda +
>>      BOOST_MPL_LIMIT_METAFUNCTION_ARITY+1" issue
>>      (http://article.gmane.org/gmane.comp.lib.boost.user/9917) and
>
> That post seems to suggest a workaround:
>
>> When I first realized this, I was thinking about bumping up
>> BOOST_MPL_LIMIT_METAFUNCTION_ARITY internally, so that, in fact,
>> the maximum supported arity of placeholder expressions (but not  
>> everything
>> else) would be BOOST_MPL_LIMIT_METAFUNCTION_ARITY + 1, but unfortunately
>> never got to it. I'll consider fixing this for 1.33.
>>
>
> Would this workaround actually work?

In one or another form, sure.

> If so, are there plan's to install it?

It's on the TODO list  
(http://svn.boost.org/trac/boost/wiki/BoostMplRoadmap),
but there is no specific plan aside "this should be fixed at some point".
Patches are welcome :).

Sorry for the late reply, got totally swamped.

-- 
Aleksey Gurtovoy
MetaCommunications Engineering