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: Larry Evans (cppljevans_at_[hidden])
Date: 2009-03-16 10:19:25

On 03/16/09 01:34, Aleksey Gurtovoy wrote:
Hi Aleksey,
[snip]
> 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> >.  Otherwise,
you'dd have apply_wrap2<lambda<lambda<op>::type>::type,_1,deref<_2> >.
As shown in my last upload to the vault.  this seems to work.
Now why apply2<op,,> doesn't is a mystery to me since it's
superclass, apply_wrap2<lambda<op>::type,,> seems to work.

> 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?  If so, are there plan's to
install it?

[snip]

> 
> Fixed in the doc sources in the trunk
> (https://svn.boost.org/trac/boost/changeset/51791).

Thank you.

> 
> Thanks for the report!
> 

Glad I could help.

-Larry