From 7836679178471884371 X-Google-Thread: f78e5,82cd3599ce330676 X-Google-NewGroupId: yes X-Google-Attributes: gid7894ca11fe,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Thu, 08 Apr 2010 12:40:08 -0500 Return-Path: To: (Usenet) From: Rani Sharoni Newsgroups: comp.std.c++ Subject: Re: throwing in a noexcept(true) function Organization: http://groups.google.com Sender: cppmods@cs.rpi.edu Approved: austern@google.com Message-ID: References: <4BB4D8B0.3070603@f2.dion.ne.jp> <4BB73613.2040903@f2.dion.ne.jp> Content-Type: text/plain; charset=ISO-8859-1 X-Original-Date: Wed, 7 Apr 2010 23:28:50 -0700 (PDT) X-Submission-Address: std-c++@netlab.cs.rpi.edu Date: Thu, 8 Apr 2010 12:37:27 CST Lines: 70 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-DBn4Q/pRT46uRhk5yMLPwDiEQTTCEhK1qU49O6KFaWe/lqoZlc5dwfhGsb0kunk2rgnS9D78J3SaH64!EB1Gtgbd5nexBd5Ta8eozAoPK/HYbm6QsmNef0mmo1Ua/erHcxD4S4Eper2om6AZEnaVmRvjk3gN!/6Xkez8G5q/8iCqeJXGZ8tEaGbU= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html 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.40 Xref: g2news1.google.com comp.std.c++:2397 On Apr 5, 9:36 am, Herb Sutter wrote: > On Sun, 4 Apr 2010 12:04:30 CST, Kazutoshi Satoda wrote: > >Like this: > > > template > > > class vector { > > ... > > iterator erase(const_iterator position) noexcept( > > has_nothrow_copy_constructor::value && > > This seems problematic for several reasons, mostly on the grounds of > usability: > > - Usability: To me, this falls squarely into "the cure is worse than > the disease" territory. A few library writers may do this to gain some > potential performance (and they can do it whether we mandate static > checking or not!), but C++ programmers in general are just not going > to write this code (and mandating static checking would attempt to > make them do so). If the goal is to allow C++ programmers in general > to write "this doesn't throw" on a function in order to make it > faster, which I suspect is the goal for many, I don't think this meets > the bar. > > - Usability: Requiring static checking means you couldn't > instantiate vector and call erase with any type T that doesn't > write noexcept on its user-written special functions, right? Looks like a classic post, Herb. There is also the run-time conditional no-throw code like push_back into vector with sufficient capacity (I often see such code in which reserve is first used to assure no resize). such conditional no- throw code can be safely called from noexcept function without try- catch (dead-code). Another common example is map[key] lookup which is no-throw is the item is already in the map. Even regardless of conditional no-throw (that Java doesn't address) there is the legacy code. tons of non-throwing code is out there (e.g. on windows, COM using error codes) so noexcept better be polite not to break such. Static no-throw diagnostics actually do exist but they are matter of QOI. For example, VC warns about code like void f() throw() { throw 1; } (proven throw) and there is also unreachable-code warning when try-catch is used for (proven) non-throwing code (a bit noisy in generic code). Regrading noexcpt violations, I think that we all agree that such violations are not a feature (used to terminate the program) but a bug and traditionally in (non-safe language) C++ bug-mitigation is mater of QOI (e.g. memory corruption handling). FWIW, one of the intentions of noexcpt was to relax the mandatory violation handling of current throw exception specifications in order to allow optimizations. I recently heard that no-throw optimizations might not be impacted by mandatory violation handling but it's still debatable (so it seems we should yet again resort to QOI). Rani -- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]