cjoy wrote:

> I'm trying to understand the input iterator invariants given by the
> standard.  Specifically, what I am struggling with is section 24.1.1 table
> 72, p. 511.  Here it is stated under the operation *a for the post
> conditions: "If a==b and (a,b) is in the domain of == then *a is
> equivalent
> to *b".  Note here that the standard does not state that *a == *b as it
> does for other iterator types and in fact we can have
> i == j but NOT *i == *j as shown by input iterators such as
> istream_iterator and istreambuf_iterator, e.g.
[snip code]
> Which I believe is correct because of the standard 24.5.1.2 line 6 p. 530
> which states that i == j will return true as long as both
> istream_iterators
> point to the same stream.  (I believe they also both have to not be at
> end() but I can't find where it says this right now.)

> Another example of this kind of thing can be found with
> istreambuf_iterator 24.5.3.5 p.533 where we have that two
> istreambuf_iterators are equal iff
> both are at end-of-stream or neither is at end-of-stream,  **regardless of
> what streambuf object they use**.

That strikes me as a defect, because i == j doesn't imply *i equivalent to
*j for any definition of "equivalence", unless i and j are using the same
streambuf object.

> So, back to my question(s)
> 1. If i == j for an input iterator, what, if anything does it say about
> the
> relationship between *i and *j.  (Given istreambuf_iterator it seems to me
> that *i and *j may be quite unrelated objects.)

I believe that "equivalent:" in this context essentially means
"interchangable". So if I have i == j, I can swap any *i and *j within the
reach of that assignment. So, for instance,
if (i == j) {
  std::cout << *i;
}

is semantically equivalent to:
if (i == j) {
  std::cout << *j;
}

> 2. Are there STL algorithms that take Input Iterators which make crucial
> use
> of i == j implies *i and *j  'equivalent'  (whatever 'equivalent' means
> here)?
>
> Dazed, or 'equivalently' confused,
>
> Corwin

        Doug

---
[ 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                ]

I'm trying to understand the input iterator invariants given by the
standard.  Specifically, what I am struggling with is section 24.1.1 table
72, p. 511.  Here it is stated under the operation *a for the post
conditions: "If a==b and (a,b) is in the domain of == then *a is equivalent
to *b".  Note here that the standard does not state that *a == *b as it does
for other iterator types and in fact we can have
i == j but NOT *i == *j as shown by input iterators such as istream_iterator
and istreambuf_iterator, e.g.

#include <iostream>
#include <iterator>

using namespace std;

int main()  {

 istream_iterator<int> i(cin), j;
 j = i;

 cout << *i << ", " << *j << endl;
 j++;
 cout << *i << ", " << *j << endl;
 if (i == j)
  cout << "i == j is true" << endl;
 else
  cout << "i == j is false" << endl;

 return 0;
}

If I give as input e.g. 2<ret> 3<ret>  (to MSVC 6) I get

2, 2
2, 3
i == j is true.

Which I believe is correct because of the standard 24.5.1.2 line 6 p. 530
which states that i == j will return true as long as both istream_iterators
point to the same stream.  (I believe they also both have to not be at end()
but I can't find where it says this right now.)

Another example of this kind of thing can be found with istreambuf_iterator
24.5.3.5 p.533 where we have that two istreambuf_iterators are equal iff
both are at end-of-stream or neither is at end-of-stream,  **regardless of
what streambuf object they use**.

So, back to my question(s)
1. If i == j for an input iterator, what, if anything does it say about the
relationship between *i and *j.  (Given istreambuf_iterator it seems to me
that *i and *j may be quite unrelated objects.)

2. Are there STL algorithms that take Input Iterators which make crucial use
of i == j implies *i and *j  'equivalent'  (whatever 'equivalent' means
here)?

Dazed, or 'equivalently' confused,

Corwin

--
"Computer games doesn't affect kids; I mean if Pac-Man affected us as kids,
we'd all be running around darkened rooms, munching magic pills and
listening to repetitive electronic music."

-Kristian Wilson, Nintendo, Inc. 1989


---
[ 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                ]

In article <vHNa7.341058$lq1.72670733@typhoon.austin.rr.com>, cjoy
<cjoy@houston.rr.com> writes
>1. If i == j for an input iterator, what, if anything does it say about the
>relationship between *i and *j.  (Given istreambuf_iterator it seems to me
>that *i and *j may be quite unrelated objects.)
>
>2. Are there STL algorithms that take Input Iterators which make crucial use
>of i == j implies *i and *j  'equivalent'  (whatever 'equivalent' means
>here)?

I think you missed the essential requirement that (a, b) is in the
domain of ==. I suspect the rest of the wording is to avoid seeming to
use == when a type need not have an operator==() {but I would be the
first to admit that the Standard is not always consistent over that
issue]


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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                ]