More on exception handling (Arnaud?)

  • Thread starter Thread starter Vincent Fatica
  • Start date Start date
V

Vincent Fatica

It seems Arnaud was on target regarding the RTL inserting exception handling
routines. Here's another oddball occurrence on which I hope someone can shed
some light.

My EVENT struct is declared in a header file. If without making any source
changes, I move the definition of it constructor (shown below) from one source
(CPP) file to another, I get the same (apparently) 6144 byte increase in the
size of my target DLL. The same happens if I move the destrustor along with it
but does not happen if I move the destructor alone. Thanks!

EVENT::EVENT(HANDLE new_h, WCHAR* new_id, BOOL bAuto, BOOL bTemp)
{
h = new_h;
lstrcpy(id, new_id);
bTemporary = bTemp;
bAutoReset = bAuto;
dwEventCount += 1;
// linked list stuff below; add new EVENT at the end
pNextEvent = NULL;
if ( pLastEvent )
{
pLastEvent->pNextEvent = this;
pPrevEvent = pLastEvent;
}
else
{
pPrevEvent = NULL;
pFirstEvent = this;
}
pLastEvent = this;
}
 
Vincent Fatica said:
It seems Arnaud was on target regarding the RTL inserting exception
handling
routines. Here's another oddball occurrence on which I hope someone can
shed
some light.

My EVENT struct is declared in a header file. If without making any
source
changes, I move the definition of it constructor (shown below) from one
source
(CPP) file to another, I get the same (apparently) 6144 byte increase in
the
size of my target DLL. The same happens if I move the destrustor along
with it
but does not happen if I move the destructor alone. Thanks!
Click to expand...

That shouldn't happen if you turn on "Whole Program Optimization". When
both functions are visible to the compiler at the same time, it can optimize
cleanup in the case of exceptions, and avoid generating the extra code.
 
That shouldn't happen if you turn on "Whole Program Optimization". When
both functions are visible to the compiler at the same time, it can optimize
cleanup in the case of exceptions, and avoid generating the extra code.
Click to expand...

Indeed! Thank you very much. Now I can divide this thing up into manageable
chunks without penalty. Is there any reason *not* to use that option (besides
perhaps build time)?
 
Vincent Fatica said:
Indeed! Thank you very much. Now I can divide this thing up into
manageable
chunks without penalty. Is there any reason *not* to use that option
(besides
perhaps build time)?
Click to expand...

I think it's just one of the suite of optimization control options, so that
you can help the compiler team troubleshoot bugs by isolating them better.
There are a few reasons why you might not want it:

(1) It changes the object file format to contain abstract syntax trees
instead of object code. The compile step is actually performed during the
link process. This is often inappropriate for static libraries,
specifically those that will be distributed -- it makes the file far more
compiler version-dependent than it actually is, it leaks a lot more
intellectual property (since the AST is much closer to source), and I think
it also makes the files larger.

(2) It enables inlining across compilation units. This eliminates function
calls and therefore reduces the number of stack frames, degrading the
quality of stack traces. It also prevents techniques such as Detours
(hooking by rewriting function bodies in memory), because there is no longer
one single copy of the function.
 
Back
Top