reverse iterator operator==

[Alexander Stippler]

Hello,

the standard requires a type reverse_iterato r. But in the form it is
required and implemented for all compilers I know, there is IMO something
missing, which is essential for its usage.
With normal iterators you can compare a const_iterator and an iterator for
equality, using reverse_iterato r as is, you can't. I can understand the
reason, why it's not provided. But does reverse_iterato r make sense this
way? A simple example:

std::vector<int > v;
std::vector<int >::const_revers e_iterator it;
for (it=v.rbegin(); it!=v.rend(); ++it) {}

This won't compile, since it and v.rend() have different types and no
operator!= is defined for those. Isn't it unnatural that I can do the same
loop as above traversing the vector forward and it is legal code, but by
inverting the traversal direction, I create illegal code?
Any experiences with reverse_iterato rs? What do you think?

regards,
alex

[Ron Natalie]

Re: reverse iterator operator==


"Alexander Stippler" <stip@mathemati k.uni-ulm.de> wrote in message news:3ff2ef54@n ews.uni-ulm.de...
[color=blue]
> With normal iterators you can compare a const_iterator and an iterator for
> equality[/color]

Nothing says you can compare iterator and const_iterator either. It's just
coincidence on your implementation that the types are convertible.

You need to use the constness of the iterator appropriate for the constness
of the object you call the r.begin()/r.end() on .

If you really want to force it to const iterators:

for(it = const_cast<cons t std::vector<int >&>(v).rbegin() ; it != const_cast<cons t std::vector<int >&>(v).rend() ; ++i) ..,

[John Ericson]

Re: reverse iterator operator==

"Ron Natalie" <ron@sensor.com > wrote in message
news:3ff2f81d$0 $66035$9a6e19ea @news.newshosti ng.com...[color=blue]
>
> "Alexander Stippler" <stip@mathemati k.uni-ulm.de> wrote in[/color]
message news:3ff2ef54@n ews.uni-ulm.de...[color=blue]
>[color=green]
> > With normal iterators you can compare a const_iterator[/color][/color]
and an iterator for[color=blue][color=green]
> > equality[/color]
>
> Nothing says you can compare iterator and const_iterator[/color]
either. It's just[color=blue]
> coincidence on your implementation that the types are[/color]
convertible.[color=blue]
>
> You need to use the constness of the iterator appropriate[/color]
for the constness[color=blue]
> of the object you call the r.begin()/r.end() on .
>
> If you really want to force it to const iterators:
>
> for(it = const_cast<cons t std::vector<int >&>(v).rbegin() ;[/color]
it != const_cast<cons t std::vector<int >&>(v).rend() ; ++i)
...,[color=blue]
>[/color]

Say what? Isn't there an implicit conversion from iterator
to const_iterator, and from reverse_iterato r to
const_reverse_i terator?
- -
Best regards, John E.

[Alexander Stippler]

Re: reverse iterator operator==

Ron Natalie wrote:
[color=blue]
>
> You need to use the constness of the iterator appropriate for the
> constness of the object you call the r.begin()/r.end() on .
>[/color]

Using const_iterators you can (to some extent) be sure, the container
used isn't modified during the iteration. That's a feature, I use heavily
because it can prevent some errors. I think you are correct, since the
standard doesn't enforce the comparison possibility. I do not really like
it, but I think I will stop using const_iterators that heavily restricting
me to use them only when neccessary (through constness of the underlying
container).

[Nick Hounsome]

Re: reverse iterator operator==

"Ron Natalie" <ron@sensor.com > wrote in message
news:3ff2f81d$0 $66035$9a6e19ea @news.newshosti ng.com...[color=blue]
>
> "Alexander Stippler" <stip@mathemati k.uni-ulm.de> wrote in message[/color]
news:3ff2ef54@n ews.uni-ulm.de...[color=blue]
>[color=green]
> > With normal iterators you can compare a const_iterator and an iterator[/color][/color]
for[color=blue][color=green]
> > equality[/color]
>
> Nothing says you can compare iterator and const_iterator either. It's[/color]
just[color=blue]
> coincidence on your implementation that the types are convertible.
>[/color]

No it isn't - the standard section on iterators says nothing about being
convertible but the section on containers puts a requirement on standard
containers that their iterators are convertible to const_iterator except for
output iterators.

[Ron Natalie]

Re: reverse iterator operator==


"Nick Hounsome" <nh002@blueyond er.co.uk> wrote in message news:utDIb.1348 8$sf5.11259@new s-binary.blueyond er.co.uk...
[color=blue]
> No it isn't - the standard section on iterators says nothing about being
> convertible but the section on containers puts a requirement on standard
> containers that their iterators are convertible to const_iterator except for
> output iterators.[/color]

OK, iterator should be convertible to const_iterator. You're misreading the
exception though. That "except for output iterator" isn't talking about the
conversion. It's saying that X::iterator can't be an output_iterator . No conversion
is required for reverse_iterato rs.

[John Ericson]

Re: reverse iterator operator==

"Ron Natalie" <ron@sensor.com > wrote in message
news:3ff31007$0 $66043$9a6e19ea @news.newshosti ng.com...[color=blue]
>
> "Nick Hounsome" <nh002@blueyond er.co.uk> wrote in message[/color]
news:utDIb.1348 8$sf5.11259@new s-binary.blueyond er.co.uk...[color=blue]
>[color=green]
> > No it isn't - the standard section on iterators says[/color][/color]
nothing about being[color=blue][color=green]
> > convertible but the section on containers puts a[/color][/color]
requirement on standard[color=blue][color=green]
> > containers that their iterators are convertible to[/color][/color]
const_iterator except for[color=blue][color=green]
> > output iterators.[/color]
>
> OK, iterator should be convertible to const_iterator.[/color]
You're misreading the[color=blue]
> exception though. That "except for output iterator"[/color]
isn't talking about the[color=blue]
> conversion. It's saying that X::iterator can't be an[/color]
output_iterator . No conversion[color=blue]
> is required for reverse_iterato rs.
>[/color]

