B
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.
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.