From -3409618043298892656 X-Google-Thread: f78e5,1130da7a3640a78c X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!news4.google.com!news.glorb.com!newsfeed101.telia.com!nf02.dk.telia.net!news.tele.dk!news.tele.dk!small.news.tele.dk!lnewsinpeer00.lnd.ops.eu.uu.net!emea.uu.net!peer-uk.news.demon.net!kibo.news.demon.net!mutlu.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: jdennett@cox.net (James Dennett) Newsgroups: comp.std.c++ Subject: Re: Deprecate the use of plain pointers as standard container iterators Date: Mon, 22 May 2006 01:28:26 GMT Organization: Cox Communications Lines: 117 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <1146830242.416436.272780@g10g2000cwb.googlegroups.com> <2tK6g.41669$iU2.38767@fed1read01> <1147094771.992837.37160@j33g2000cwa.googlegroups.com> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.demon.co.uk 1148261602 18201 158.152.254.254 (22 May 2006 01:33:22 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Mon, 22 May 2006 01:33:22 +0000 (UTC) X-Original-To: std-c++@mailman.ucar.edu X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) X-Greylisting: NO DELAY (Relay+Sender autoqualified); processed by UCSD_GL-v2.1 on mailbox10.ucsd.edu; Sun, 21 May 2006 10:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Path: comp-std-cpp-robomod!not-for-mail X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id k4M1SQEi004186; Mon, 22 May 2006 11:28:26 +1000 (EST) X-NNTP-Posting-Date: Sun, 21 May 2006 13:34:23 EDT X-Delivered-To: std-c++@ucar.edu X-Spamscanner: mailbox10.ucsd.edu (v1.6 Aug 4 2005 15:27:38, -2.8/5.0 3.0.4) X-Authentication-Warning: fed1read01.mgt.cox.net: news set sender to newsmaster@cox.net using -f X-Newsgroups: comp.std.c++ X-MailScanner: PASSED (v1.2.8 83139 k4LHYbkO083102 mailbox10.ucsd.edu) Xref: g2news2.google.com comp.std.c++:2077 Nicola Musatti wrote: > James Dennett wrote: >> Nicola Musatti wrote: > [...] >>> If std::vector<>::iterator is a pointer the expression ++v.begin() is >>> invalid because it attempts to modify an rvalue. >> std::sort(boost::next(v.begin()), v.end()); > > Imagine for a moment that you are teaching the standard library to not > very expert C++ programmers. Would you really be happy to tell them > that in order to advance an iterator one position they need to call a > third party function? I'd prefer to advise them to re-write this one in their own library, unless they were already using boost. If boost was in use, I wouldn't feel bad about recommending use of boost::next and boost::prior. > But, wait, it will probably be in the standard in > less than five years! The implementation with which I have to do most of my current work won't let me take the std::distance between two iterators in the obvious way; I won't hold my breath waiting for anything new to become available. Third party library support does move much faster than the standardization process. (It's Sun's CC, incidentally; the compiler has improved a lot of late, but for backwards compatibility reasons its default standard library has not changed in a long, long time, and still does not assume support for partial specialization or for template members. Support for STLPort v4 is included, but as no third-party libraries support that, it's not an option for us. Sun's reasons are valid; ABI stability of C++ on Solaris is pretty much rock solid, but the cost is being frozen into a (large) pre-1998 subset of C++.) >> works and is generic (and of course boost::next is >> trivial to implement). > > It's still much clumsier than ++v.begin() . I'm not sure about that. v.begin()+1 is more reasonable; incrementing an rvalue seems relatively unnatural to me, though I imagine that's influenced by C++'s specific rules. > [...] >>> int * find(int * b, int * e, int d) { >>> return b + d < e ? b + d : e; >>> } > > // ... >>> std::vector::iterator i = find(v.begin(), v.end(), 2); >>> std::cout << ( i != v.end() ? *i : 0 ) << '\n'; >>> >>> If std::vector<>::iterator is a pointer the user defined find function >>> is chosen. >> What's to say that std::vector::iterator might not be >> a UDT defined in a namespace nested within ::std? In that >> case your code might also find no "find", or the wrong >> "find"? It sounds like you wish to require that the >> iterators must be of a type defined in namespace ::std; > > No, I'm merely saying that the syntax and behaviour of the standard > library should be consistent across platforms, which it's not. Nor even is that of C, and nor is the underlying language. Completely abstracting away the underlying platform is too expensive. The harder question is to determine how consistent the standard library should be, and there it's appropriate to leave behavior unspecified or implementation- specified (or even undefined). >> the question is whether the benefit is worth the cost, >> which might be slower performance on some systems (as >> well as possibly encouraging people to write code in a >> less robust style by relying on ADL where it's not needed). > > Are you suggesting that pitfalls should be carefully sprinkled > throughout the language so that people could learn more from > experience? I said nothing of the kind. Using unqualified names when you want a specific entity makes for less clear code, in my opinion. This pitfall affects only code which should be better written in any case. I will say that ADL does have real pitfalls though, and I'm not sure that it's inclusion was the right solution to the perceived problem, but that's a separate issue. I'd like to limit the number of pitfalls, but that can be done more by making it easy to avoid the dark corners; one way to do that is to disable ADL when you don't want it. As a QoI issue, a stdlib implementation ought to at least provide a debugging mode where all iterators are UDTs, even if the associated compiler needs raw iterators for std::vector and std::basic_string to maximize performance. > As to the performance related argument I'm aware of its > existance and I consider it the most concrete one against my proposal. > On the other hand the deprecation mechanisim is there exactly in order > to guarantee compiler vendors enough time to fix things. The deprecation mechanism ought to be deprecated and replaced by one which actually results in things being removed from the standard eventually :) -- James --- [ 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.comeaucomputing.com/csc/faq.html ]