From -3401122351083227787 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,8d7ae4b2a3e77f8b X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-08-10 19:05:08 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!torn!snoopy.risq.qc.ca!news.primus.ca!news.primus.ca!news.alt.net!comp-std-cpp-robomod!not-for-mail From: stefan_heinzmann@yahoo.com (Stefan Heinzmann) Newsgroups: comp.std.c++ Subject: Re: Why is there no range type in the standard library? Date: 11 Aug 2003 02:05:07 GMT Organization: http://groups.google.com/ Lines: 109 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <95e0e5ef.0308101430.454aced2@posting.google.com> References: <95e0e5ef.0308060330.28aefaae@posting.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Return-Path: 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) Delivered-To: std-c++@ucar.edu X-Trace: posting.google.com 1060554628 1080 127.0.0.1 (10 Aug 2003 22:30:28 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 10 Aug 2003 22:30:28 GMT X-Spam-Status: No, hits=-15.4 required=10.0 tests=BAYES_00,FORGED_YAHOO_RCVD,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Xref: archiver1.google.com comp.std.c++:20566 bop2@telia.com ("Bo Persson") wrote in message news:... > "Chris Newton" skrev i > meddelandet news:bh4192$fan$1@hercules.btinternet.com... > > Stefan Heinzmann wrote [abridged]... > > > Given that the notion of an iterator range is rather fundamental > in > > > the standard library, I wonder why this wasn't turned into a class > > > template in the STL. > > Possibly becase it would rule out some kinds of iterators, making the > entire concept less powerful. I don't see what kind of iterator would be ruled out. Could you give an example? > >> Something like this: > > > > > > template > > > struct iterator_range { > > > Iter begin, end; > > This requires the range to be constant. Usually, nothing reqires > container.end() to remain constant in a loop. If it doesn't remain constant, you're in trouble. It means you can't use most of the STL algorithms either, because they take a copy of the iterators. You would have to use plain for loops and have the container.end() expression evaluated in each loop iteration. What difference is there between passing two separate iterators to an algorithm and passing a range object containing two iterators? > > > > > > size_t size() const { return std::distance(begin,end); } > > This rules out the use of input and output iterators. How would you > compute the distance() for some keyboard input? You don't. If distance isn't available for the underlying iterator then size() isn't either. SFINAE. [...] > > > bool operator==(const Iter& rhs) const > > > { return (begin == rhs.begin) && (end == rhs.end); } > > This rules out not only input and output iterators, but also filtering > iterators. Just because begin() and end() compares equal, the > intermediate values does not have to be the same, or the same number. That begs the question what it means if two ranges of input iterators are equal. Maybe equality is not that useful for an iterator range... > > > // ... potentially more methods here > > > }; > > > > I've often wondered about this myself. A lot of algorithms > inherently > > run over a range, and a single range object more naturally and > flexibly > > represents the required concept than a pair of iterators. Consider, > for > > example, the typical loop implied by many standard algorithms: > > > > for (iterator_type it = begin_it; it != end_it; ++it) { ... } > > I would say that this would be typical for a for_each() call, where > the iterator values *are* captured at the point of call. An ordinary > for loop is much more powerful. Nothing prevents you from using for loops if you prefer. I was interested in using the algorithms in the standard library (for_each and a *lot* more) and my question was whether this can be made safer and more convenient by a range class. [...] > > In general, I think that supporting the concept of a range would > allow > > more natural extension of the standard library to support newer data > > structures and algorithms, as well as offering a cleaner > presentation of > > what is already available. > > But you would also need to keep at least some of the current library, > as it presents a more general interface. Then you will have some > algorithms for range types and some for iterators. I don't immediately > see how this makes it cleaner. Keeping the current stuff would for the very least be necessary for backwards compatibility. I imagine I even would get the boot for suggesting that the methods and algorithms taking separate iterators be declared obsolete. I don't see, however, why the current interface is more general. If you've got a range type you can always get at the individual iterators, and if you've got separate iterators you can easily combine them to form a range object. The provision of a convenience function template akin to std::make_pair has already been suggested. In my view the two alternatives are equivalent, with the one based on the range type being clearer and safer in my opinion. Cheers Stefan --- [ 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 ]