/CLR in VC8 bloats image with unreferenced code

[Bern McCarty]

We upgraded a bunch of MEC++ code to C++/CLI about 10 months ago and we've
noticed that our images bloated quite a lot in the process. Upon
investigating I observed that when a /clr compiland includes a header file
for a native type that has an inlined copy constructor, that both the
inlined copy constructor and the inlined destructor for that same type will
end up in my mixed image, even though there is no reference made to that
native type from the source code of my dll at all. This is true even if the
..h containing the native type is included in a #pragma unmanaged section of
my compiland.

This seems like a bad compiler bug to me. I should pay zero runtime penalty
for including type information for types that I do not reference at all.
Don't you agree? Otherwise I have to go to the almost impossible difficulty
of minimizing the native type information observed by my mixed compiland.
But that ain't the C++ I know. That is an intractable task.

This bug is particularly annoying when it forces you to link with an import
library for a dll that you shouldn't have to link with at all. Suddenly your
binding closure balloons for no justifiable reason. This happens when you
see a native type (that you do not use) with an inline copy constructor and
destructor that references something in some other .dll (that you also do
not use). This bug may have something to do with exception handling/stack
unwinding. The linker errors that can be observed when unexpected stuff is
dragged into your .dll image often mention some "_unwindfunclet " symbol that
I know nothing about. This dragging in of unused code into images is
increasingly responsible for breaking our builds.

I implore someone from the Visual C team to investigate this. Reproducing it
is trivial. Start with a native hello world C++ program that arbitrarily
includes some not-really-referenced-or needed headers for some native types
that have inlined copy constructors and destructors that call out to other
..dlls whose import libraries you do not link with. Put #pragma managed at
the very top of the program and first make sure that it compiles just fine
as a pure native image and that it runs. Now, slap /CLR on the compile and
try again. Now you will get link errors and you will see that it tracks
back to the unused native types that have inlined copy constructors.

Bern McCarty
Bentley Systems, Inc.

[Bern McCarty]

Before anyone asks...

Where I said "Put #pragma managed at the very top of the program and first
make sure that it compiles just fine
as a pure native image and that it runs."

.....I meant to say "Put #pragma unmanaged...... "

-Bern
"Bern McCarty" <Be**@newsgroup s.nospamwrote in message
news:BE******** *************** ***********@mic rosoft.com...

>
We upgraded a bunch of MEC++ code to C++/CLI about 10 months ago and we've
noticed that our images bloated quite a lot in the process. Upon
investigating I observed that when a /clr compiland includes a header file
for a native type that has an inlined copy constructor, that both the
inlined copy constructor and the inlined destructor for that same type
will end up in my mixed image, even though there is no reference made to
that native type from the source code of my dll at all. This is true even
if the .h containing the native type is included in a #pragma unmanaged
section of my compiland.

This seems like a bad compiler bug to me. I should pay zero runtime
penalty for including type information for types that I do not reference
at all. Don't you agree? Otherwise I have to go to the almost impossible
difficulty of minimizing the native type information observed by my mixed
compiland. But that ain't the C++ I know. That is an intractable task.

This bug is particularly annoying when it forces you to link with an
import library for a dll that you shouldn't have to link with at all.
Suddenly your binding closure balloons for no justifiable reason. This
happens when you see a native type (that you do not use) with an inline
copy constructor and destructor that references something in some other
.dll (that you also do not use). This bug may have something to do with
exception handling/stack unwinding. The linker errors that can be
observed when unexpected stuff is dragged into your .dll image often
mention some "_unwindfunclet " symbol that I know nothing about. This
dragging in of unused code into images is increasingly responsible for
breaking our builds.

I implore someone from the Visual C team to investigate this. Reproducing
it is trivial. Start with a native hello world C++ program that
arbitrarily includes some not-really-referenced-or needed headers for some
native types that have inlined copy constructors and destructors that call
out to other .dlls whose import libraries you do not link with. Put
#pragma managed at the very top of the program and first make sure that it
compiles just fine as a pure native image and that it runs. Now, slap
/CLR on the compile and try again. Now you will get link errors and you
will see that it tracks back to the unused native types that have inlined
copy constructors.

Bern McCarty
Bentley Systems, Inc.