From 853264060353217950 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,8d7ae4b2a3e77f8b X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-08-09 18:31:31 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!news.gtei.net!newsfeed.mathworks.com!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: chrisnewton@no.junk.please.btinternet.com (Chris Newton) Newsgroups: comp.std.c++ Subject: Re: Why is there no range type in the standard library? Date: Sun, 10 Aug 2003 01:31:26 +0000 (UTC) Organization: BT Openworld Lines: 62 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <95e0e5ef.0308060330.28aefaae@posting.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: mail2news.demon.co.uk 1060479086 28481 10.0.0.1 (10 Aug 2003 01:31:26 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sun, 10 Aug 2003 01:31:26 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.12) id 19lf3M-0007PE-00 for mail2news@news.news.demon.net; Sun, 10 Aug 2003 01:31:25 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id LAA23531; Sun, 10 Aug 2003 11:31:21 +1000 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ucar.edu X-Newsgroups: comp.std.c++ X-NNTP-Posting-Date: Sat, 9 Aug 2003 23:48:51 +0000 (UTC) X-Accept-Language: en, en-us X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Spam-Status: No, hits=-6.2 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Xref: archiver1.google.com comp.std.c++:20549 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. Something like this: > > template > struct iterator_range { > Iter begin, end; > > size_t size() const { return std::distance(begin,end); } > bool empty() const { return begin == end; } > bool operator==(const Iter& rhs) const > { return (begin == rhs.begin) && (end == rhs.end); } > // ... 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) { ... } How could we provide iterators over a circular data structure that satisfied the usual equality operations, but also allowed us to run such an algorithm over an entire circular container? What would container_list::begin() and circular_list::end() mean in a context like that anyway? For a circular container, it makes more sense to define a single bidirectional "anchor" iterator (logically both begin() and end() would return this, if they were provided at all) and offer both a "whole" range, and a "partial" range based on two iterators, either or both of which might be the anchor. 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. One could also see plenty of applications for "filtered ranges", which again might be a more natural representation of some concepts than we current have with "iterator adapters" and such. It might also be useful to provide a make_range function template, analogous to make_pair, to build a suitable range from begin and end iterators if this makes sense and is unambiguous. Suitable data structures could provide their own specialisations. In cases like circular lists, where there is potential ambiguity, alternatives could be offered for each possibility instead, and no specialisation provided. Anyone mistakenly trying to use the ambiguous construction would receive a compile-time error, so as well as gaining a more natural interface to the algorithms, we also provide more robust checking than in an iterator pair solution. Regards, Chris --- [ 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 ]