To be honest, I tested the max_element with files (algorithms) from 1.34 and it did not work (map files did not update for 2 years). May be I forgot smth. The transformation of vector to map via fold worked. I can try to reverse the process and see if it works for map to vector. But I do not see any reason, to transform to vector first and afterwords iterate through vector again for finding the max element. As you can imagine, this will have impact on compilation speed. On the other hand, I can write my own traversal algorithm for maps. But it would be better to use some standard algorithms. Some probably weird question: If mpl::map fulfills the requirement of ForwardSequence, why wasn't it tested with for_each or max_element or may be some other useful algorithms? Thanks, Ovanes -----Original Message----- From: David Abrahams [mailto:dave@boost-consulting.com] Sent: Tuesday, December 12, 2006 11:44 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] updating mpl::map to 1.34 "Ovanes Markarian" <om_boost@keywallet.com> writes:

Hi!

I would like to update mpl::map and mpl algorithms to 1.34 release candidate libs. What is the best way to do it? If there an archive of currently tested boost libs available or which CVS label should I use for new mpl version.

Is it sufficient to replace boost/mpl directory in the installed boost libs?

There is no guarantee that will work. Nobody has tested it.

Currently I have problems when iterating (mpl::for_each, mpl::max_element) through mpl::map sequences.

I suggest simply moving to the 1.34 release branch, wholesale. -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Dave, Thanks for your answers. Can you point me to the docs, how I should organize the test cases? Should these be some sort of BOOST_STATIC_ASSERTS etc. I think I could easily extract some code parts and do it. Many thanks, Ovanes -----Original Message----- From: David Abrahams [mailto:dave@boost-consulting.com] Sent: Wednesday, December 13, 2006 3:36 PM To: boost-users@lists.boost.org Cc: Aleksey Gurtovoy Subject: Re: [Boost-users] updating mpl::map to 1.34 "Ovanes Markarian" <om_boost@keywallet.com> writes:

To be honest, I tested the max_element with files (algorithms) from 1.34 and it did not work (map files did not update for 2 years). May be I forgot smth. The transformation of vector to map via fold worked. I can try to reverse the process and see if it works for map to vector. But I do not see any reason, to transform to vector first and afterwords iterate through vector again for finding the max element. As you can imagine, this will have impact on compilation speed. On the other hand, I can write my own traversal algorithm for maps. But it would be better to use some standard algorithms.

It sounds like you translplanted 1.34's MPL into your existing Boost installation? Remember I said that might not work.

Some probably weird question: If mpl::map fulfills the requirement of ForwardSequence, why wasn't it tested with for_each or max_element or may be some other useful algorithms?

Probably just an oversight. If you have some simple test cases we can add to the MPL test suite, please add them to the Boost SourceForge patch tracker. If they fail, maybe we'll fix a bug. -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Hi Dave, I believe I found some problem, when I was writing the test cases ;) It is for sure responsible for the reported misbehavior with max_element. Well, I don't know how to deal with this issue, may be you can advice smth. Map accepts sequence of type pair. Vector as well. My approach was to think, as long as mpl::pair static interface (first, second) is valid I can use another class as well. So I decided to derive a public class from mpl::pair, which will model discriminated value int value speciefies a type: template<int N, class T> struct my_pair : mpl::pair<mpl::int_<N>, T> { //some forward declarations of mpl::pair typedefs typename second second_; }; now I could define a map of types using my_pair and avoid using mpl::int_<N> each time: typedef mpl::map<my_pair<0, int>, my_pair<1, double> ...> my_map; Now to the problem :) : mpl::map converts these types to mpl::pair from my_pair. And the code like this will fail: typedef mpl::max_element < mpl::transform_view < my_map , mpl::sizeof_<mpl::_> > >::type max_iter; because mpl::_ is not my_pair, but mpl::pair<X,Y> and has the size of 1 byte ;) (as specified in standard) I understand I can pass to mpl::sizeof_<mpl::_> the second type from, but this would bring the entire forward sequence handling scenario out of the balance. I can use mpl::vector in this example and it will return my_pair, but I can not use mpl::map with custom pair. What should I do? This example shows that vector and map behave differently and I can not fully apply the ForwardSequence abstraction without worring which type was passed. I think with mpl::for_each happens the same thing in my example, but I would like to investigate it more to make conclusions. With Kind Regards, Ovanes Markarian On Thu, December 14, 2006 04:38, David Abrahams wrote:

"Ovanes Markarian" <om_boost@keywallet.com> writes:

...

Dave,

Thanks for your answers. Can you point me to the docs, how I should organize the test cases?

There are no docs on that; please just look at libs/mpl/test and follow the same patterns.

...

Should these be some sort of BOOST_STATIC_ASSERTS etc.

I think I could easily extract some code parts and do it.

Thank you

-- Dave Abrahams Boost Consulting www.boost-consulting.com

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

But my question would be: Would you see an advantage in this approach (with type derivation)? On the other hand, if I could manipulate the types the same way in mpl::vector and mpl::map this would be more clearer. I think vector should not support the derived types as well. With Kind Regards, Ovanes Markarian On Thu, December 14, 2006 19:04, David Abrahams wrote:

"Ovanes Markarian" <om_boost@keywallet.com> writes:

...

I believe I found some problem, when I was writing the test cases ;) It is for sure responsible for the reported misbehavior with max_element.

Well, I don't know how to deal with this issue, may be you can advice smth. Map accepts sequence of type pair. Vector as well. My approach was to think, as long as mpl::pair static interface (first, second) is valid I can use another class as well.

Clearly from your experiments you can see that you can't actually do that.

-- Dave Abrahams Boost Consulting www.boost-consulting.com

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

"Ovanes Markarian" <om_boost@keywallet.com> writes:

Now I have a question regarding iteration through the map. Would you expect this sample to work:

typedef mpl::map < mpl::pair<int, int> , mpl::pair<int, double> , mpl::pair<int, char[20]> , mpl::pair<int, char> > seq_t;

typedef mpl::begin<seq_t>::type begin_map; typedef mpl::apply < mpl::insert<mpl::_1, mpl::_2> , mpl::vector<> , begin_map >::type vector_with_one_elem;

No. I'm not sure what you're trying to do here, but it fails for the same reason that this fails: mpl::insert<mpl::vector<>, begin_map>::type The two-argument form of mpl::insert only works for inserting into associative sequences. vector is not an associative sequence. -- Dave Abrahams Boost Consulting www.boost-consulting.com