In article <3a380355.14185618@news.csrlink.net>,
  jpotter@falcon.lhup.edu (John Potter) wrote:
> On Wed, 13 Dec 2000 14:21:47 GMT, Scott Meyers <smeyers@aristeia.com>
> wrote:
>
> > LWG issue 179, where it appears that the committee is close to
agreeing
> > that it should be possible to mix iterators and const_iterators in
> > comparisons, but it need not be possible to mix reverse_iterators
and
> > const_reverse_iterators.

<snip>

> > As a guy who will doubtless be asked to explain the reasoning
behind this
> > behavior, could somebody kindly explain it to me?

I haven't figured it out myself yet :).  reverse_iterator can be fixed,
even (if necessary), in a way that won't break any user code.  I've
been in contact with Judy Ward, and she's agreed to raise an issue for
me in the library active issues list.  (Like John, I'm not a committee
member).

> How about other things?  Should
>
>    for_each(i, ci, Func());
>
> compile?  It is the algorithm version of the usual example where the
> problem is seen.  I don't think that the interest is as high for
> either of these as it is for the usual iterators.

I think they're two different topics, with different interest levels;
reverse iterators IMO are supposed to be semantically similar to normal
iterators, so to me that has a higher interest level.

        -Steve
(email replies to: scleary at jerviswebb dot com)

P.S. I've looked at this issue a bit, but didn't get any response to my
post in this NG on 7/11/2000 titled "Comments on Library Active Issue
#179: Comparison of const_iterators to iterators"

P.P.S. To make the fix in a way that won't break any user code at all,
*add* the two-template-parameter function definitions to the single-
template-parameter function definitions instead of *replacing* the old
ones.


Sent via Deja.com
http://www.deja.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

On Sat, 16 Dec 2000 18:10:35 GMT, Stephen Cleary <csclear@my-deja.com>
wrote:

> reverse iterators IMO are supposed to be semantically similar to normal
> iterators

I agree that reverse_iterators should be treated the same as the
normal iterators.  When the subject was discussed on clc++m, everyone
seemed surprised that reverse_iterator and const_reverse_iterator
are not comparable.  It might help if someone posted some real code
where that caused a problem rather than only having consistency as
an arguement.  The only real example that I have seen for the normal
iterators is for(C::const_iterator i = c.begin(); c.end() != i; ++ i).
The same example would hold for reverse_iterator, but does anyone use
them?

BTW, your thoughts on operator-(iter, iter) for a mix of const and
non-const iterators also makes sense.  I would make it a non-member
(like the standard) and there is no need for friend since base() is
public for reverse_iterator.  It would be an implemeter problem for
the normal container iterators which are implementation defined. Again,
does anyone care?

> P.P.S. To make the fix in a way that won't break any user code at all,
> *add* the two-template-parameter function definitions to the single-
> template-parameter function definitions instead of *replacing* the old
> ones.

I'm confused.  Do you have an example which compiles now and would not
if the replacement were made?

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3a3c587e.131945081@news.csrlink.net>,
  jpotter@falcon.lhup.edu (John Potter) wrote:
> On Sat, 16 Dec 2000 18:10:35 GMT, Stephen Cleary <csclear@my-deja.com>
> wrote:
>
> It might help if someone posted some real code
> where that caused a problem rather than only having consistency as
> an arguement.  The only real example that I have seen for the normal
> iterators is for(C::const_iterator i = c.begin(); c.end() != i; ++ i).
> The same example would hold for reverse_iterator, but does anyone use
> them?

I think I first ran into this problem when fooling around with
containers of iterators and const_iterators.  I don't have that code
anymore...

> I would make it [operator-] a non-member
> (like the standard) and there is no need for friend since base() is
> public for reverse_iterator.

Good points.

> Do you have an example which compiles now and would not
> if the replacement were made?

I was told that the reverse_iterator replacement would be frowned on
because it could "break user code", so I should re-submit it as a
feature request for the next Standard.  The only such code I can think
of is user code that took the address of one of the current global
operator functions.

        -Steve

e-mail replies to: scleary at jerviswebb dot com


Sent via Deja.com
http://www.deja.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

More than once it has occurred to me that the standardization committee
works in mysterious ways, but Matt Austern's current CUJ column led me to
LWG issue 179, where it appears that the committee is close to agreeing
that it should be possible to mix iterators and const_iterators in
comparisons, but it need not be possible to mix reverse_iterators and
const_reverse_iterators.  That is, this code should compile,

  Container::iterator i;
  Container::const_iterator ci;

  if (i == ci) ...    // should be okay
  if (ci == i) ...    // also should be okay

but this code need not compile:

  Container::reverse_iterator i;
  Container::const_reverse_iterator ci;

  if (i == ci) ...    // may be rejected
  if (ci == i) ...    // ditto

As a guy who will doubtless be asked to explain the reasoning behind this
behavior, could somebody kindly explain it to me?

Thanks,

Scott

--
I've scheduled more public seminars.  Check out
http://www.aristeia.com/seminars/ for details.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

On Wed, 13 Dec 2000 14:21:47 GMT, Scott Meyers <smeyers@aristeia.com>
wrote:

> LWG issue 179, where it appears that the committee is close to agreeing
> that it should be possible to mix iterators and const_iterators in
> comparisons, but it need not be possible to mix reverse_iterators and
> const_reverse_iterators.  That is, this code should compile,
>
>   Container::iterator i;
>   Container::const_iterator ci;
>
>   if (i == ci) ...    // should be okay
>   if (ci == i) ...    // also should be okay
>
> but this code need not compile:

Must not compile.  The prototype for std::reverse_iterator is given
in the standard.  It has a single template parameter and can not be
instantiated unless the two types are identical.  Containers return
std::reverse_iterator([const_]iterator).

>   Container::reverse_iterator i;
>   Container::const_reverse_iterator ci;
>
>   if (i == ci) ...    // may be rejected
>   if (ci == i) ...    // ditto
>
> As a guy who will doubtless be asked to explain the reasoning behind this
> behavior, could somebody kindly explain it to me?

Unlikely, but anyway.  Regardless of my comments in the issue list
(I am an interested observer, not a committee member), I have come
to accept that most everyone thinks this change is desirable.  The
issue only addresses the iterators and the placement of the new text
would only affect the iterators.

If someone would like to fix reverse_iterator, another issue can be
raised.  How about other things?  Should

   for_each(i, ci, Func());

compile?  It is the algorithm version of the usual example where the
problem is seen.  I don't think that the interest is as high for
either of these as it is for the usual iterators.

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]