Just trying to use mpl::transform on a vector of int's and I can't seem to get it working properly. Can anyone see what's wrong?? I'm trying to perform vector_c<int, 1, 2, 3> + vector_c<int, 1, 1, 1> = vector_c<int, 2, 3 ,4> The is_same function always returns false when I compile and run it. ------------------- typedef mpl::vector_c<int, 1, 2, 3> type_a; typedef mpl::vector_c<int, 1, 1, 1> type_b; struct plus_f { template<class A, class B> struct apply { typedef typename mpl::plus<A, B>::type type; }; }; typedef mpl::transform<type_a, type_b, plus_f >::type result_type; std::cerr << "True " << boost::is_same<result_type, mpl::vector_c<int, 2, 3, 4> >::value << std::endl; __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Lucio Flores <dogboy_l@yahoo.com> writes:
Just trying to use mpl::transform on a vector of int's and I can't seem to get it working properly. Can anyone see what's wrong?? I'm trying to perform
vector_c<int, 1, 2, 3> + vector_c<int, 1, 1, 1> = vector_c<int, 2, 3 ,4>
The is_same function always returns false when I compile and run it.
The result of the transform is only required to be "concept-identical" to the result you're looking for. http://www.boost.org/libs/mpl/doc/refmanual/terminology.html So you almost never want to use is_same to compare sequences. usually the equal algorithm is a more appropriate choice: http://www.boost.org/libs/mpl/doc/refmanual/equal.html P.S. <plug> I recommend http://www.boost-consulting.com/mplbook for MPL newbies </plug> HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com
Hi, I have the code which copy from a STL list to another if a condition is met: list<A*> alist; for (list<A*>::iterator iter = alist.begin(); iter != alist.end(); ++iter) { A* a = (*iter); if ( a->aFunc( i, j) { destList.push_back(a); } } I try doing this, but it does not compile: for_each(alist.begin(), alist.end(), if_then( bind(&A::aFunc, _1 , i, j ), columnBlocks.push_back(_1))); There are my errors: error: no matching function for call to âstd::vector<A*, std::allocator<A*>
::push_back(const boost::lambda::lambda_functor<boost::lambda::placeholder<1> &) error: âif_thenâ was not declared in this scope
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On 2/24/06, yinglcs2@yahoo.com <yinglcs2@yahoo.com> wrote:
Hi,
I have the code which copy from a STL list to another if a condition is met:
list<A*> alist;
for (list<A*>::iterator iter = alist.begin(); iter != alist.end(); ++iter) {
A* a = (*iter);
if ( a->aFunc( i, j) { destList.push_back(a); } }
I try doing this, but it does not compile:
for_each(alist.begin(), alist.end(), if_then( bind(&A::aFunc, _1 , i, j ), columnBlocks.push_back(_1)));
There are my errors:
error: no matching function for call to 'std::vector<A*, std::allocator<A*>
::push_back(const boost::lambda::lambda_functor<boost::lambda::placeholder<1> &) error: 'if_then' was not declared in this scope
1. Have you included the correct header (boost/lambda/if.hpp). 2. You'll have to bind the push_back call as well: bind(&list<A*>::push_back, columnBlocks, _1) HTH Stuart Dootson
"David Abrahams" writes
The result of the transform is only required to be "concept-identical" to the result you're looking for.
IMO that behaviour is sloppy. I see no reason why (at least) boost::is_same < plus< int_<1> ,int_<1> >::type, int_<2> > shouldnt be true. mpl models itself on runtime C++ but in this case it deviates from following runtime behaviour for no real benefit. Note also that tightening the behaviour wouldnt break any conforming code ;-) regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" writes
The result of the transform is only required to be "concept-identical" to the result you're looking for.
IMO that behaviour is sloppy. I see no reason why (at least)
boost::is_same < plus< int_<1> ,int_<1> >::type, int_<2> > shouldnt be true.
Patches welcome, and all that. If you can figure out how to do it without greatly complicating the library, I'm sure Aleksey would be glad to adopt your code. Until then, I'll thank you not to sling words like "sloppy" around so blithely.
mpl models itself on runtime C++ but in this case it deviates from following runtime behaviour for no real benefit. Note also that tightening the behaviour wouldnt break any conforming code ;-)
In the user's case, the real benefit is that it drastically reduces the number of lines of implementation code in the library, which has a real impact on the library's usability. vector<int_<1>, int_<2> > vector<integral_c<int,1>, integral_c<int,2> > vector_c<int, 1, 2> are all different types, and they always will be. There's nothing we can do about that, period. Arranging it so that you always get the exact type you expect would require a great deal more code than we're using now, and may not even be possible. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" writes
The result of the transform is only required to be "concept-identical" to the result you're looking for.
IMO that behaviour is sloppy. I see no reason why (at least)
boost::is_same < plus< int_<1> ,int_<1> >::type, int_<2> > shouldnt be true.
Patches welcome, and all that. If you can figure out how to do it without greatly complicating the library, I'm sure Aleksey would be glad to adopt your code.
I'd question this decision. Code that assumes that plus< int_<1>, int_<2>
::type is int_<3> is by definition more limited than code that handles any result as long as its ::value is 3. But feel free to take my comments with a grain of salt as I'm not familiar with MPL.
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:000c01c63940$5b10b6b0$6407a8c0@pdimov2...
David Abrahams wrote:
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" writes
The result of the transform is only required to be "concept-identical" to the result you're looking for.
IMO that behaviour is sloppy. I see no reason why (at least)
boost::is_same < plus< int_<1> ,int_<1> >::type, int_<2> > shouldnt be true.
Patches welcome, and all that. If you can figure out how to do it without greatly complicating the library, I'm sure Aleksey would be glad to adopt your code.
I'd question this decision. Code that assumes that plus< int_<1>, int_<2>
::type is int_<3> is by definition more limited than code that handles any result as long as its ::value is 3.
int_<1> and int_<2> are types not concepts. What other type can *more advantageously* be returned here bearing in mind that currently I get an integral_c<int,N> back? regards Andy Little
"David Abrahams" wrote
"Andy Little" wrote
"David Abrahams" writes
The result of the transform is only required to be "concept-identical" to the result you're looking for.
IMO that behaviour is sloppy. I see no reason why (at least)
boost::is_same < plus< int_<1> ,int_<1> >::type, int_<2> > shouldnt be true.
Patches welcome, and all that. If you can figure out how to do it without greatly complicating the library, I'm sure Aleksey would be glad to adopt your code. Until then, I'll thank you not to sling words like "sloppy" around so blithely.
What can I say? I acknowledge that mpl is a monumental piece of work . Wonderful... but far from perfect. In this case it looks trivial to change the int_ plus behaviour... #include <boost/mpl/int.hpp> #include <boost/mpl/plus.hpp> namespace boost{namespace mpl{ template <int N1, int N2 /* Nn...*/> struct plus<int_<N1>,int_<N2> /* Nn...*/>{ typedef int_< N1 + N2 /* Nn...*/> type; }; }} #include <iostream> int main() { using boost::mpl::plus; using boost::mpl::int_; typedef plus<int_<1>,int_<2> >::type res; std::cout << typeid(res).name() <<'\n'; } /* output: boost::mpl::int_<3> */ Meanwhile mpl causes other work dependent on it ( see below) to be more complicated to suit it. This seems to have been done this way because it makes the implementors life a bit easier ( as you allude to below), but the user suffers IMO because mpl doesnt follow the golden rule of least surprise ( again as you allude to below) in this case as the OP has discovered!
mpl models itself on runtime C++ but in this case it deviates from following runtime behaviour for no real benefit. Note also that tightening the behaviour wouldnt break any conforming code ;-)
In the user's case, the real benefit is that it drastically reduces the number of lines of implementation code in the library, which has a real impact on the library's usability.
All I can say is that I was *a user*. It certainly had an effect on useability of my pqs library. It had a huge effect on compile times because large complicated templates **representing the same sequence** kept being differently represented. There was a jump in compilation times from typically 4 seconds to 30 or so, as well as getting Fatal error messages from the compiler on relatively small code samples that the compiler had run out of keys. The use of mpl turned the pqs library from something enjoyable to use to something unusable. I am much happier now that I have all but eliminated use of mpl in my physical quantities library . Having submitted pqs into the review queue I am sure this question of why I am not using mpl is going to come up and may cause the library to be blindly rejected, so I am going to start fighting back now!
vector<int_<1>, int_<2> >
vector<integral_c<int,1>, integral_c<int,2> >
vector_c<int, 1, 2>
are all different types, and they always will be. There's nothing we can do about that, period.
That shouldnt stop discussion of whether it is the best design. Arranging it so that you always get the
exact type you expect would require a great deal more code than we're using now, and may not even be possible.
I shall continue to question whether it is the best design. I dont know whether there are plans to C++ standardise any of mpl , but I would certainly like to raise that and some other issues in that case. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
I shall continue to question whether it is the best design. I dont know whether there are plans to C++ standardise any of mpl , but I would certainly like to raise that and some other issues in that case.
Question all you want as far as I'm concerned. Until you can propose a technically superior solution to the problem of sequence identity, it won't make any difference, because the authors of MPL have already tried, and failed, to find one. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ud5hcene3.fsf@boost-consulting.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
I shall continue to question whether it is the best design. I dont know whether there are plans to C++ standardise any of mpl , but I would certainly like to raise that and some other issues in that case.
Question all you want as far as I'm concerned. Until you can propose a technically superior solution to the problem of sequence identity, it won't make any difference, because the authors of MPL have already tried, and failed, to find one.
I am not concerned with the intractible problem of sequence identity ( whatever that means) at the moment. What is the problem with the result of plus<int_<A>,int_<B>> being int_<A+B> ? regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ud5hcene3.fsf@boost-consulting.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
I shall continue to question whether it is the best design. I dont know whether there are plans to C++ standardise any of mpl , but I would certainly like to raise that and some other issues in that case.
Question all you want as far as I'm concerned. Until you can propose a technically superior solution to the problem of sequence identity, it won't make any difference, because the authors of MPL have already tried, and failed, to find one.
I am not concerned with the intractible problem of sequence identity ( whatever that means) at the moment.
Then what was this indictment about? Me:
The result of the transform is only required to be "concept-identical" to the result you're looking for.
You: IMO that behaviour is sloppy.
What is the problem with the result of plus<int_<A>,int_<B>> being int_<A+B> ?
I don't know if there are any serious problems with it, but I'm guessing it would mean the addition of a number of specializations, and additional ugly workarounds to support broken compilers. And, of course, the bigger problem is that we don't have a. A patch implementing it b. Tests to verify that the patch worked c. Time to implement it ourselves right now The extra code may or may not be an obstacle to inclusion. I can't speak for Aleksey, but I guess that to know, he'd have to see the patch. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" wrote
"Andy Little" writes
I am not concerned with the intractible problem of sequence identity ( whatever that means) at the moment.
Then what was this indictment about?
Me:
The result of the transform is only required to be "concept-identical" to the result you're looking for.
You: IMO that behaviour is sloppy.
What can I say? I acknowledge that mpl is a monumental piece of work . Wonderful... but far from perfect. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" wrote
"Andy Little" writes
I am not concerned with the intractible problem of sequence identity ( whatever that means) at the moment.
Then what was this indictment about?
Me:
The result of the transform is only required to be "concept-identical" to the result you're looking for.
You: IMO that behaviour is sloppy.
What can I say? I acknowledge that mpl is a monumental piece of work . Wonderful... but far from perfect.
I don't think the fact that it's imperfect gives you the right to label any arbitrary design decision as sloppy. You seem to have no justification at all for calling the behavior mentioned above "sloppy," notwithstanding that it reminds you of another behavior that you dislike. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" wrote
"Andy Little" writes
"David Abrahams" wrote
"Andy Little" writes
I am not concerned with the intractible problem of sequence identity ( whatever that means) at the moment.
Then what was this indictment about?
Me:
The result of the transform is only required to be "concept-identical" to the result you're looking for.
You: IMO that behaviour is sloppy.
What can I say? I acknowledge that mpl is a monumental piece of work . Wonderful... but far from perfect.
I don't think the fact that it's imperfect gives you the right to label any arbitrary design decision as sloppy.
I dont follow? "any arbitrary decision"?
You seem to have no justification at all for calling the behavior mentioned above "sloppy," notwithstanding that it reminds you of another behavior that you dislike.
The behaviour of having a return type defined as a concept rather than a type in this case is unnecessarily imprecise. In practise (Based on my experience in pqs physical quantities library) it causes an explosion of arbitrary types all meaning the same thing. This in turn leads to slow compile times and overuse of compiler resources and with the fatal effect in some cases, that the compiler cannot cope resulting in a failed compilation. An alternative suggestion is to explicitly specify what seems to be the actual behaviour of arithmetic operations on int_'s, long's etc in the documentation. The actual behaviour seems to be that these functions invariably return an integral_c. It could then also be specified that the value_type of the result is found by applying the usual promotion rules to the types of each of the (non mpl::na) arguments. That would at least tighten up any play in the current specification. In order to get the desired behaviour it would then be a question of only using integral_c's of one value_type. Having said the above its not actually that important to me what mpl does to be honest. I only use it in trivial ways in pqs. Having put it in and taken it of the library out a couple of times I have found I am happier without it, and would be very reluctant to put it back in again. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" wrote
"Andy Little" writes
"David Abrahams" wrote
"Andy Little" writes
I am not concerned with the intractible problem of sequence identity ( whatever that means) at the moment.
Then what was this indictment about?
Me:
The result of the transform is only required to be "concept-identical" to the result you're looking for.
You: IMO that behaviour is sloppy.
What can I say? I acknowledge that mpl is a monumental piece of work . Wonderful... but far from perfect.
I don't think the fact that it's imperfect gives you the right to label any arbitrary design decision as sloppy.
I dont follow? "any arbitrary decision"?
Yes, in this case the particular design decision that transform<some_template< ... > >::type may not always be a specialization of some_template.
You seem to have no justification at all for calling the behavior mentioned above "sloppy," notwithstanding that it reminds you of another behavior that you dislike.
The behaviour of having a return type defined as a concept rather than a type in this case is unnecessarily imprecise.
You haven't proven that about transform, which is the case in question.
In practise (Based on my experience in pqs physical quantities library) it causes an explosion of arbitrary types all meaning the same thing. This in turn leads to slow compile times and overuse of compiler resources and with the fatal effect in some cases, that the compiler cannot cope resulting in a failed compilation.
An alternative suggestion is to explicitly specify what seems to be the actual behaviour of arithmetic operations on int_'s, long's etc in the documentation.
Stop. The statement in question is about transform, not about int_'s, long_'s, etc. You condemned Aleksey's design decision about the result of transform and have repeatedly claimed that it is unnecessary and could easily be done better. Please demonstrate, or retract your claim. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" wrote
"Andy Little"writes:
"David Abrahams" wrote
"Andy Little" writes
"David Abrahams" wrote
"Andy Little" writes
I am not concerned with the intractible problem of sequence identity ( whatever that means) at the moment.
Then what was this indictment about?
Me:
The result of the transform is only required to be "concept-identical" to the result you're looking for.
You: IMO that behaviour is sloppy.
What can I say? I acknowledge that mpl is a monumental piece of work . Wonderful... but far from perfect.
I don't think the fact that it's imperfect gives you the right to label any arbitrary design decision as sloppy.
I dont follow? "any arbitrary decision"?
Yes, in this case the particular design decision that
transform<some_template< ... > >::type
may not always be a specialization of some_template.
You seem to have no justification at all for calling the behavior mentioned above "sloppy," notwithstanding that it reminds you of another behavior that you dislike.
The behaviour of having a return type defined as a concept rather than a type in this case is unnecessarily imprecise.
You haven't proven that about transform, which is the case in question.
In practise (Based on my experience in pqs physical quantities library) it causes an explosion of arbitrary types all meaning the same thing. This in turn leads to slow compile times and overuse of compiler resources and with the fatal effect in some cases, that the compiler cannot cope resulting in a failed compilation.
An alternative suggestion is to explicitly specify what seems to be the actual behaviour of arithmetic operations on int_'s, long's etc in the documentation.
Stop. The statement in question is about transform, not about int_'s, long_'s, etc. You condemned Aleksey's design decision about the result of transform and have repeatedly claimed that it is unnecessary and could easily be done better. Please demonstrate, or retract your claim.
I think we need a little bit more context here.
OP David Abrahams Andy Little (me) Just trying to use mpl::transform on a vector of int's and I can't seem to get it working properly. Can anyone see what's wrong?? I'm trying to perform
vector_c<int, 1, 2, 3> + vector_c<int, 1, 1, 1> = vector_c<int, 2, 3 ,4>
The is_same function always returns false when I compile and run it.
The result of the transform is only required to be "concept-identical" to the result you're looking for.
IMO that behaviour is sloppy. I see no reason why (at least)
boost::is_same < plus< int_<1> ,int_<1> >::type, int_<2> > shouldnt be true.
Your change from "the transform" to "being about transform" above is problematic for me. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
I think we need a little bit more context here.
OP David Abrahams
Andy Little (me)
Just trying to use mpl::transform on a vector of int's and I can't seem to get it working properly. Can anyone see what's wrong?? I'm trying to perform
vector_c<int, 1, 2, 3> + vector_c<int, 1, 1, 1> = vector_c<int, 2, 3 ,4>
The is_same function always returns false when I compile and run it.
The result of the transform is only required to be "concept-identical" to the result you're looking for.
IMO that behaviour is sloppy. I see no reason why (at least)
boost::is_same < plus< int_<1> ,int_<1> >::type, int_<2> > shouldnt be true.
Your change from "the transform" to "being about transform" above is problematic for me.
I don't know what you mean. Nobody wrote "the transform" above. Don't make this complicated. It is very simple: I made a statemnt *about the behavior of transform*, and you replied "that behavior is sloppy," and then proceeded to go on about something only distantly related (the type of results of arithmetic operations). The behavior I was describing is not sloppy. To make the library behave differently would introduce a huge overhead in implementation code that is more likely than not to slow down compilation of user programs. Let me be a little more explicit: transform<vector_c<int, ...> >::type is likely to be a specialization of vectorN where N is a numeral. Therefore, testing it against a vector_c specialization using is_same will always fail. That is the behavior I was referring to. I wouldn't care much what you said, except for that you're doing this in a thread where impressionable "newbies" are reading, and I don't want them to misunderstand the library design or the implementation decisions and their costs/benefits. Your statement above not only unfairly maligns Aleksey's work, it is misleading. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" wrote
"Andy Little" writes:
I wouldn't care much what you said, except for that you're doing this in a thread where impressionable "newbies" are reading, and I don't want them to misunderstand the library design or the implementation decisions and their costs/benefits.
I can continue in private if you wish ? regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" wrote
"Andy Little" writes:
I wouldn't care much what you said, except for that you're doing this in a thread where impressionable "newbies" are reading, and I don't want them to misunderstand the library design or the implementation decisions and their costs/benefits.
I can continue in private if you wish ?
If you feel the need to continue to label the transform behavior as sloppy without justification, then that would be better. Otherwise, either explain how transform could be better or, please, just retract your remark about the behavior of transform for the record. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u3bi7705a.fsf@boost-consulting.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" wrote
"Andy Little" writes:
I wouldn't care much what you said, except for that you're doing this in a thread where impressionable "newbies" are reading, and I don't want them to misunderstand the library design or the implementation decisions and their costs/benefits.
I can continue in private if you wish ?
If you feel the need to continue to label the transform behavior as sloppy without justification, then that would be better. Otherwise, either explain how transform could be better or, please, just retract your remark about the behavior of transform for the record.
I retract the remark which referred to mpl::transform as sloppy. I offer my sincere apologies to anyone who may have taken offense. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u3bi7705a.fsf@boost-consulting.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" wrote
"Andy Little" writes:
I wouldn't care much what you said, except for that you're doing this in a thread where impressionable "newbies" are reading, and I don't want them to misunderstand the library design or the implementation decisions and their costs/benefits.
I can continue in private if you wish ?
If you feel the need to continue to label the transform behavior as sloppy without justification, then that would be better. Otherwise, either explain how transform could be better or, please, just retract your remark about the behavior of transform for the record.
I retract the remark which referred to mpl::transform as sloppy. I offer my sincere apologies to anyone who may have taken offense.
Thank you, that helps focus the discussion. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Andy Little wrote:
An alternative suggestion is to explicitly specify what seems to be the actual behaviour of arithmetic operations on int_'s, long's etc in the documentation. The actual behaviour seems to be that these functions invariably return an integral_c. It could then also be specified that the value_type of the result is found by applying the usual promotion rules to the types of each of the (non mpl::na) arguments. That would at least tighten up any play in the current specification.
Isn't this what the docs already seem to say? http://www.boost.org/libs/mpl/doc/refmanual/plus.html
"Peter Dimov" wrote
Andy Little wrote:
An alternative suggestion is to explicitly specify what seems to be the actual behaviour of arithmetic operations on int_'s, long's etc in the documentation. The actual behaviour seems to be that these functions invariably return an integral_c. It could then also be specified that the value_type of the result is found by applying the usual promotion rules to the types of each of the (non mpl::na) arguments. That would at least tighten up any play in the current specification.
Isn't this what the docs already seem to say?
Nearly but not specifically Return type: Integral Constant (Concept.) Maybe it could be changed to (something like) Return type: integral_c< typeof(c1::value + c2::value) , ( c1::value + c2::value ) > c; This would guarantee that is_same can be used on the result. Currently I cant assume that. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
Maybe it could be changed to (something like)
Return type: integral_c< typeof(c1::value + c2::value) , ( c1::value + c2::value ) > c;
This would guarantee that is_same can be used on the result. Currently I cant assume that.
You seem to have a deep misunderstanding of the problem. is_same< int_<3>, integral_c<int,3> >::value is false. They are different types. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" wrote
"Andy Little" writes:
Maybe it could be changed to (something like)
Return type: integral_c< typeof(c1::value + c2::value) , ( c1::value + c2::value ) > c;
This would guarantee that is_same can be used on the result. Currently I cant assume that.
You seem to have a deep misunderstanding of the problem.
Do I ..........? ;-)
is_same< int_<3>, integral_c<int,3> >::value
is false. They are different types.
Really ? Knock me down wiv a feather guvnor! typedef mpl::plus<mpl::bool_<true>,mpl::bool_<true> >::type type1; typedef mpl::plus<mpl::int_<1>,mpl::int_<1> >::type type2; typedef mpl::plus<mpl::long_<1>,mpl::long_<1> >::type type3; typedef mpl::plus<mpl::integral_c<int,1>,mpl::integral_c<long,1>
::type type4;
assert((boost::is_same<type1, mpl::integral_c<bool,true> >::value)); assert((boost::is_same<type2, mpl::integral_c<int,2> >::value)); assert((boost::is_same<type3, mpl::integral_c<long,2> >::value)); assert((boost::is_same<type4, mpl::integral_c<long,2> >::value)); You might try reading the context in which that was said ........:-) (< hint > look in <boost/mpl/aux_/arithmetic_op.hpp> .......;-) regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" wrote
"Andy Little" writes:
Maybe it could be changed to (something like)
Return type: integral_c< typeof(c1::value + c2::value) , ( c1::value + c2::value ) > c;
This would guarantee that is_same can be used on the result. Currently I cant assume that.
You seem to have a deep misunderstanding of the problem.
Do I ..........? ;-)
Yes, you seem to.
is_same< int_<3>, integral_c<int,3> >::value
is false. They are different types.
Really ? Knock me down wiv a feather guvnor!
Ah, the distinctive musk of sarcasm.
typedef mpl::plus<mpl::bool_<true>,mpl::bool_<true> >::type type1; typedef mpl::plus<mpl::int_<1>,mpl::int_<1> >::type type2; typedef mpl::plus<mpl::long_<1>,mpl::long_<1> >::type type3; typedef mpl::plus<mpl::integral_c<int,1>,mpl::integral_c<long,1>
::type type4;
assert((boost::is_same<type1, mpl::integral_c<bool,true> >::value)); assert((boost::is_same<type2, mpl::integral_c<int,2> >::value)); assert((boost::is_same<type3, mpl::integral_c<long,2> >::value)); assert((boost::is_same<type4, mpl::integral_c<long,2> >::value));
What is that supposed to illustrate? Your desires? Current behavior?
You might try reading the context in which that was said ........:-)
I did. You might try clearly explaining what you're after.
(< hint > look in <boost/mpl/aux_/arithmetic_op.hpp> .......;-)
I know what it looks like. I can see how what's specified in the manual is different from (less specific than) what I think you want, but I don't see how what is actually delivered is any different from what you want. Of course, exactly what you want is still unclear. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" wrote
"Andy Little" writes:
"David Abrahams" wrote
"Andy Little" writes:
Maybe it could be changed to (something like)
Return type: integral_c< typeof(c1::value + c2::value) , ( c1::value + c2::value ) > c;
This would guarantee that is_same can be used on the result. Currently I cant assume that.
You seem to have a deep misunderstanding of the problem.
Do I ..........? ;-)
Yes, you seem to.
In what way am I misunderstanding it?
is_same< int_<3>, integral_c<int,3> >::value
is false. They are different types.
Really ? Knock me down wiv a feather guvnor!
Ah, the distinctive musk of sarcasm.
No seriously. Thanks for the illuminating moment.
typedef mpl::plus<mpl::bool_<true>,mpl::bool_<true> >::type type1; typedef mpl::plus<mpl::int_<1>,mpl::int_<1> >::type type2; typedef mpl::plus<mpl::long_<1>,mpl::long_<1> >::type type3; typedef mpl::plus<mpl::integral_c<int,1>,mpl::integral_c<long,1>
::type type4;
assert((boost::is_same<type1, mpl::integral_c<bool,true> >::value)); assert((boost::is_same<type2, mpl::integral_c<int,2> >::value)); assert((boost::is_same<type3, mpl::integral_c<long,2> >::value)); assert((boost::is_same<type4, mpl::integral_c<long,2> >::value));
What is that supposed to illustrate? Your desires? Current behavior?
Surely its pretty obvious isnt it ?
You might try reading the context in which that was said ........:-)
I did. You might try clearly explaining what you're after.
I'm after a more precise solution, one that leaves .. how shall I put this tactfully?... slightly less room for doubt.
(< hint > look in <boost/mpl/aux_/arithmetic_op.hpp> .......;-)
I know what it looks like. I can see how what's specified in the manual is different from (less specific than) what I think you want,
Perhaps you'd like to clarify what you think I want?
but I don't see how what is actually delivered is any different from what you want. Of course, exactly what you want is still unclear.
I dont understand this especially after your previous remarks. Now you seem to be agreeing that what is delivered is unclear? I thought it couldnt be improved? regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
typedef mpl::plus<mpl::bool_<true>,mpl::bool_<true> >::type type1; typedef mpl::plus<mpl::int_<1>,mpl::int_<1> >::type type2; typedef mpl::plus<mpl::long_<1>,mpl::long_<1> >::type type3; typedef mpl::plus<mpl::integral_c<int,1>,mpl::integral_c<long,1>
::type type4;
assert((boost::is_same<type1, mpl::integral_c<bool,true> >::value)); assert((boost::is_same<type2, mpl::integral_c<int,2> >::value)); assert((boost::is_same<type3, mpl::integral_c<long,2> >::value)); assert((boost::is_same<type4, mpl::integral_c<long,2> >::value));
What is that supposed to illustrate? Your desires? Current behavior?
Surely its pretty obvious isnt it ?
Surely I wouldn't be asking if it were obvious to me.
You might try reading the context in which that was said ........:-)
I did. You might try clearly explaining what you're after.
I'm after a more precise solution, one that leaves .. how shall I put this tactfully?... slightly less room for doubt.
So it's just the specification that you want tightened, or do you want a different behavior? I'm sure the answer seems like it ought to be obvious to me, but it isn't, so kindly spell it out.
(< hint > look in <boost/mpl/aux_/arithmetic_op.hpp> .......;-)
I know what it looks like. I can see how what's specified in the manual is different from (less specific than) what I think you want,
Perhaps you'd like to clarify what you think I want?
It would be a lot simpler if you'd just spell it out. It seems like you have been asking for several different things at different times.
but I don't see how what is actually delivered is any different from what you want. Of course, exactly what you want is still unclear.
I dont understand this especially after your previous remarks. Now you seem to be agreeing that what is delivered is unclear?
No, read what I wrote. It's unclear to me what you want. I can't tell how it differs from the current behavior.
I thought it couldnt be improved?
Who ever said anything about arithmetic operations couldn't be improved? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" wrote
Andy Little wrote
What is the problem with the result of plus<int_<A>,int_<B>> being int_<A+B> ?
I don't know if there are any serious problems with it,
Is it in principle a better solution than the current solution? regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" wrote
Andy Little wrote
What is the problem with the result of plus<int_<A>,int_<B>> being int_<A+B> ?
I don't know if there are any serious problems with it,
Is it in principle a better solution than the current solution?
It depends what your principles are. And probably on the contents of the actual patch. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" wrote
"Andy Little" writes:
"David Abrahams" wrote
Andy Little wrote
What is the problem with the result of plus<int_<A>,int_<B>> being int_<A+B> ?
I don't know if there are any serious problems with it,
Is it in principle a better solution than the current solution?
It depends what your principles are. And probably on the contents of the actual patch.
Ok. I'll look into it. regards Andy Little
"Peter Dimov" wrote
Andy Little wrote:
What is the problem with the result of plus<int_<A>,int_<B>> being int_<A+B> ?
How does the specification of mpl::plus look like in your proposed model?
Firstly the signature : namespace boost{ namespace mpl{ template <typename Lhs, typename Rhs> struct plus; }} IOW the function doesnt have more than 2 parameters Rationale: The extra parameters are * unexpected * a nuisance when specialising for a UDT. * irrelevant in many uses eg with mpl::transform. * lengthen error messages. * more likely to overflow. I realise that would break existing code but I bring it up as a discussion point if mpl was ever the subject of standardisation for example. Secondly the type of the result As a workaround to the status quo I would suggest that where the first two parameters are of the same integral_constant template type and the rest arent specified by the user ( ie left as the default mpl::na), the template type of the result should be the same as the template type of the integral constant parameters. note: If the first modification was unacceptable then the rule could of course be extended to further numbers of integral_constant parameters, otherwise if the first modification was acceptable then the following code is still valid. Example typedef mpl::plus<mpl::int_<1>,mpl::int_<2> >::type int_two; assert((boost::is_same<int_two,mpl::int_<3> >::value)); typedef mpl::plus< mpl::integral_c<long,1>,mpl::integral_c<long,-1> >::type long_c_two; assert((boost::is_same< long_c_two,mpl::integral_c<long,0> >::value)); As a refinement promotion rules would add certainty in further cases of integral_constant combinations. The current spec gives an example indicating something similar with regard to value_type but AFAIK no wording. The same rules would apply to mpl::minus,mpl::times, mpl::divides, and logical operators etc As far as I know that is the extent of the modifications to the current spec. regards Andy Little
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Peter Dimov
Andy Little wrote:
What is the problem with the result of plus<int_<A>,int_<B>> being int_<A+B> ?
How does the specification of mpl::plus look like in your proposed model?
I don't think *this* it is necessarily difficult to implement as Andy would prefer. However, global application (to the MPL) of the underlying concept represents a major refactoring and the result would most likely be a lot slower. Dave was referring to the sequence identity problem because it is exactly the same kind of thing. There is a dinstinction between types on which metaprogramming operates (such as 'int' or 'const MyClass') and the types of metaprogramming constructs themselves. The latter need only be structurally compatible with the concept (i.e. the archtype or the Plutonic form of the structure). If the MPL starts making guarantees that metatypes (e.g. a 'vector', a 'list', an 'int_<A>') can be used as a non-metatype, it will lead to either 1) a combinatorial explosion of code or 2) a drastic efficiency hit (because the library will be explicitly rewriting structures after they are built). Granted, if this was done for integral wrappers only, the combinatorial explosion wouldn't be too terribly bad. IMO, you don't need wrappers for every integral type in this domain, you only need an integer wrapper (around 'long'), a natural wrapper (around 'unsigned long'), and a Boolean (around 'bool'). *But*, it still comes down to a more fundamental issue.... Should the library endorse the use of the types of metaprogramming constructs themselves as non-metatypes? I'd say it shouldn't. If you need that for 'int_<A+B>' (e.g.) then say 'int_<plus<int_<A>, int_<B> >::value>' Regards, Paul Mensonides
"Paul Mensonides" wrote
Peter Dimov wrote
Andy Little wrote:
What is the problem with the result of plus<int_<A>,int_<B>> being int_<A+B> ?
How does the specification of mpl::plus look like in your proposed model?
I don't think *this* it is necessarily difficult to implement as Andy would prefer. However, global application (to the MPL) of the underlying concept represents a major refactoring
Thats a practical problem, but shouldnt stop discussion of the design I hope!
and the result would most likely be a lot slower.
That is pure speculation(see below)!
Dave was referring to the sequence identity problem because it is exactly the same kind of thing.
I dont think it is, but the design of the primitives affects more or less the design of the sequences. The primitives are the building blocks.
There is a dinstinction between types on which metaprogramming operates (such as 'int' or 'const MyClass') and the types of metaprogramming constructs themselves. The latter need only be structurally compatible with the concept (i.e. the archtype or the Plutonic form of the structure). If the MPL starts making guarantees that metatypes (e.g. a 'vector', a 'list', an 'int_<A>') can be used as a non-metatype, it will lead to either 1) a combinatorial explosion of code or 2) a drastic efficiency hit (because the library will be explicitly rewriting structures after they are built).
I can only go from my experience in pqs where exactly the opposite has happened. After my mpl experience which resulted in an unusable library I redesigned the library around compile- time meta-constants which can be equality compared using is_same. This has dramatically speeded compilation compared with use of mpl (e.g 30 secs to 4 sec for a typical compile) And has solved the previous situation where VC7.1 compiler gave an out of keys message on relatively trivial test cases. Bear in mind what use of boost::is_same over boost::mpl::equal_to implies. It must mean that for a given comparative set the same or less types must be instantiated. That cant increase compile times. Further in the case where different types compare equal then as more complex types are built out of the primitives, then there is an O(N^N) explosion of types all representing the same thing. This is I believe what happened in pqs.
Granted, if this was done for integral wrappers only, the combinatorial explosion wouldn't be too terribly bad. IMO, you don't need wrappers for every integral type in this domain, you only need an integer wrapper (around 'long'), a natural wrapper (around 'unsigned long'), and a Boolean (around 'bool'). *But*, it still comes down to a more fundamental issue.... Should the library endorse the use of the types of metaprogramming constructs themselves as non-metatypes? I'd say it shouldn't. If you need that for 'int_<A+B>' (e.g.) then say 'int_<plus<int_<A>, int_<B> >::value>'
I believe it is a case of more complexity in the primitives resulting in greater simplicity overall. regards Andy Little
On Feb 24, 2006, at 4:00 PM, Andy Little wrote:
"Paul Mensonides" wrote
There is a dinstinction between types on which metaprogramming operates (such as 'int' or 'const MyClass') and the types of metaprogramming constructs themselves. The latter need only be structurally compatible with the concept (i.e. the archtype or the Plutonic form of the structure). If the MPL starts making guarantees that metatypes (e.g. a 'vector', a 'list', an 'int_<A>') can be used as a non-metatype, it will lead to either 1) a combinatorial explosion of code or 2) a drastic efficiency hit (because the library will be explicitly rewriting structures after they are built).
I can only go from my experience in pqs where exactly the opposite has happened. After my mpl experience which resulted in an unusable library I redesigned the library around compile- time meta-constants which can be equality compared using is_same. This has dramatically speeded compilation compared with use of mpl (e.g 30 secs to 4 sec for a typical compile) And has solved the previous situation where VC7.1 compiler gave an out of keys message on relatively trivial test cases.
Andy, I'm just curious but what kind of test are these numbers (30 -> 4 seconds) measuring? After buying Dave and Aleksy's MPL book, I went ahead and implemented the quantity<T,D> prototype they proposed to do dimensional analysis, then added unit support, enforcement and conversion, but not automatic conversion and also added support for dimensionless numbers. I have, in my mind's eye, a very full featured pqs-like system that relies heavily on mpl and I've not seen any sort of compile speed problems like you report. -- Noel
What is the easiest way to use boost::lambda library with count_if to count how many item is less than 0.05? I try the following, but that not work: int no = count_if(myList.begin() myList.end(), _1 < 0.05); __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
yinglcs2@yahoo.com wrote:
What is the easiest way to use boost::lambda library with count_if to count how many item is less than 0.05?
I try the following, but that not work: int no = count_if(myList.begin() myList.end(), _1 < 0.05);
I think we are going to need more information. Can you provide more of the code? This looks fine except you are doing a literal floating point comparison. Be careful with literal floating point comparisons in general. KevinH -- Kevin Heifner heifner @ ociweb.com http://heifner.blogspot.com Object Computing, Inc. (OCI) www.ociweb.com
Sorry, you are right. that code compiles fine. I made a mistake somewhere else. You mention "be careful with literal floating point comparisons in general.". I thought doing float point == comparision is bad. But I am just doing less than (<), so i am okay. Is that true? --- Kevin Heifner <heifner_k@ociweb.com> wrote:
What is the easiest way to use boost::lambda
yinglcs2@yahoo.com wrote: library
with count_if to count how many item is less than 0.05?
I try the following, but that not work: int no = count_if(myList.begin() myList.end(), _1 < 0.05);
I think we are going to need more information. Can you provide more of the code? This looks fine except you are doing a literal floating point comparison. Be careful with literal floating point comparisons in general.
KevinH -- Kevin Heifner heifner @ ociweb.com http://heifner.blogspot.com Object Computing, Inc. (OCI) www.ociweb.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
yinglcs2@yahoo.com wrote:
You mention "be careful with literal floating point comparisons in general.". I thought doing float point == comparision is bad. But I am just doing less than (<), so i am okay. Is that true?
Depends. If you don't mind d < 0.05 being true sometimes when d ~= 0.05 then you don't have a problem. Just like with == comparison, your literal double value may not be represented as the exact literal value. KevinH -- Kevin Heifner heifner @ ociweb.com http://heifner.blogspot.com Object Computing, Inc. (OCI) www.ociweb.com
You might want to avoid replying to emails when you really want to start a new thread. Many of us access this list via gmane and a newsgroup reader. Your post gets buried under an entirely unrelated thread topic so you might not get the visibility you desire, and it dirupts that unrelated thread for those following it. Thanks, Jeff Flinn
"Noel Belcourt" wrote
I'm just curious but what kind of test are these numbers (30 -> 4 seconds) measuring?
After buying Dave and Aleksy's MPL book, I went ahead and implemented the quantity<T,D> prototype they proposed to do dimensional analysis, then added unit support, enforcement and conversion, but not automatic conversion and also added support for dimensionless numbers. I have, in my mind's eye, a very full featured pqs-like system that relies heavily on mpl and I've not seen any sort of compile speed problems like you report.
If that is the case that is great. Is there any chance of seeing the library? regards Andy Little
On Feb 25, 2006, at 12:49 AM, Andy Little wrote:
"Noel Belcourt" wrote
I'm just curious but what kind of test are these numbers (30 -> 4 seconds) measuring?
After buying Dave and Aleksy's MPL book, I went ahead and implemented the quantity<T,D> prototype they proposed to do dimensional analysis, then added unit support, enforcement and conversion, but not automatic conversion and also added support for dimensionless numbers. I have, in my mind's eye, a very full featured pqs-like system that relies heavily on mpl and I've not seen any sort of compile speed problems like you report.
If that is the case that is great. Is there any chance of seeing the library?
Yeah, it can be done but it may take a little effort. There's no documentation of any kind except for one line comments preceding the BOOST_STATIC_ASSERT's scattered throughout the code. And where do I put it, in the sandbox? -- Noel
"Noel Belcourt" wrote
On Feb 25, 2006, at 12:49 AM, Andy Little wrote:
"Noel Belcourt" wrote
I'm just curious but what kind of test are these numbers (30 -> 4 seconds) measuring?
After buying Dave and Aleksy's MPL book, I went ahead and implemented the quantity<T,D> prototype they proposed to do dimensional analysis, then added unit support, enforcement and conversion, but not automatic conversion and also added support for dimensionless numbers. I have, in my mind's eye, a very full featured pqs-like system that relies heavily on mpl and I've not seen any sort of compile speed problems like you report.
If that is the case that is great. Is there any chance of seeing the library?
Yeah, it can be done but it may take a little effort. There's no documentation of any kind except for one line comments preceding the BOOST_STATIC_ASSERT's scattered throughout the code. And where do I put it, in the sandbox?
Yes, but I think its called the boost vault now. regards Andy Little
"Noel Belcourt" wrote
I'm just curious but what kind of test are these numbers (30 -> 4 seconds) measuring?
FWIW I have put pqs_3_0_1 back in The vault in Physical Constants Units directory. This version used mpl heavily and had huge compile times. Last I remember is that it was only tested in VC7.1. Also requires mpl_math.zip in the vault for mpl::rational and needs replacement of boost/mpl/aux/has_type.hpp the original of which had obscure order of header inclusion issues. The figures I stated are as I remember them. I have no interest in retesting them. In fact I shudder at the thought of compiling this version again :-( Feel free to provide more accurate figures comparing this version with pqs_3_0_6. regards Andy Little
"Noel Belcourt" <kbelco@sandia.gov> writes:
After buying Dave and Aleksy's MPL book, I went ahead and implemented the quantity<T,D> prototype they proposed to do dimensional analysis, then added unit support, enforcement and conversion, but not automatic conversion and also added support for dimensionless numbers. I have, in my mind's eye, a very full featured pqs-like system that relies heavily on mpl and I've not seen any sort of compile speed problems like you report.
Noel, "In my mind's eye" usally means it's imaginary. I don't think that's really what you mean to say, is it? -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Feb 25, 2006, at 5:01 AM, David Abrahams wrote:
"Noel Belcourt" <kbelco@sandia.gov> writes:
After buying Dave and Aleksy's MPL book, I went ahead and
I meant Aleksey, sorry about that.
implemented the quantity<T,D> prototype they proposed to do dimensional analysis, then added unit support, enforcement and conversion, but not automatic conversion and also added support for dimensionless numbers. I have, in my mind's eye, a very full featured pqs-like system that relies heavily on mpl and I've not seen any sort of compile speed problems like you report.
Noel,
"In my mind's eye" usally means it's imaginary. I don't think that's really what you mean to say, is it?
No, what I meant to imply was that "my own impression of what I built is full featured ..." -- Noel
"Paul Mensonides" wrote
*But*, it still comes down to a more fundamental issue.... Should the library endorse the use of the types of metaprogramming constructs themselves as non-metatypes? I'd say it shouldn't. If you need that for 'int_<A+B>' (e.g.) then say 'int_<plus<int_<A>, int_<B> >::value>'
That wont work if you need to use pass the function to another function. regards Andy Little
So as an exercise, I'm trying to use a lambda expression that applies the first argument twice on it's second argument. typedef mpl::apply<_1, mpl::apply<_1, _2>::type>::type twice_type; Then I instance this lambda function on boost::add_pointer and int typedef mpl::apply<twice_type, boost::add_pointer<_1>, int>::type result_type; But using boost::is_same, I've found that result_type==int, not int** as expected. Can someone see why? ------------------------------------------- Manson: My philosophy is: Don't think. I don't believe in the mind that you think with and scheme with. I don't believe in words. Reporter: If you don't believe in words, why do you use so many of them? Manson: Words are symbols. All I'm doing is jumbling the symbols in your brain. Everything is symbolic. Symbols are just connections in your brain. Even your body is a symbol. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Lucio Flores wrote:
So as an exercise, I'm trying to use a lambda expression that applies the first argument twice on it's second argument.
typedef mpl::apply<_1, mpl::apply<_1, _2>::type>::type twice_type;
Then I instance this lambda function on boost::add_pointer and int
typedef mpl::apply<twice_type, boost::add_pointer<_1>, int>::type result_type;
But using boost::is_same, I've found that result_type==int, not int** as expected. Can someone see why?
If you look closely, as it is defined, twice_type is actually the same as mpl::_2. Once you "invoke" the ::type member typedef you're evaluating the metafunction and no longer have a lambda. Here's a simple function I find useful in debugging template meta-code: template <class type> inline void print() { class _ { _() {} }; _ printer; } use it thus: int main() { typedef mpl::apply<mpl::_1, mpl::_2>::type result; print<result>(); } You'll get a nice error message with the resulting type in it. This should help you better understand what's going on. You'll should look into protect and lambda to defer evaluation of the metafunctions. HTH, João
--- João Abecasis <jpabecasis@gmail.com> wrote:
Lucio Flores wrote:
So as an exercise, I'm trying to use a lambda expression that applies the first argument twice on it's second argument.
typedef mpl::apply<_1, mpl::apply<_1, _2>::type>::type twice_type;
Then I instance this lambda function on boost::add_pointer and int
typedef mpl::apply<twice_type, boost::add_pointer<_1>, int>::type result_type;
But using boost::is_same, I've found that result_type==int, not int** as expected. Can someone see why?
If you look closely, as it is defined, twice_type is actually the same as mpl::_2. Once you "invoke" the ::type member typedef you're evaluating the metafunction and no longer have a lambda.
Ah.... ok so to create a proper lambda metafunction, I'm typing: typedef mpl::apply<_1, mpl::apply<_1, _2> > twice_type; Then to invoke it, I tried doing typedef mpl::apply<twice_type::type, boost::add_pointer<_1>, int> result_type; But boost::is_same<result_type, int**>::value is also false.
Here's a simple function I find useful in debugging template meta-code:
template <class type> inline void print() { class _ { _() {} }; _ printer; }
I see, I'm supposed to read the type description from the compiler error. Slick!! But the compiler doesn't describe the full description: prog_3_6.cpp: In function `void print() [with type = result_type]': prog_3_6.cpp:32: instantiated from here prog_3_6.cpp:9: error: `print()::_::_() [with type = result_type]' is private gcc version 3.3.5 20050117 (prerelease) (SUSE Linux) Maybe a compiler flag is needed to make it describe the full type? ------------------------------------------- Manson: My philosophy is: Don't think. I don't believe in the mind that you think with and scheme with. I don't believe in words. Reporter: If you don't believe in words, why do you use so many of them? Manson: Words are symbols. All I'm doing is jumbling the symbols in your brain. Everything is symbolic. Symbols are just connections in your brain. Even your body is a symbol. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Lucio Flores wrote:
--- João Abecasis <jpabecasis@gmail.com> wrote:
Lucio Flores wrote:
So as an exercise, I'm trying to use a lambda expression that applies the first argument twice on it's second argument.
typedef mpl::apply<_1, mpl::apply<_1, _2>::type>::type twice_type;
Then I instance this lambda function on boost::add_pointer and int
typedef mpl::apply<twice_type, boost::add_pointer<_1>, int>::type result_type; But using boost::is_same, I've found that result_type==int, not int** as expected. Can someone see why? If you look closely, as it is defined, twice_type is actually the same as mpl::_2. Once you "invoke" the ::type member typedef you're evaluating the metafunction and no longer have a lambda.
Ah.... ok so to create a proper lambda metafunction, I'm typing:
typedef mpl::apply<_1, mpl::apply<_1, _2> > twice_type;
Then to invoke it, I tried doing
typedef mpl::apply<twice_type::type, boost::add_pointer<_1>, int> result_type;
twice_type::type is an invocation of twice_type, so you're almost back to square one. Using the print utility print<twice_type::type>(); , I get (edited for readability) error: ‘print()::_::_() [with type = mpl::apply<mpl::_1, mpl::_2>]’ is private error: within this context
But boost::is_same<result_type, int**>::value is also false.
Here's a simple function I find useful in debugging template meta-code:
template <class type> inline void print() { class _ { _() {} }; _ printer; }
I see, I'm supposed to read the type description from the compiler error. Slick!! But the compiler doesn't describe the full description:
prog_3_6.cpp: In function `void print() [with type = result_type]': prog_3_6.cpp:32: instantiated from here prog_3_6.cpp:9: error: `print()::_::_() [with type = result_type]' is private
gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)
Maybe a compiler flag is needed to make it describe the full type?
Typedefs can interfere with the print utility. That said, you got what you asked for. I'm assuming you wrote print<result_type>(); Perhaps what you're really after is, print<result_type::type>(); , since you already know what result_type is from the typedef above. Best regards, João
Lucio Flores writes:
So as an exercise, I'm trying to use a lambda expression that applies the first argument twice on it's second argument.
typedef mpl::apply<_1, mpl::apply<_1, _2>::type>::type twice_type;
I'm afraid this doesn't do what you think. Following a metafunction with '::type' means invoking it, so the above is basically equivalent to typedef mpl::apply<_1, _2>::type t; // == _1::apply<_2>::type == _2 typedef mpl::apply<_1,t>::type twice_type; // == _1::apply<t>::type == _1::apply<_2>::type // == _2
Then I instance this lambda function on boost::add_pointer and int
typedef mpl::apply<twice_type, boost::add_pointer<_1>, int>::type result_type;
.. and, in its turn, this is equivalent to typedef mpl::apply<_2, boost::add_pointer<_1>, int>::type result_type; which gives you the result you refer to below.
But using boost::is_same, I've found that result_type==int, not int** as expected. Can someone see why?
HTH, -- Aleksey Gurtovoy MetaCommunications Engineering
--- David Abrahams <dave@boost-consulting.com> wrote:
P.S. <plug> I recommend http://www.boost-consulting.com/mplbook for MPL newbies </plug>
I'm working through problems using that very book!! __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
participants (13)
-
Aleksey Gurtovoy -
Andy Little -
David Abrahams -
Jeff Flinn -
João Abecasis -
Kevin Heifner -
Lucio Flores -
Noel Belcourt -
Paul Mensonides -
Perry Smith -
Peter Dimov -
Stuart Dootson -
yinglcs2＠yahoo.com