From -3011278824680134399 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,b05362a7d4392b67 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2001-01-01 17:57:04 PST Path: supernews.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newsfeed.icl.net!dispose.news.demon.net!demon!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: jpotter@falcon.lhup.edu (John Potter) Newsgroups: comp.std.c++ Subject: Re: Definition of input iterators Date: Tue, 2 Jan 2001 01:56:06 GMT Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <3a50e18e.75679473@news.csrlink.net> References: <3A49DDCC.86CCDD18@oxyware.com> X-Trace: mail2news.demon.co.uk 978400572 mail2news:12812 mail2news mail2news.demon.co.uk X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Newsreader: Forte Free Agent 1.11/32.235 NNTP-Posting-Date: Mon, 01 Jan 2001 14:53:37 EST Lines: 59 Xref: supernews.google.com comp.std.c++:3140 On Fri, 29 Dec 2000 01:18:02 GMT, Hubert Matthews wrote: > I've found what I consider to be a problem with the definition of input > iterators in the Standard. Table 72 states that incrementing an > iterator (using either prefix or postfix ++) may invalidate any copies > of that iterator. I says may not must. I think you may be misreading the iterator requirements. These are the minimum requirements for a thing to claim that it is an input iterator. That places a restriction on the operations which an algorithm may perform when it claims to support an input iterator. It does not restrict what an input iterator is allowed to do. > This is a problem when implementing operator++(int), > as it must return a copy of the pre-increment value of the iterator > which may now not be dereferenceable because of the increment. No, operator++(int) is not required to return the pre-increment value. It is required to have the same side effect as operator++() and the return is not usable in general. > Table 72 defines the effect of *r++ to be { T tmp = *r; r++; return tmp; > }. How is this to be achieved with a user-defined iterator since *r++ > must, by the rules of operator precendence, be evaluated as > operator++(int) followed by applying operator*() to a potentially > invalidated iterator? No. Istream_iterator is a std example which returns an iterator which has not been invalidated. Knowing that istream_iterator does not invalidate copies allows me to store them in a vector and sort them and then copy the results. However, I can not write a general algorithm which claims to use input iterators to do this. Istreambuf_iterator is a std example which returns a proxy with an operator* which allows *r++ to work when the iterator is invalidated. These are both examples only, not requirements for implementation. They will both work with any algorithm which uses only those operations required for input iterators. > My suggestion is that incrementing an iterator should guarantee that > copies of that iterator are still dereferenceable but not necessarily > incrementable. This allows the return from operator++(int) to be used > safely. The only thing that is allowed is *r++. All that an implementer needs to do is make that work. It is safe to use the return from operator++(int) in the one allowed operation for all std input iterators. When creating a new input iterator, make it work. 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. ]