From 8593296178722655154 X-Google-Thread: f78e5,3c316a202087bfac X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!news4.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: Fri, 21 Apr 2006 08:30:04 -0500 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on ak74.algebra.com X-Spam-Level: *** X-Spam-Status: No, score=3.4 required=5.0 tests=HEADER_SPAM,MISSING_HEADERS, TO_CC_NONE autolearn=disabled version=3.1.1 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) X-Original-To: std-c++@mailman.ucar.edu Delivered-To: std-c++@mailman.ucar.edu Delivered-To: std-c++@ucar.edu From: "ThosRTanner" Newsgroups: comp.std.c++ Subject: Re: Defining undefined, etc., behavior Organization: http://groups.google.com Message-ID: <1145616430.013950.317090@u72g2000cwu.googlegroups.com> References: <123m587c3abqge4@corp.supernews.com> <1145261505.465774.326140@z34g2000cwc.googlegroups.com> <4ahscsFtangcU1@individual.net> <1145436601.054028.10610@e56g2000cwe.googlegroups.com> <4an60dFtvqu9U1@individual.net> <1145532546.503324.321250@t31g2000cwb.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 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: u72g2000cwu.googlegroups.com; posting-host=199.172.169.15; posting-account=WDL57QwAAADh6I7Opo5K2PCbyz8hJhRA X-Virus-Scanned: amavisd-new at ucar.edu 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: Fri, 21 Apr 2006 08:22:58 CST Lines: 106 NNTP-Posting-Host: 65.182.171.162 X-Trace: sv3-ihStcavDtSGRJiMvRZ1NdybNU/mDp2fG2G8CJ0LsK3pdWfH7XFHEQTkJ5aPBWs9CRD7LJS69fP8i2JT!2mqTHZxGriakdP0Ax6KXrA+YXOP95+fZY5dQf69FYRLKwVw9QBljOLeimwgzMz7ZO1kWg3fW8O51!m48fesPSf0BZ+5ji63k0oIcwK0RHdCK4QfHSawdq+yA= 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: g2news2.google.com comp.std.c++:1632 kuyper@wizard.net wrote: > Bo Persson wrote: > > "ThosRTanner" skrev i meddelandet > > news:1145436601.054028.10610@e56g2000cwe.googlegroups.com... > > > > > > "Bo Persson" wrote: > . > > >> > All of these can be detected by the compiler. > > >> > > >> That's the problem. They can *sometimes* be detected by the > > >> compiler. > > >> What happens when they cannot? > > > Please provide an instance where a conformant compiler cannot detect > > > with 100% accuracy whether the throw spec for a function being > > > called > > > is "looser" than the throw spec for the calling function. > > > > Try this one: > > > > void g(int x) > > { > > if (x > 5) > > throw "parameter error"; > > } > > > > void f(int x) throw() > > { > > if (x < 5) > > g(x); > > } > > > > Will that compile? > > The throw spec for g() allows it to throw anything, which is > unambiguously looser than the throw spec for f(), which is not allowed > to throw anything, and this fact is trivially detectable by the > compiler at the point where g() is called. How does this count as a > response to a challenge to provide 'an instance where a conformant > compiler cannot detect with 100% accuracy whether the throw spec for a > function being called is "looser" than the throw spec for the calling > function.' ? > > I suspect that you're misreading the proposal. It's the throw > specification of the called function that is being compared with the > throw specification of the calling function. It doesn't matter whether > or not the called function actually throws an exception inconsistent > with the calling function's specification. All that matters is whether > the called function has a specification that would allow it to throw > such an exception. > > > template > > void f() throw() > > { > > T::g(); > > } > > Whether or not the throw specification of g() is looser than that of > f() can not be determined at the time of the template definition, but > it's also true that you can't even determine whether or not g() > actually exists at that point. Both the existence of g(), and it's > possession of a looser throw specification f()'s, can trivially be > detected with 100% accuracy at the point of instantiation of f; > assuming that the instantiation is legal (which requires that the > definition of T be in visible). > > > > All functions have throw specifications (a lack of throw spec means > > > you > > > can throw anything). > > > > Which includes most of the standard library. Should you not be allowed > > to use that? > > The proposed change would still allow you to call such functions; it > would just require you to either catch all of the exceptions that might > be thrown by such a function, or to give your own function a completely > open throw spec. > > There are many valid arguments that could be made against this > proposal, such as the fact that it would break a lot of existing code, > but the infeasibility of implementation isn't one of them. That's why I suggested adding 'static' or some such keyword after the throw keyword in the specifcation. That would break no existing code. I admit having implicit 'throw static ()' for destructors and extern "C" declarations probably would break existing code, but extern "C" actually needs this behaviour (real C functions can't throw anything, and throwing an exception into a C caller is very dangerous), and also the usual technique of wrapping C headers: #ifdef __cplusplus extern "C" { #endif void func1(int arg1, etc); wouldn't work very well without the implicit throw static () As for destructors - I'd accept an obligatory compiler warning and an obligatory compiler option! --- [ 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 ]