Boost Users :
Subject: Re: [Boost-users] Assignment of ptr_container<A>::iterator value to ptr_container<B>::iterator variable
From: Rob Desbois (rob.desbois_at_[hidden])
Date: 2011-09-29 10:14:05
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 /
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,
On Wed, Sep 28, 2011 at 5:25 PM, Thorsten Ottosen
> 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
>> 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 )
>> 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
> Boost-users mailing list
-- Rob Desbois Eml: rob.desbois_at_[hidden] Tel: 07946 705987 "I disapprove of what you say, but Ill defend to the death your right to say it", Voltaire
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net