boost::sub_range vs boost::iterator_range
After reading (and re-reading a few times) the documentation on
range, it appears to me that there is little (if any) difference between:
boost::sub_range<T>
and
boost::iterator_range
On Sat, 3 Dec 2005, Victor A. Wagner Jr. wrote:
After reading (and re-reading a few times) the documentation on range, it appears to me that there is little (if any) difference between: boost::sub_range<T> and boost::iterator_range
Seems to me that sub_range is a convenience class to describe iterator ranges from ranges or containers that model ForwardRange, from which you can propagate constness.
I've been working on a N way merge algorithm for work, and thought it might be a nice chance to learn bost::range and maybe even get it general enough to submit for boost utility some day. At any rate. Here's the problem: I've written a test case and two implementations (work still in progress) but I get compile errors when I try to use sub_range.
the code can be found at http://www.noidea128.org/sourcefiles/15646~
to change the program from compiling/running the iterator_range to sub_range simply change the lne from:
Nway_merge(contain, ourmerged); -to- SNway_merge(contain, ourmerged);
my compiler (VC-8_0) gives two errors which I cannot decipher. Any assistance would be appreciated.... especially if I've misunderstood why sub_range instead of iterator_range.
Mm, I don't know. The only thing g++-4.0 (sorry, I can't help you with VC) was complaining about are the missing 'typename's for the declaration of member_container_iterator and iterator_range_iterator in Nway_merge, and sub_range_iterator in SNway_merge. What are the errors reported by the compiler? -- François Duranleau LIGUM, Université de Montréal "There once was a boy who dreamed of being a hero, who believed sincerely in the battle to banish Darkness from a world of Light. But Light and Darkness are equal, and where one exists, so too must the other. And when the boy finally realized this, he had taken the first step toward being a true hero." - from Record of Lodoss War
Victor A. Wagner Jr. wrote:
After reading (and re-reading a few times) the documentation on range, it appears to me that there is little (if any) difference between: boost::sub_range<T> and boost::iterator_range
I've been working on a N way merge algorithm for work, and thought it might be a nice chance to learn bost::range and maybe even get it general enough to submit for boost utility some day. At any rate. Here's the problem: I've written a test case and two implementations (work still in progress) but I get compile errors when I try to use sub_range.
the code can be found at http://www.noidea128.org/sourcefiles/15646~
to change the program from compiling/running the iterator_range to sub_range simply change the lne from:
Nway_merge(contain, ourmerged); -to- SNway_merge(contain, ourmerged);
my compiler (VC-8_0) gives two errors which I cannot decipher. Any assistance would be appreciated.... especially if I've misunderstood why sub_range instead of iterator_range.
Hi,
push_back adds constness to sub_range.
See:
#include <vector>
#include
Victor A. Wagner Jr. wrote:
Seems to me that sub_range is a convenience class to describe iterator ranges from ranges or containers that model ForwardRange, from which you can propagate constness.
yup, that's what I thought also
It seems that the problem was caused by the fact that the vc71 generates default operators a bit wierd. The copy-constructor is default generated and so does simply copy the iterators. It seems that the default generated constructor/ assignment for sub_range calls a templated version of iterator_range's construcgtor/ assignment operator I think this might be a bug in the compiler. I've added the following overload sub_range& operator=( sub_range r ) { // // argument passed by value to avoid // const_iterator to iterator conversion // base::operator=( r ); return *this; } and can now compile your program. I've also committed this to the main cvs. -Thorsten
At 14:15 2005-12-07, Thorsten Ottosen wrote:
Victor A. Wagner Jr. wrote:
Seems to me that sub_range is a convenience class to describe iterator ranges from ranges or containers that model ForwardRange, from which you can propagate constness.
yup, that's what I thought also
It seems that the problem was caused by the fact that the vc71 generates default operators a bit wierd. The copy-constructor is default generated and so does simply copy the iterators. It seems that the default generated constructor/ assignment for sub_range calls a templated version of iterator_range's construcgtor/ assignment operator
I think this might be a bug in the compiler.
I've added the following overload
sub_range& operator=( sub_range r ) { // // argument passed by value to avoid // const_iterator to iterator conversion // base::operator=( r ); return *this; }
and can now compile your program.
I've also committed this to the main cvs.
yes, it compiles, and runs on vc7.1 it does NOT compile on vs8.0 (which is currently my default compiler)
-Thorsten
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner Jr. wrote:
I've added the following overload
sub_range& operator=( sub_range r ) { // // argument passed by value to avoid // const_iterator to iterator conversion // base::operator=( r ); return *this; }
and can now compile your program.
I've also committed this to the main cvs.
yes, it compiles, and runs on vc7.1 it does NOT compile on vs8.0 (which is currently my default compiler)
was there any difference in the compiler there? Is it still operator= in iterator_range that gets called? -Thorsten
At 16:18 2005-12-08, you wrote:
Victor A. Wagner Jr. wrote:
I've added the following overload
sub_range& operator=( sub_range r ) { // // argument passed by value to avoid // const_iterator to iterator conversion // base::operator=( r ); return *this; }
and can now compile your program.
I've also committed this to the main cvs.
yes, it compiles, and runs on vc7.1 it does NOT compile on vs8.0 (which is currently my default compiler)
was there any difference in the compiler there? Is it still operator= in iterator_range that gets called?
yes, vs2005 has the vc8.0 compiler... I'll repost the program AND the errors... http://www.noidea128.org/sourcefiles/15688~ that souce is already trying to call SNway_merge and shows 2 errors.
-Thorsten
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner Jr. wrote:
At 16:18 2005-12-08, you wrote:
Victor A. Wagner Jr. wrote:
I've added the following overload
sub_range& operator=( sub_range r ) { // // argument passed by value to avoid // const_iterator to iterator conversion // base::operator=( r ); return *this; }
and can now compile your program.
I've also committed this to the main cvs.
yes, it compiles, and runs on vc7.1 it does NOT compile on vs8.0 (which is currently my default compiler)
was there any difference in the compiler there? Is it still operator= in iterator_range that gets called?
yes, vs2005 has the vc8.0 compiler... I'll repost the program AND the errors... http://www.noidea128.org/sourcefiles/15688~ that souce is already trying to call SNway_merge and shows 2 errors.
-Thorsten
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Add:
sub_range(const sub_range& r) :
base(static_cast
Thorsten Ottosen wrote:
Victor A. Wagner Jr. wrote:
Seems to me that sub_range is a convenience class to describe iterator ranges from ranges or containers that model ForwardRange, from which you can propagate constness.
yup, that's what I thought also
It seems that the problem was caused by the fact that the vc71 generates default operators a bit wierd. The copy-constructor is default generated and so does simply copy the iterators. It seems that the default generated constructor/ assignment for sub_range calls a templated version of iterator_range's construcgtor/ assignment operator
I think this might be a bug in the compiler.
I thought it was intentional. See: void test() { std::string str; // hey, const sub_range. const boost::sub_rangestd::string rng1(str); // whether or not to allow...? boost::sub_rangestd::string rng2 = rng1; } I don't know the answer for sure. Regards, MB http://p-stade.sourceforge.net/
MB wrote:
Thorsten Ottosen wrote:
Victor A. Wagner Jr. wrote:
Seems to me that sub_range is a convenience class to describe iterator ranges from ranges or containers that model ForwardRange, from which you can propagate constness.
yup, that's what I thought also
It seems that the problem was caused by the fact that the vc71 generates default operators a bit wierd. The copy-constructor is default generated and so does simply copy the iterators. It seems that the default generated constructor/ assignment for sub_range calls a templated version of iterator_range's construcgtor/ assignment operator
I think this might be a bug in the compiler.
I thought it was intentional. See:
void test() { std::string str;
// hey, const sub_range. const boost::sub_rangestd::string rng1(str);
// whether or not to allow...? boost::sub_rangestd::string rng2 = rng1; }
I don't know the answer for sure.
Can you assing a const vector<T> to a mutable vector<T>? -Thorsten
Thorsten Ottosen wrote:
I think this might be a bug in the compiler.
I thought it was intentional. See:
void test() { std::string str;
// hey, const sub_range. const boost::sub_rangestd::string rng1(str);
// whether or not to allow...? boost::sub_rangestd::string rng2 = rng1; }
I don't know the answer for sure.
Can you assing a const vector<T> to a mutable vector<T>?
Hmm, yes. (though I think it is not the property of range.) I believed it was your intention, because a trivial assignment fails like Victor's example under VC++7.1. I must change the recognition of sub_range. Regards, MB http://p-stade.sourceforge.net/
participants (4)
-
François Duranleau -
MB -
Thorsten Ottosen -
Victor A. Wagner Jr.