From 5307573696142011954 X-Google-Thread: f78e5,a5065ede37bcf8d6 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news2.google.com!newsread.com!news-xfer.newsread.com!news.alt.net!comp-std-cpp-robomod!not-for-mail From: "kanze" Newsgroups: comp.std.c++ Subject: =?iso-8859-1?q?Re:_Problems_interpreting_requirement_for_std::copy_(=A725.2.1)?= Date: 14 Sep 2005 05:10:24 GMT Organization: http://groups.google.com Lines: 79 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <1126598545.817792.304560@o13g2000cwo.googlegroups.com> References: <1126258566.887901.223500@g43g2000cwa.googlegroups.com> <3qlVe.538$pq6.9733@twister2.libero.it> Mime-Version: 1.0 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 1126598551 3051 127.0.0.1 (13 Sep 2005 08:02:31 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 13 Sep 2005 08:02:31 +0000 (UTC) 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: o13g2000cwo.googlegroups.com; posting-host=62.160.54.162; posting-account=qsfl8gwAAABZGaLp2a7FeTfDkJamzWYW X-Virus-Scanned: amavisd-new at ucar.edu X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.ucar.edu id j8D82dNC009528 X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Xref: g2news1.google.com comp.std.c++:2093 Gabriel Dos Reis wrote: > AlbertoBarbati@libero.it (Alberto Ganesh Barbati) writes: > | kanze wrote: > | > Finally, what about something like: > | > copy( l.begin(), l.end(), back_inserter( l ) ) ; > | > I think that, realistically, this will generally result in > | > an endless loop. And yet, it requires quite a stretch of > | > the imagination to say that back_inserter( l ) is in the > | > range of [l.begin(),l.end()). > | It doesn't result in an endless loop, because l.end() is not > | re-evaluated during the execution of copy. > the "because" part is irrelevant. See below. > And James' claim that the l.end() is invalidated is bogus. Agreed. I was thinking of something else. The results of a v.end(), where v is a vector or a deque, are invalidated by dereferencing a back_inserter. The results of l.end(), where l is a list, aren't. (Intuitively, I find it convenient to imagine that the iterator returned by end() points to a virtual element, which is always behind all of the real elements in the list. And that the rules concerning invalidation of iterators apply to it in exactly the same way they apply to iterators designating real objects.) > | The value which is passed as the "last" parameter remains a > | valid iterator which keeps pointing to the same element for > | the whole execution of the algorithm. Therefore the > | statement will effectively just append a entire copy of l at > | the end of l itself. > Consider this: > p = l.end(); > l.push_back(8); > q = l.end(); > assert (p == q); Guaranteed, I believe. There are subtle issues concerning the copy function above. I would normally presume that something like: while ( begin != end ) { *dest ++ = *begin ++ ; } would be a legal implementation of std::copy. As would be: while ( begin != end ) { *dest = *begin ; ++ dest ; ++ begin ; } It's interesting to note, however, that they have different behavior in the case above. -- 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 ]