From 6519857825222213061 X-Google-Thread: f78e5,a5065ede37bcf8d6 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.speakeasy.net!news.speakeasy.net.POSTED!not-for-mail NNTP-Posting-Date: Thu, 15 Sep 2005 21:30:06 -0500 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 From: "kanze" Newsgroups: comp.std.c++ Subject: =?iso-8859-1?q?Re:_Problems_interpreting_requirement_for_std::copy_(=A725.2.1)?= Organization: http://groups.google.com Message-ID: <1126777947.114176.131040@g47g2000cwa.googlegroups.com> References: <1126258566.887901.223500@g43g2000cwa.googlegroups.com> <3qlVe.538$pq6.9733@twister2.libero.it> <1126690042.222765.230600@f14g2000cwb.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Complaints-To: groups-abuse@google.com User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: g47g2000cwa.googlegroups.com; posting-host=62.160.54.162; posting-account=qsfl8gwAAABZGaLp2a7FeTfDkJamzWYW X-Virus-Scanned: amavisd-new at ucar.edu Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.ucar.edu id j8FAW9NC022443 X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Approved: Fergus Henderson , moderator of comp.std.c++ X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Date: Thu, 15 Sep 2005 21:24:26 CST Lines: 75 NNTP-Posting-Host: 65.182.171.162 X-Trace: sv3-iogvnF4z8gmez4I5bZDkLEHVSHpBFsjHFV4ukoqF/wNaFab4/vJvDSgi7/ucf1C5tb86TjHsIkb09Vf!lorjBqZhKeJBCodL8YQ5YqkBuIez2E9nnda8E/TwcxZUwSmlTEiyu6UA3SbMh/jbZIuLBZVwsTu7!c3RBVh/QcVEVcySZJ3HOV1z7MqZKnkT5ddPQpisuSWQ= X-Complaints-To: abuse@speakeasy.net X-DMCA-Complaints-To: abuse@speakeasy.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.std.c++:2128 Alberto Ganesh Barbati wrote: > kanze wrote: > > Alberto Ganesh Barbati wrote: > >>Gabriel Dos Reis wrote: > > [...] > >>>Consider this: > >>> p = l.end(); > >>> l.push_back(8); > >>> q = l.end(); > >>> assert (p == q); > >>That might happen for some (probably most) implementations > >>of std::list, but I could find no statement in the standard > >>that provides such guarantee. If you think such guarantee is > >>provided, I will be glad to have a precise reference in the > >>standard. Without an explicit or implicit guarantee you > >>cannot assume that the expression in the assert always true > >>for all conformant implementations of std::list. > > �23.2.23/1, in the decription of insert, push_front and > > push_back: "Does not affect the validity of iterators and > > references." > > I don't find an exact definition in the standard as to what > > it means by validity, but from the actual use, I think it > > means that the iterator continues to designate the same > > element (or in the case of end(), it continues to designate > > an element one past the end). > I agree that the statement means that a valid past-the-end > iterator remains valid after a push_back, but it's not obvious > to me that it should remain a past-the-end iterator. One could > implement a past-the-end iterator in such a way that, after a > push_back, it points to (newly added) last element and I don't > see how such implementation would be violating the > standard. Of course I may be missing something. I think it is the standard which is missing something, but I may have just missed it. What is missing is the definition of what it means for an iterator to remaind valid. Given the total set of specifications as to when an iterator remains valid, and when it doesn't, I think that the definition is that an iterator remains valid if and only if it can still be used AND still designates the same element (with one past the end being considered a "virtual" element). If we assume only the first part of this requirement, of course, vector<>::erase whould only invalidate the last n iterators (where n is the number of elements begin erased), and not all of the iterators past the point of erase. And vector::insert would only invalid iterators if reallocation occured; a correctly dimensionned reserve could guarantee that it never invalided an iterator. I am exterpolating this definition from the total set of the validity specifications, however, and it would be much nicer if the standard said it explicitly. -- James Kanze GABI Software Conseils en informatique orient�e objet/ Beratung in objektorientierter Datenverarbeitung 9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34 --- [ 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 ]