The Library Working Group issues #179 and #280 address
mixing comparisons of (const_iterator , iterator) and
(reverse_iterat or, const_reverse_i terator), respectively.

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#179

The OP doesn't have to mix iterator types, though, and could
just make a const reference to the container, and get
const_reverse_i terators from the const reference to the
container.

Best regards, John E.

[Nick Hounsome]

Re: reverse iterator operator==


"John Ericson" <jericwahabison @pacbell.net> wrote in message
news:_yGIb.4801 $_W.2874@newssv r25.news.prodig y.com...[color=blue]
> "Ron Natalie" <ron@sensor.com > wrote in message
> news:3ff31007$0 $66043$9a6e19ea @news.newshosti ng.com...[color=green]
> >
> > "Nick Hounsome" <nh002@blueyond er.co.uk> wrote in message[/color]
> news:utDIb.1348 8$sf5.11259@new s-binary.blueyond er.co.uk...[color=green]
> >[color=darkred]
> > > No it isn't - the standard section on iterators says[/color][/color]
> nothing about being[color=green][color=darkred]
> > > convertible but the section on containers puts a[/color][/color]
> requirement on standard[color=green][color=darkred]
> > > containers that their iterators are convertible to[/color][/color]
> const_iterator except for[color=green][color=darkred]
> > > output iterators.[/color]
> >
> > OK, iterator should be convertible to const_iterator.[/color]
> You're misreading the[color=green]
> > exception though. That "except for output iterator"[/color]
> isn't talking about the[color=green]
> > conversion. It's saying that X::iterator can't be an[/color]
> output_iterator . No conversion[color=green]
> > is required for reverse_iterato rs.
> >[/color]
>
> The Library Working Group issues #179 and #280 address
> mixing comparisons of (const_iterator , iterator) and
> (reverse_iterat or, const_reverse_i terator), respectively.
> http://anubis.dkuug.dk/jtc1/sc22/wg2...fects.html#179[/color]

scuse my ignorance but isn't the problem described in the link solely down
to the apparently poor idea of making operator== a member?

If it is free function:

template <class C>
bool operator==(type name C::const_iterat or& a, typename C::const_iterat or&
b);

Then the conversion from iterator to const_iterator would sort it.

Actually I think that in practice it has to be a whole familly of
functions:
template <typename T> bool operator==(type name set<T>::const_i terator& a,
typename set<T>::const_i terator& b);
+ for map list etc.
And obviously only for those where an iterator is a class and not just a
typedef for T*
[color=blue]
>
> The OP doesn't have to mix iterator types, though, and could
> just make a const reference to the container, and get
> const_reverse_i terators from the const reference to the
> container.
>
> Best regards, John E.
>
>[/color]

[John Ericson]

Re: reverse iterator operator==

"Nick Hounsome" <nh002@blueyond er.co.uk> wrote in message
news:nBHIb.414$ PZ6.373@news-binary.blueyond er.co.uk...[color=blue]
>
> "John Ericson" <jericwahabison @pacbell.net> wrote in[/color]
message[color=blue]
> news:_yGIb.4801 $_W.2874@newssv r25.news.prodig y.com...[color=green]
> > "Ron Natalie" <ron@sensor.com > wrote in message
> > news:3ff31007$0 $66043$9a6e19ea @news.newshosti ng.com...[color=darkred]
> > >
> > > "Nick Hounsome" <nh002@blueyond er.co.uk> wrote in[/color][/color][/color]
message[color=blue][color=green]
> >[/color][/color]
news:utDIb.1348 8$sf5.11259@new s-binary.blueyond er.co.uk...[color=blue][color=green][color=darkred]
> > >[/color][/color][/color]

<snip>

JE> > The Library Working Group issues #179 and #280 address
JE> > mixing comparisons of (const_iterator , iterator) and
JE> > (reverse_iterat or, const_reverse_i terator),
respectively.
JE> >
http://anubis.dkuug.dk/jtc1/sc22/wg2...fects.html#179[color=blue]
>[/color]
Nick> scuse my ignorance but isn't the problem described in
the link solely down
Nick> to the apparently poor idea of making operator== a
member?[color=blue]
>[/color]
<snip>

Not your ignorance - the link issues are whether the
Standard should require that comparisons of
(reverse_)itera tors and const_(reverse_ )iterators be
supported, not necessarily the mechanism of implementation.
If the comparison operator were template functions with a
single type parameter and the types are different, then it
would be understandable if the type weren't deducible from
those different types. For member functions, I had expected
that, for example, (const_iterator == iterator) would be OK
(iterator being promoted to const_iterator) , while (iterator
== const_iterator) could be trouble. For the
reverse_iterato r case, perhaps the OP's implementation is
using a template operator, and is not able to deduce the
template parameter. If the Standard doesn't require that
comparisons of reverse_iterato rs and const_reverse_i terators
be supported, then I suppose one should make the iterators
in the comparison match. I haven't been doing that with
iterator and const_iterator. Maybe ignorance on my part?

Best regards, John E.