Re: [boost] MPL: set<> not fully supporting compile time iteration?
CLOSER (see below)
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Ryan Sent: Friday, June 17, 2005 9:24 PM To: boost@lists.boost.org Subject: Re: [boost] MPL: set<> not fully supporting compile time iteration?
Brian Braatz <brianb <at> rmtg.com> writes:
[snip] // copy it to a vector typedef mpl::copy < myset::type , back_inserter< vec >
>::type result_vec;
mpl::for_each<result_vec>( print_type()); } ...
Try:
typedef mpl::copy < mpl::begin<myset> , mpl::back_inserter<vec>
::type result_vec;
HTH
-Ryan
[Brian Braatz Writes:] THANK YOU RYAN- I am compiling now (one step closer) But I am still not getting the expected (??) behavior here is the current code struct A {}; struct B {}; struct C {}; struct D {}; struct print_type { template <typename T> void operator()(T const& v) const { std::cout << "[ " << typeid(v).name() << " ] "; } }; typedef mpl::set3<A,B,C> myset; typedef mpl::vector<> vec; // copy it to a vector typedef mpl::copy < mpl::begin<myset> , back_inserter< vec > >::type result_vec; // Prints "0" cout << "result_vec size " << mpl::size<result_vec>::value << endl; // prints nothing mpl::for_each<result_vec>( print_type()); ANYONE- wishing to show me how I did something ABSOLTULEY stupid or missed some concept- please, by all means :) I am starting to believe though that there is something broken with mpl::set<> (typically developer- blame either the compiler or the library (grin))
"Brian Braatz" <brianb@rmtg.com> writes:
I am starting to believe though that there is something broken with mpl::set<> (typically developer- blame either the compiler or the library (grin))
In this case the developer is right. I've just checked in a failing test case -- with any luck Aleksey can address this one quickly. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Brian Braatz <brianb <at> rmtg.com> writes:
CLOSER (see below)
On Behalf Of Ryan [snip] Try:
typedef mpl::copy < mpl::begin<myset> , mpl::back_inserter<vec>
::type result_vec;
HTH
-Ryan
[Brian Braatz Writes:] THANK YOU RYAN- I am compiling now (one step closer) But I am still not getting the expected (??) behavior here is the current code ...
Sorry about the leading you down the wrong path Brian. I was really thinking about: typedef mpl::copy < mpl::iterator_range<mpl::begin<myset>::type, mpl::end<myset>::type > , mpl::back_inserter< vec > >::type result_vec; which would only be a work around but IMO is more similar to the runtime equivalent. I am a little suprised the mpl::begin<> compiled, but I need to review Dave's and Alesky's MPL book again and will hopefully come to understand. I was actually on the newsgroup yesterday to see the answer to your great remove_duplicate_types question. I had just written the equivalent runtime function using std::vector, std::sort, and std::unique and was wondering about how to handle std::sort in the compile_time world. I stopped on this thread because I saw that it could likely lead to the answer. Thanks for the great question; I'll try to test a little better before answering any in the future. Cheers, -Ryan
Ryan Gallagher <ryan.gallagher@gmail.com> writes:
Brian Braatz <brianb <at> rmtg.com> writes:
CLOSER (see below)
On Behalf Of Ryan [snip] Try:
typedef mpl::copy < mpl::begin<myset> , mpl::back_inserter<vec>
::type result_vec;
HTH
-Ryan
[Brian Braatz Writes:] THANK YOU RYAN- I am compiling now (one step closer) But I am still not getting the expected (??) behavior here is the current code ...
Sorry about the leading you down the wrong path Brian. I was really thinking about:
typedef mpl::copy < mpl::iterator_range<mpl::begin<myset>::type, mpl::end<myset>::type > , mpl::back_inserter< vec > >::type result_vec;
which would only be a work around but IMO is more similar to the runtime equivalent.
Not really. copy just works on a pair of iterators anyway, under the covers.
I am a little suprised the mpl::begin<> compiled, but I need to review Dave's and Alesky's MPL book again and will hopefully come to understand.
Well, mpl::begin<myset> is just a type like any other. You haven't even instantiated it. But the copy<mpl::begin<myset>, ...> may have compiled because of the peculiar way in which set iterators were broken: deref<begin<myset>::type>::type was always myset (or the equivalent set3<...> with the same elements).
I was actually on the newsgroup yesterday to see the answer to your great remove_duplicate_types question. I had just written the equivalent runtime function using std::vector, std::sort, and std::unique and was wondering about how to handle std::sort in the compile_time world. I stopped on this thread because I saw that it could likely lead to the answer.
http://www.boost.org/libs/mpl/doc/refmanual/sort.html ;^) -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
Brian Braatz -
David Abrahams -
Ryan Gallagher