"John Potter" <jpotter@falcon.lhup.edu> wrote in message
news:3cdff429.26355878@news.earthlink.net...
> On 13 May 2002 15:30:35 GMT, "Anthony
> Williams"<anthwil@nortelnetworks.com> wrote:
>
> > remove_copy and remove_copy_if (25.2.7 [lib.alg.remove]) permit their
input
> > range to be marked with Input Iterators. However, since two operations
are
> > required against the elements to copy (comparison and assigment), when
the
> > input range uses Input Iterators, a temporary copy must be taken to
avoid
> > dereferencing the iterator twice.
>
> Did I miss a change to the standard for input iterators?  This sounds
> like the common application of output iterator requirements to input
> iterators.  For output iterators, algorithms must alternate * = with
> ++, but no such restriction applies to input iterators.


This is my interpretation of "Algorithms on input iterators should never
attempt to pass through the same iterator twice. They should be single pass
algorithms.", which admittedly appears in a non-normative note (24.1.1p3).
However, it seems to me that I could fulfil the explicit requirements of an
Input Iterator by having operator* do a dereference and increment operation,
and operator++ only increment if the iterator hasn't already been
dereferenced.

If I've mis-interpreted the requirements, then this is NAD, and it certainly
makes life easier.
If I've interpreted the requirements correctly, but it wasn't the intention,
then there is a defect in the Input Iterator requirements instead.

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optical Components Ltd
The opinions expressed in this message are not necessarily those of my
employer


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 14 May 2002 17:55:46 GMT, "Anthony
Williams"<anthwil@nortelnetworks.com> wrote:

> This is my interpretation of "Algorithms on input iterators should never
> attempt to pass through the same iterator twice. They should be single pass
> algorithms.", which admittedly appears in a non-normative note (24.1.1p3).

Understood.  The alternative is that you have not "passed through" until
you leave via ++.  You may stay as long as you like, but you may not
come back.

> However, it seems to me that I could fulfil the explicit requirements of an
> Input Iterator by having operator* do a dereference and increment operation,
> and operator++ only increment if the iterator hasn't already been
> dereferenced.

The fact that (*it).m and it->m are supported for input iterators, but
not for output iterators, seems to indicate otherwise.  The two standard
input iterators advance only on ++.  If a == b, *a is equivalent to *b,
but ++a == ++b is not required.

BTW, this has been discussed many times before in this group.  Not sure
that any official conclusion was reached.  At least your DR will force
an official clarification, eventually (issue 98 is still outstanding).
Unfortunately, the result could cover only those two algorithms and not
cover input iterator in general.

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.jamesd.demon.co.uk/csc/faq.html                       ]

On 13 May 2002 15:30:35 GMT, "Anthony
Williams"<anthwil@nortelnetworks.com> wrote:

> remove_copy and remove_copy_if (25.2.7 [lib.alg.remove]) permit their input
> range to be marked with Input Iterators. However, since two operations are
> required against the elements to copy (comparison and assigment), when the
> input range uses Input Iterators, a temporary copy must be taken to avoid
> dereferencing the iterator twice.

Did I miss a change to the standard for input iterators?  This sounds
like the common application of output iterator requirements to input
iterators.  For output iterators, algorithms must alternate * = with
++, but no such restriction applies to input iterators.

   cout << distance(istream_iterator<string>(cin),
         istream_iterator<string>()) << endl;

is a simple implementation of wc -w.

For an equality comparible type T and some_input_iterator with it as a
value type and objects a and b, the following must pass.

   b = a;
   assert(a == b);
   assert(*a == *b);

There is no need to make copies.  If there were a need, operator-> for
input iterators would be foolish.

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.jamesd.demon.co.uk/csc/faq.html                       ]

[ Moderator's note: Forwarded to C++ Committee. -sdc ]

remove_copy and remove_copy_if (25.2.7 [lib.alg.remove]) permit their input
range to be marked with Input Iterators. However, since two operations are
required against the elements to copy (comparison and assigment), when the
input range uses Input Iterators, a temporary copy must be taken to avoid
dereferencing the iterator twice. This therefore requires the value type of
the InputIterator to be CopyConstructible. If the iterators are at least
Forward Iterators, then the iterator can be dereferenced twice, or a
reference to the result maintained, so the temporary is not required.

Proposed resolution:

Add "If InputIterator does not meet the requirements of forward iterator,
then the value type of InputIterator must be copy constructible. Otherwise
copy constructible is not required." to 27.5.2.7p6

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optical Components Ltd
The opinions expressed in this message are not necessarily those of my
employer



[ 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.jamesd.demon.co.uk/csc/faq.html                       ]