From 903599563560970537 X-Google-Thread: f78e5,82cd3599ce330676 X-Google-NewGroupId: yes X-Google-Attributes: gid7894ca11fe,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!news.glorb.com!news.alt.net!frodo.cs.rpi.edu!not-for-mail From: Kazutoshi Satoda Newsgroups: comp.std.c++ Subject: Re: throwing in a noexcept(true) function Date: Fri, 2 Apr 2010 00:06:38 CST Organization: unknown Lines: 58 Sender: cppmods@cs.rpi.edu Approved: austern@google.com Message-ID: <4BB4D8B0.3070603@f2.dion.ne.jp> NNTP-Posting-Host: netlab.cs.rpi.edu Content-Type: text/plain; charset=UTF-8; format=flowed To: (Usenet) Return-Path: X-Original-Date: Fri, 02 Apr 2010 02:32:32 +0900 X-Submission-Address: std-c++@netlab.cs.rpi.edu Xref: g2news2.google.com comp.std.c++:2359 To summarize, the main two points of view that were expressed were >> that that trying to propagate an exception out of a noexcept function >> should result in: >> a) All bets off: Undefined behavior [...] >> b) Termination: [...] >> The committee has currently penciled in (b). >> > Another choice that was suggested by some members of the BSI C++ Panel is: > c) implementation-defined behaviour > How about static checking? d) Render them ill-formed if possible (and terminate if not) void may_throw() noexcept(false); // ill-formed void f0() noexcept { may_throw(); } // well-formed but terminates at runtime if the exception was not caught void f1() noexcept { try { may_throw(); } catch (int) {} } // ill-formed void f2() noexcept { try { may_throw(); } catch (int) { may_throw(); } } // ill-formed void f3() noexcept { try { may_throw(); } catch (int) {} may_throw(); } Here, f0() can achieve zero-overhead. In f1(), compilers only have to adds an implicit handler - catch (...) { std::terminate(); } - at the end of explicit catch handlers. This behavior is same as the current draft, but the overhead will be buried under the existing cost of explicit handers. I believe compilers can check this in the same way to implement the operator noexcept(expr). Within this way, throw() will work as a way to escape from this static checking as needed to call old (having no exception specification) library functions, as const_cast works for const correctness. This may require huge amount of efforts to ensure that the standard library functions and compiler generated functions are suitably annotated with noexcept. But I think the new exception specification is not worth adding unless it enables static checking, and I'm afraid of that current draft (choice b) will make noexcept accused of non-zero-overhead, as same as throw(), and to be another burden to introduce static checking later. -- k_satoda [ 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 ]