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