In article <FREYBURG.96Jun6112611@gamut.stanford.edu>
freyburg@gamut.stanford.edu (Brian Michael Freyburger) writes:

> However, the slightly relaxed condition:

> "r is dereferenceable imples ++r == ++X(r)"

> still allows for multi-pass algorithms.

On the other hand, it fails if type X is, say, int*, because ++X(r) is
then ill-formed.

Moreover, although the original requirement may be too strong,
I'm not sure how to rephrase it.  I understand what you're saying --
you would like two forward iterators to compare equal if they
``point to the same place'' even if they behave differently under ++.
But what can you say about their behavior that defines ``point to
the same place'' if they do not behave equivalently under ++ ?
--
    --Andrew Koenig
      ark@research.att.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Currently, forward iterators have the requirement that

"r == s and r is dereferenceable implies ++r == ++s".

It is explicitely stated in the draft to achieve the purpose of
allowing multi-pass algorithms on forward iterators [see the note at
24.1.3.2].

However, the slightly relaxed condition:

"r is dereferenceable imples ++r == ++X(r)"

still allows for multi-pass algorithms.  In fact, the
only valid way to create a multi-pass algorithm is too copy the
iterator, and pass through the data multiple times.

The current condition adds the constraint that two iterators FROM ANY
SOURCE, which compare ==, must have the same behavior.  In fact, the
whole of their behaviour, as defined by the requirements, must be
exactly the same.

Now, why relax the condition?  Consider the following code, a
stride_iterator, which is adapted from some code of mine to support
multi-dimensional containers:

template <class Ref, class Iterator, class Diff>
class stride_iterator
{
public:
  stride_iterator()  {}
  stride_iterator(Iter i, Diff stride) : i(i), w(stride) {}

  stride_iterator &operator ++(   ) { i += w; return *this; }
  stride_iterator  operator ++(int) { stride_iterator tmp(i, w); i += w; return tmp; }

  Ref operator *() { return *i; }

  // ...

  friend operators ==(const stride_iterator &a, const stride_iterator &b)
    { return a.i == b.i && a.w == b.w; }

private:
  Iter i;
  Diff w;
};

This issue is the definition of operator ==.  With the relaxed rules,
the operator could be defined just compare the underlying iterators
and NOT the widths.  The conditions that "a == b implies *a == *b"
would still hold, as would the relaxed condition above, allowing for
multi-pass algorithms.

For a set of stride_iterator's walking over the same underlying
memory, it is more useful to be able to use operator == for detecting
aliases than to see which iterator's will have the same exact
"behavior".  The same exact "behavior" can be obtained by using the
copy constructor which still allows for multi-pass algorithms.

Comments, suggestions, concerns?



[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article: <FREYBURG.96Jun6112611@gamut.stanford.edu>  freyburg@gamut.stanford.edu (Brian Michael Freyburger) writes:
> Currently, forward iterators have the requirement that
>
> "r == s and r is dereferenceable implies ++r == ++s".
>
> It is explicitely stated in the draft to achieve the purpose of
> allowing multi-pass algorithms on forward iterators [see the note at
> 24.1.3.2].
>
> However, the slightly relaxed condition:
>
> "r is dereferenceable imples ++r == ++X(r)"
>
> still allows for multi-pass algorithms.  In fact, the
> only valid way to create a multi-pass algorithm is too copy the
> iterator, and pass through the data multiple times.
> ...
> Now, why relax the condition?  Consider the following code, a
> stride_iterator, which is adapted from some code of mine to support
> multi-dimensional containers:

Oops, I didn't read carefully enough - I've been implicitly using the
relaxed version and "getting away" with it.  (I too have iterators
that navigate "slices").  You get my vote!

Alan Griffiths               | Also editor of: The ISDF Newsletter
Senior Systems Consultant,   | (An Association of C and C++ Users publication)
CCN Group Limited.           | (ISDF editor  : isdf@octopull.demon.co.uk)
(agriffiths@ma.ccngroup.com) | (For ACCU see : http://bach.cis.temple.edu/accu)



[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]