Assignment of ptr_container<A>::iterator value to ptr_container<B>::iterator variable
So I've got a few ptr_container instances floating around, and have just tracked down a bug caused by (my) naff code essentially akin to the following: ptr_vector<int> vi; ptr_vector<string> vs; bool eq = (vi.begin() == vs.begin()); After digging I discovered the operator in question in void_ptr_iterator.hpp: template< class VoidIterT, class T, class VoidIterU, class U > inline bool operator==( const void_ptr_iterator<VoidIterT,T>& l, const void_ptr_iterator<VoidIterU,U>& r ) What is the reason for implementing comparison between different iterator types? I have a few guesses but unsure of whether they're sensible ones or not! Of course disallowing comparison between differing pointer types won't save people from comparing iterators from different containers, but I think it's a little too easy to fall into this trap, and difficult to spot the error once written in. (The equality comparison was an unlikely case, and fortunately found it during thorough unit testing :-) ) Is there any sensible way to suppress this behaviour, or are there any comments on why I might be being a muppet? Cheers, Rob -- Rob Desbois Eml: rob.desbois@gmail.com
Hi Rob, Den 28-09-2011 17:39, Rob Desbois skrev:
So I've got a few ptr_container instances floating around, and have just tracked down a bug caused by (my) naff code essentially akin to the following: ptr_vector<int> vi; ptr_vector<string> vs; bool eq = (vi.begin() == vs.begin());
After digging I discovered the operator in question in void_ptr_iterator.hpp: template< class VoidIterT, class T, class VoidIterU, class U> inline bool operator==( const void_ptr_iterator<VoidIterT,T>& l, const void_ptr_iterator<VoidIterU,U>& r )
[snip]
Is there any sensible way to suppress this behaviour, or are there any comments on why I might be being a muppet?
We can't fix it until we update the code. I agree it is unfortunate behavior that we should try to avoid. I have forgot why I implemented it that way, but I suspect it might have been to work around various compiler issues. Anyway, please file a bug report, and then I'll see if I can fix it. Or, even better, provide a patch. kind regards -Thorsten
Thanks Thorsten. Apologies - I realised I got the email subject wrong, duh. I've filed this as ticket #5961 (https://svn.boost.org/trac/boost/ticket/5961). I presume the reason you implemented it like this is to support comparing C::iterator with C::const_iterator types. The standard library iterators support this without allowing comparison between differently-typed iterators by making the container type a template parameter for the iterator, and hence the comparators too. Single container type, 2 iterator types allows the necessary stuff without being too relaxed. I've submitted a proposed patch (#5963 @ https://svn.boost.org/trac/boost/ticket/5963) which ties the originating container type to the iterator type, and the passing of this through the template structures from the most-derived container types through the base layers and the traits classes (set_config / sequence_config). All tests in libs/ptr_container/test pass, and I've confirmed separately that the original behaviour of allowing operatorXX(const_iterator, iterator) is still supported (which is what the tests do), whilst comparing iterators from different container types is no longer allowed. I didn't make any changes to the map container and iterator since it seems they already behaved as expected. Hope it's all fine. All the best, Rob On Wed, Sep 28, 2011 at 5:25 PM, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Hi Rob,
Den 28-09-2011 17:39, Rob Desbois skrev:
So I've got a few ptr_container instances floating around, and have just tracked down a bug caused by (my) naff code essentially akin to the following: ptr_vector<int> vi; ptr_vector<string> vs; bool eq = (vi.begin() == vs.begin());
After digging I discovered the operator in question in void_ptr_iterator.hpp: template< class VoidIterT, class T, class VoidIterU, class U> inline bool operator==( const void_ptr_iterator<VoidIterT,T>& l, const void_ptr_iterator<VoidIterU,U>& r )
[snip]
Is there any sensible way to suppress this behaviour, or are there any comments on why I might be being a muppet?
We can't fix it until we update the code. I agree it is unfortunate behavior that we should try to avoid.
I have forgot why I implemented it that way, but I suspect it might have been to work around various compiler issues.
Anyway, please file a bug report, and then I'll see if I can fix it. Or, even better, provide a patch.
kind regards
-Thorsten _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Rob Desbois Eml: rob.desbois@gmail.com Tel: 07946 705987 "I disapprove of what you say, but I’ll defend to the death your right to say it", Voltaire
participants (2)
-
Rob Desbois -
Thorsten Ottosen