[ptr_container] Bug in reverse iterators?
Is this a bug or am I expecting it to do something that it shouldn't? Does anyone know a workaround for this (at least temporarily)? Compiler: VC 7.1 boost: 1.33.0 Description: The "base" function for reverse iterators in the pointer container classes do not return the underlying iterator type as expected. It appears that "base" returns a reverse iterator instead. This is not specific with ptr_vector. All the pointer containers seem to have this problem. #include <boost/ptr_container/ptr_vector.hpp> void sample() { // the type of the vector does not matter for this typedef boost::ptr_vector<DWORD> boostvector; boostvector boostvec; boostvector::reverse_iterator rboostIt = boostvec.rbegin(); // The following line does NOT compile. boostvector::iterator boostIt = rboostIt.base(); // For comparison of code that DOES compile typedef std::vector<DWORD> stdvector; stdvector stdvec; stdvector::reverse_iterator rstdIt = stdvec.rbegin(); // The following line DOES compile. stdvector::iterator stdIt = rstdIt.base(); }
Is this a bug or am I expecting it to do something that it shouldn't? Does anyone know a workaround for this (at least temporarily)?
Compiler: VC 7.1 boost: 1.33.0
Description: The "base" function for reverse iterators in the pointer container classes
do not return the underlying iterator type as expected. It appears
Hi Bill, Bill Buklis wrote: that "base" returns a reverse iterator instead. This is not specific with ptr_vector. All the pointer containers seem to have this problem. Indeed they have. Thay always return the iterators with void* value_type. It's my oversigt. I haven't tried it, but to get an iterator given a reverse iterator, one should be able to do iterator i( ri.base().base() ); Looks pretty ugly. -Thorsten
Thorsten Ottosen wrote:
Hi Bill,
Bill Buklis wrote:
Is this a bug or am I expecting it to do something that it shouldn't? Does anyone know a workaround for this (at least temporarily)?
Compiler: VC 7.1 boost: 1.33.0
The cvs has been updated so reverse_iterators are now defined as usual in terms of boost::reverse_iterator< iter_type > Thanks for the report. -Thorsten
I haven't tried it, but to get an iterator given a reverse iterator, one should be able to do
iterator i( ri.base().base() );
Looks pretty ugly.
I discovered this myself the other day. It does work. But, as you said it is quite ugly. Hopefully, I'll be able to get everyone here to upgrade when this filters through to the next version of boost. But, in the meantime at least I have something that works. Thanks. This library is really nice. Greatly simplifies things for me as I don't need the overhead of shared_ptr for these constructs. -- Bill -- -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Thorsten Ottosen Sent: Tuesday, January 24, 2006 11:17 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [ptr_container] Bug in reverse iterators? Thorsten Ottosen wrote:
Hi Bill,
Bill Buklis wrote:
Is this a bug or am I expecting it to do something that it shouldn't? Does anyone know a workaround for this (at least temporarily)?
Compiler: VC 7.1 boost: 1.33.0
The cvs has been updated so reverse_iterators are now defined as usual in terms of boost::reverse_iterator< iter_type > Thanks for the report. -Thorsten _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Bill Buklis wrote:
I haven't tried it, but to get an iterator given a reverse iterator, one should be able to do
iterator i( ri.base().base() );
Looks pretty ugly.
I discovered this myself the other day. It does work. But, as you said it is quite ugly. Hopefully, I'll be able to get everyone here to upgrade when this filters through to the next version of boost. But, in the meantime at least I have something that works.
Right. you might want to put a function in between your code to easy upgrades.
Thanks. This library is really nice. Greatly simplifies things for me as I don't need the overhead of shared_ptr for these constructs.
Thanks. My main motivation was not speed, but design. If what you're modelling is not shared, but unique, I prefer to use something that models that explicitly. C++ is a fantastic langauge to design programs in, reason enough for me to prefer it. -Thorsten
participants (2)
-
Bill Buklis -
Thorsten Ottosen