From -4994603119051059822 X-Google-Thread: f78e5,49e4bf97841f1e8f X-Google-Attributes: gidf78e5,public,usenet X-Google-Language: ENGLISH,UTF8 Path: g2news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!tiscali!newsfeed1.ip.tiscali.net!news.tiscali.de!newsfeed.hanau.net!newsfeed.vmunix.org!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: AlbertoBarbati@libero.it (Alberto Ganesh Barbati) Newsgroups: comp.std.c++ Subject: Re: Minor modification: nothrow guarantee for clear() in sequence container Date: Sat, 4 Aug 2007 15:24:17 GMT Organization: [Infostrada] Lines: 102 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <46a49bd4$0$1084$426a34cc@news.free.fr> <1185781837.435107.100540@q75g2000hsh.googlegroups.com> <87643zphxb.fsf@grogan.peloton> <1186057361.918031.139230@19g2000hsx.googlegroups.com> <87hcnh3kfm.fsf@grogan.peloton> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: news.demon.co.uk 1186241061 24356 158.152.254.254 (4 Aug 2007 15:24:21 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sat, 4 Aug 2007 15:24:21 +0000 (UTC) X-Original-To: std-c++@mailman.ucar.edu X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-IronPort-Anti-Spam-Result: Ao8CAFIAtEbBRsBn/2dsb2JhbAA X-MIME-Autoconverted: from 8bit to quoted-printable by mulga.csse.unimelb.edu.au id l74FOIOJ029630 X-IronPort-Anti-Spam-Filtered: true X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au X-Path: comp-std-cpp-robomod!not-for-mail X-Received: (from fjh@localhost) by mulga.csse.unimelb.edu.au (8.13.8+Sun/8.13.8/Submit) id l74FOH1U029605; Sun, 5 Aug 2007 01:24:17 +1000 (EST) X-NNTP-Posting-Date: Sat, 04 Aug 2007 13:29:53 MET DST X-Delivered-To: std-c++@mailman.ucar.edu X-Authentication-Warning: mulga.csse.unimelb.edu.au: fjh set sender to devnull@stump.algebra.com using -f X-Newsgroups: comp.std.c++ Xref: g2news2.google.com comp.std.c++:475 David Abrahams ha scritto: >=20 > It would be pretty easy to make a backwards-compatible, nonthrowing > clear. In fact, I'm willing to bet that every single implementation > of clear is already nonthrowing in practice. We just need the > standardese to bless that. Then I'd like to go one step further and > lift the move/copy ctor requirement. None of these changes could > possibly have an effect on program semantics unless the standard > library implementation had perverted implementation of erase that > needlessly copied elements. >=20 Allow me to recap. All references are relative to the latest draft N2315, 23.1/10 says that: "Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following additional requirements: =E2=80=94 [...] =E2=80=94 no erase(), pop_back() or pop_front() function throws an except= ion. - [...]" The 23.2.2.3 and 23.2.5.4 clauses mention erase() in these terms: "Throws: Nothing unless an exception is thrown by the copy constructor or assignment operator of T." Then, we have table 88 that defines clear() in terms of erase(begin(), end()). Finally, 23.2.3.3 makes list special, by requiring the no-throw guarantee explicitly for clear(). Now we have two goals: 1) expressing a no-throw guarantee for deque::clear() and vector::clear() 2) lift the move/copy requirements from deque::clear() and vector::clear() (as we will see below, there are no such requirement for list::clear(), right now) There are many ways to achieve that, of course. I'm pretty sure we can find a solution that doesn't break existing code. The first thing that comes to my mind is: erase() can throw only when calling copy constructors or assignment operators, so what if it doesn't call any? It could not throw then! But when does erase() actually need to call them? For a vector, that happens if and only if last !=3D end(). For a deque if and only if first !=3D begin() and last !=3D end(). The requirements for the invalidation of references implicitly mandate that. So why not state the requirement explicitly? For example, for vector, we could change 23.2.5.2/5 from "Effects: Invalidates iterators and references at or after the point of the erase." to "Effects: Invalidates iterators and references at or after the point of the erase. If position =3D=3D end() or last =3D=3D end() no element is co= pied." Similarly for deque. This will quickly and easily get rid of goal number 1 as well as being a useful clarification on erase(). Before considering goal number 2, let me point your attention to the fact that, currently, Table 88 puts *no* requirements on T for both methods erase() and clear(). I guess that's because for list there are no such requirements, but somehow they are missing even for vector and deque in the full specifications of those containers! Of course we know that vector::erase() and deque::erase() can't be implemented without at least CopyAssignable or MoveAssignable (we don't actually need CopyContructible nor MoveConstructible, I think). I think the standard might specify this fact more explicitly. This can be done by simply adding in the specifications of erase() in 23.2.2.3 and 23.2.5.4 a new paragraphs like: "Requires: T shall be CopyAssignable or MoveAssignable." Back to goal number 2, one simple solution might be to provide a full specification clear() in addition to table 88, in line with: "void clear(); Requires: Despite clear() is defined in terms of erase(), T need not be CopyAssignable or MoveAssignable. Effects: as if erase(begin(), end()). Throws: nothing." The "as if" takes care that the semantic remains the same as the current standard, but without imposing unneeded requirements on T. Any comments? Ganesh --- [ 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 ]