Q2: templates and throw specification

[Michael Kilburn]

Hi

I am looking for description of G++'s behavior related to usage of
throw specifications with template functions. Settings:
- Linux on x86
- G++ v4.0.3, ld v2.15

questions:

1. As far as I understand GCC implements table-driven exceptions. Is
it correct?

2. GCC implements exception specs according to standard, i.e. writing
void foo() throw() { ... }
is equivalent to
void foo() throw() { try{ ... } catch(...) { unexpected(); } }
on latest MSVC compiler (not mentioning that by default MSVC's
catch(...) will catch SEHs too :-) )

As the result of this throw specification could be costly because
optimizer will be limited somewhat, inlining could be affected and
exception tables will grow. Is it correct?

But if foo() uses only nothrow operations aforementioned try/catch
block will not be created (or will be optimized away) thus actually
making code better, because foo's callers will benefit from the fact
that foo() never throws. Is it correct?

3. Now, the most important question -- does GCC generates throw spec
for functions instantiated from a template?

I.e. let say we have this:
void op1();
void op2() throw();

template<int> foo();
template<> foo<1>() { op1(); }
template<> foo<2>() { op2(); }

void main()
{
    foo<1>(); // (1)
    foo<2>(); // (2)
}

what exception specs will get functions instantiated at (1) and (2)?
(not getting specification is equivalent of getting 'throws anything'
spec)
Does GCC analyzes foo's body in order to generate throw spec at the
point of instantiation? (which is very important in STL where template
functions are being called from other template functions) I.e could I
assume that in this case:

int func(std::vector<int> const& v) throw()
{
   return v.empty() ? 0 : v[0];
}

vector::empty()  and vector::operator[]() have nothrow spec and as a
result func's nothrow spec does not incur any penalty described in
question #2? Is it possible to generate a warning when throw spec does
incur a penalty? (e.g. when 'int' in this example is replaced by a
class that could throw in copy constructor)


4. and the last question -- why -fno-enforce-eh-specs option increased
resulting image size by ~5Mb (from ~39Mb)? O_O I'd expect it to do
exactly opposite...


Bye.
Sincerely yours, Michael.