On Mon, 16 Mar 2009 09:19:25 -0500, Larry Evans <cppljevans@suddenlink.net> 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