From: Thomas Richter on 14 Feb 2010 08:31 Nevin :-] Liber wrote: >> On Feb 12,> It's easy to do static checking of throw specifications at compile >> time because the compiler knows the throw spec of all the called >> functions, because it has to see the prototype before it can compile >> the call. > > Again, I just don't see how you can analyze this without whole program > analysis, which isn't trivial. > > GIven the following: > > struct Foo > { > virtual void Bar() const = 0; > }; > > > bool DoIThrow(Foo const& f) > { > try { f.Bar(); return false; } > catch (...) { return true; } > } > > > So, what does DoIThrow() return: true or false? > > Personally, I don't know how to do the analysis w/o looking at *every* > derived class of DoIThrow. What is your "easy" way to figure this out? With the proposal at hand, f.Bar() has no "throw()" specification and hence *might* throw, thus DoITThrow *may* return true. It's as much as saying that "const cannot be checked without whole program analysis". Anyhow, the discussion is pointless because throw() already *does* have a meaning. A not very usable one for my purposes, but it does. > And this is still a fairly simple case... Indeed. Greetings, Thomas -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: ThosRTanner on 15 Feb 2010 05:47
On Feb 13, 3:39 am, "Nevin :-] Liber" <ne...(a)eviloverlord.com> wrote: > In article > <6bb964cd-04bb-49b0-b344-a17a2e943...(a)b7g2000yqd.googlegroups.com>, > ThosRTanner <ttann...(a)bloomberg.net> wrote: > > > On Feb 12,> It's easy to do static checking of throw specifications at compile > > time because the compiler knows the throw spec of all the called > > functions, because it has to see the prototype before it can compile > > the call. > > Again, I just don't see how you can analyze this without whole program > analysis, which isn't trivial. > > GIven the following: > > struct Foo > { > virtual void Bar() const = 0; > > }; > > bool DoIThrow(Foo const& f) > { > try { f.Bar(); return false; } > catch (...) { return true; } > > } > > So, what does DoIThrow() return: true or false? > > Personally, I don't know how to do the analysis w/o looking at *every* > derived class of DoIThrow. What is your "easy" way to figure this out? > > And this is still a fairly simple case... > It's not really necessary to know. From the throw specs, it can throw anything. As far as the compilation goes, that's all that you need to know. So this: void wibble() throw(std::exception) { Foo f; DoIThrow(f); } can terminate your program. What further analysis is necessary? I don't care what it throws. All I care is that it can throw something that wibble() says it can't throw. It's exactly the same as const: void fiddle(char *f); char const *s = "abd"; fiddle(s); won't compile. Not that you know whether or not fiddle changes s. The function prototype says it can. And so it won't compile, and a good thing too. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |