[mpl] apply as a placeholder expression?
I have an MPL sequence of metafunction classes. I want to apply<> each with mpl::transform. So I did this: struct metafnclass { template<typename T> struct apply { typedef T type; }; }; typedef mpl::vector<metafnclass, metafnclass> metafnclasses; typedef mpl::transform< metafnclasses , mpl::apply<mpl::_1, int>
::type transmetafnclasses;
This fails horribly, and I don't know why. If I add an indirection like this: template<typename T,typename U> struct indirect_apply : mpl::apply<T, U> {}; typedef mpl::transform< metafnclasses , indirect_apply<mpl::_1, int>
::type transmetafnclasses;
then it works fine. Why should that be? Is something getting evaluated too eagerly? -- Eric Niebler Boost Consulting www.boost-consulting.com
Your email inspired me to go look through code as I was certain I had run into this too. Turns out I have similar code to below with a comment that says" todo figure out why this needs to be indirected". If it is any help, I had this problem on BOTH GCC4 and VC71, so it doesn't seem to be a compiler specific issue. On 11/1/05 11:21 AM, "Eric Niebler" <eric@boost-consulting.com> wrote:
I have an MPL sequence of metafunction classes. I want to apply<> each with mpl::transform. So I did this:
struct metafnclass { template<typename T> struct apply { typedef T type; }; };
typedef mpl::vector<metafnclass, metafnclass> metafnclasses;
typedef mpl::transform< metafnclasses , mpl::apply<mpl::_1, int>
::type transmetafnclasses;
This fails horribly, and I don't know why. If I add an indirection like this:
template<typename T,typename U> struct indirect_apply : mpl::apply<T, U> {};
typedef mpl::transform< metafnclasses , indirect_apply<mpl::_1, int>
::type transmetafnclasses;
then it works fine. Why should that be? Is something getting evaluated too eagerly?
Eric Niebler <eric <at> boost-consulting.com> writes:
I have an MPL sequence of metafunction classes. I want to apply<> each with mpl::transform. So I did this:
I'm afraid it's a design flaw. *Every* mpl::apply is just a 6-ary meta-function, but mpl::lambda only support up to 5-ary ones. We call mpl::apply 5-ary meta-functions but mpl::lambdas don't thinks so, they just see how much template parameters are there in the template-parameter-list. Or I suspect that we really should call mpl::apply 6-ary meta-fun because it really takes 6 arguments! Incrementing the 'BOOST_MPL_..._LIMIT_ARITY'(I forgot the detail though) doesn't help though, because the arity of mpl::apply will increase correspondingly and will always be one more arity than that mpl::lambda can support! It's inherent conflict or inconsistence. Did I miss any obvious alternative?;-)
pongba <pongba@gmail.com> writes:
Eric Niebler <eric <at> boost-consulting.com> writes:
Incrementing the 'BOOST_MPL_..._LIMIT_ARITY'(I forgot the detail though) doesn't help though, because the arity of mpl::apply will increase correspondingly and will always be one more arity than that mpl::lambda can support! It's inherent conflict or inconsistence.
Did I miss any obvious alternative?;-)
Eric can use the appropriate applyN template. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
pongba <pongba@gmail.com> writes:
Eric Niebler <eric <at> boost-consulting.com> writes:
Incrementing the 'BOOST_MPL_..._LIMIT_ARITY'(I forgot the detail though) doesn't help though, because the arity of mpl::apply will increase correspondingly and will always be one more arity than that mpl::lambda can support! It's inherent conflict or inconsistence.
Did I miss any obvious alternative?;-)
Eric can use the appropriate applyN template.
Ah, thanks. Using applyN instead of apply fixes the problem. The fact that apply doesn't work here seems like a bug to me. Is it fixable? -- Eric Niebler Boost Consulting www.boost-consulting.com
"Eric Niebler" <eric@boost-consulting.com> writes:
David Abrahams wrote:
pongba <pongba@gmail.com> writes:
Eric Niebler <eric <at> boost-consulting.com> writes:
Incrementing the 'BOOST_MPL_..._LIMIT_ARITY'(I forgot the detail though) doesn't help though, because the arity of mpl::apply will increase correspondingly and will always be one more arity than that mpl::lambda can support! It's inherent conflict or inconsistence.
Did I miss any obvious alternative?;-)
Eric can use the appropriate applyN template.
Ah, thanks. Using applyN instead of apply fixes the problem. The fact that apply doesn't work here seems like a bug to me. Is it fixable?
Not really, without changing how it is used. It's the arity problem that pongba pointed out. You'd have to write something like: apply<some_lambda_expression>::to<a, b, c> -- Dave Abrahams Boost Consulting www.boost-consulting.com
Eric Niebler writes:
David Abrahams wrote:
Eric can use the appropriate applyN template.
Ah, thanks. Using applyN instead of apply fixes the problem. The fact that apply doesn't work here seems like a bug to me.
Technically, it is.
Is it fixable?
I'm planning to take a shot at it, see http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?MPL_TODO_List (Short-term TODO list / Next release). -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
Eric Niebler writes: I'm planning to take a shot at it, see http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?MPL_TODO_List (Short-term TODO list / Next release).
I guess the easy fix is to always make the lambda support handle one more argument than specified by the macro that controls the arity of apply. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (5)
-
Aleksey Gurtovoy -
Brian Braatz -
David Abrahams -
Eric Niebler -
pongba