Ok, suppose we have a policy-based class Foo, and a policy P: template <typename Policy> class Foo { // ... }; struct P { template <typename T> struct apply { typedef policy type; }; }; Now, my understanding is that we can use Lambda so that we can invoke Foo this way: Foo<P> f; Or define P in this way: template <typename T> struct P { // policy }; and call Foo this way: Foo<P<_> > f; But if I require that everyone define P in the first way, then Lambda should not be necessary, is that correct? Is there still a reason to use Lambda in that case? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.683 / Virus Database: 445 - Release Date: 5/12/2004
Just to clarify, we're talking about mpl::lambda here. "David B. Held" <dheld@codelogicconsulting.com> writes:
Ok, suppose we have a policy-based class Foo, and a policy P:
template <typename Policy> class Foo { // ... };
struct P { template <typename T> struct apply { typedef policy type; }; };
P is a "metafunction class"
Now, my understanding is that we can use Lambda so that we can invoke Foo this way:
Foo<P> f;
for some definition of "invoke" ;-)
Or define P in this way:
template <typename T> struct P { // policy };
P is a "metafunction"
and call Foo this way:
For some defintion of "call" ;-)
Foo<P<_> > f;
P<_> is a "lambda expression"
But if I require that everyone define P in the first way, then Lambda should not be necessary, is that correct? Is there still a reason to use Lambda in that case?
In the upcoming version of MPL (very soon now) mpl::apply -- which you'll want to use even to invoke metafunction classes portably (no, using P::template apply<whatever>::type doesn't work everywhere) -- will invoke mpl::lambda internally, so the upshot is that passing either lambda expressions or metafunction classes will work. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u4qqiep5w.fsf@boost-consulting.com...
Just to clarify, we're talking about mpl::lambda here.
Right.
"David B. Held" <dheld@codelogicconsulting.com> writes:
[...]
Now, my understanding is that we can use Lambda so that we can invoke Foo this way:
Foo<P> f;
for some definition of "invoke" ;-)
I like to think of "operator<>" as the "metafunction call operator". ;> It helps me to think of it in a more MPL-like way.
[...] In the upcoming version of MPL (very soon now) mpl::apply -- which you'll want to use even to invoke metafunction classes portably (no, using P::template apply<whatever>::type doesn't work everywhere) --
Really? Where does that not work?
will invoke mpl::lambda internally, so the upshot is that passing either lambda expressions or metafunction classes will work.
Cool. Is "Real Soon Now(TM)" within the next month? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.683 / Virus Database: 445 - Release Date: 5/12/2004
"David B. Held" <dheld@codelogicconsulting.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u4qqiep5w.fsf@boost-consulting.com...
Just to clarify, we're talking about mpl::lambda here.
Right.
"David B. Held" <dheld@codelogicconsulting.com> writes:
[...]
Now, my understanding is that we can use Lambda so that we can invoke Foo this way:
Foo<P> f;
for some definition of "invoke" ;-)
I like to think of "operator<>" as the "metafunction call operator". ;> It helps me to think of it in a more MPL-like way.
You're misleading yourself, then. "::type" is the metafunction call operator. "operator<>" is just used for argument binding.
[...] In the upcoming version of MPL (very soon now) mpl::apply -- which you'll want to use even to invoke metafunction classes portably (no, using P::template apply<whatever>::type doesn't work everywhere) --
Really? Where does that not work?
VC6/7
will invoke mpl::lambda internally, so the upshot is that passing either lambda expressions or metafunction classes will work.
Cool. Is "Real Soon Now(TM)" within the next month?
I think so; Aleksey? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams writes:
In the upcoming version of MPL (very soon now) mpl::apply -- which you'll want to use even to invoke metafunction classes portably (no, using P::template apply<whatever>::type doesn't work everywhere) --
Really? Where does that not work?
VC6/7
will invoke mpl::lambda internally, so the upshot is that passing either lambda expressions or metafunction classes will work.
Cool. Is "Real Soon Now(TM)" within the next month?
I think so; Aleksey?
Yes, of course. It's going in the upcoming release (which I'll start to take care of within a week or so). It's already implemented, in the "mplbook" branch. -- Aleksey Gurtovoy MetaCommunications Engineering
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote
Yes, of course. It's going in the upcoming release (which I'll start to take care of within a week or so). It's already implemented, in the "mplbook" branch.
Will it have O(1) push_front/back operations for mpl::vector/list? Thanks, Arkadiy
Arkadiy Vertleyb writes:
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote
Yes, of course. It's going in the upcoming release (which I'll start to take care of within a week or so). It's already implemented, in the "mplbook" branch.
Will it have O(1) push_front/back operations for mpl::vector/list?
For the 'vector', yes. 'list' will remain to be a front-extensible sequence only. -- Aleksey Gurtovoy MetaCommunications Engineering
participants (4)
-
Aleksey Gurtovoy -
Arkadiy Vertleyb -
David Abrahams -
David B. Held