Re: EH & Optimization
"Staffan Langin" wrote:
a) compiler must ensure that the function indeed behaves
according to its exception specification, i.e. instead of
optimizing out irrelevant code now compiler must generate
something like this:
try
{
void foo() throw() // won't throw
}
catch(...)
{
std::unexpected();
}
According to the C++ standard, std::unexpected is invoked
when a handler encounters the outermost block of a
function with an expection-specification different from
the exception thrown. AFAIK, there is no requirement to
implement the verification of the exception-specification
the way your code-snippet suggests.
And if `foo' throws, then what is it if not "a function with
an exception-specification different from the exception
thrown"? Empty exception specification is just a specific
case, which obeys the same rules as non-empty one.
Correct implementation of exception specification is
definite pessimization, since compiler must generate the
code to enforce function's policy. With non-empty exception
specification list the above code would become:
try
{
void foo() throw(X, Y)
}
catch(X) { throw; }
catch(Y) { throw; }
catch(...)
{
std::unexpected();
}
(All this machinery might be placed within `foo' actually,
but it's not important.)
However, MS VC++2005 compiler ignores exception
specification, except the empty one. In case of `throw()' it
behaves exactly the opposite [__declspec(nothrow)] of what
the Standard requires, as Carl Daniel already pointed.
c) exception specification almost certainly prevents
inlining;
That's interesting. I don't see why it should and it
contradicts with my own experiences. Could you please
elaborate.
I never investigated much all inlining deal breakers with
VC++, however I did read it many times in articles of quite
knowledgeable people (including Herb Sutter and Scott
Meyers, for example). The reason is simple. In order to
enforce exception specification compiler must wrap
functions's content with "try...catch" block. So, the
content is already indivisible. Apparently many compilers
decided that inlining in such conditions doesn't worth the
effort.
Also, my colleagues, who live in *nix world and work with
gcc confirmed that exception specification prevented
inlining. Here's what I found regarding this:
"Using exception specifications to help compiler"
http://gcc.gnu.org/ml/gcc/2003-06/msg00375.html
I don't have first hand info on VC++2005 behavior, though.
Simplified, the class hierachy looks something along the
line of:
[...]
template<class Types>
Context<Types>::Context() throw()
{
//Here the SEH prolog/epilog are emitted and only for
array-members.
}
I can only assume that in presence of templates compiler
plays on the safe side. You could try "#pragma optimize("y",
on)" for `Context' constructor. However, I think you already
have optimization switches which imply /Oy.
Alex