From: Thomas Richter on
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
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! ]