Unmanaged C functions and C++ classes wrapped in an assembly not as public but as managed private methods: how???

Bob Rock

Hello,

in the last few days I've made my first few attempts at creating mixed C++
managed-unmanaged assemblies and looking aftwerwards with ILDASM at what is
visible in those assemblies from a managed point-of-view I've noticed that:

1) for each managed and unmanaged C function (not C++ classes) I get a
public managed static method (defined on a 'Global Functions' class) in the
generated assembly with an export name of the form xyz.FunctionName, where
xyz looks like a C++ mangled random name. As global methods of this 'Global
Functions' class also appear the main and _mainCRTStartup functions and any
other C library function that gets used inside the defined managed or
unmanaged C functions. In my simple sample applications, for example, I'm
using the printf C standard library function inside my definined functions
and when looking at the generated assembly with ILDASM I find a public
managed static method with the same name.

2) for each unmanaged C++ class I get a public managed structure (value
class) with no managed method visible. Including any C++ standard library
(such as iostrem, string, ecc.) in a project also adds a lot of managed
objects in the form of public managed structures (value classes). And this
happens even if none of the included C++ standard library classes gets used
in the defined managed/unmanaged C++ classes.

All of the above happens when compiling assemblies in release mode and
having specified to have the compiler produce NO debugging information.
Incredibly I discovered that even for release compiled assemblies some
debugging information still is produced and inserted into the assembly. Look
under "Project Properties -> C/C++ -> General" and set Debug Information
Format to Disabled to stop debug info from being placed into your
assemblies.

Now, what I'd like to do is:
(1) hide, if possible, any managed objects (value classes, arrays and
fields) created around my unmanaged C functions and C++ classes, but most of
all
(2) I'd like to have all these managed structures (value classes) created
around my managed/unmanaged C functions and unmanaged C++ classes to be
PRIVATE and NOT PUBLIC as their are created now.

I've tried defining as static both the managed and unmanaged C functions but
this does not seem to change anything. As for the C++ unmanaged classes it
seems that access specifiers (public, private, protected) may only be
applied to managed classes and so on this front I have not been able to do
anything.

Can anyone help me out???
Thx.
Bob Rock

Nov 17 '05 #1

Ronald Laeremans [MSFT]

Note: I set follow-ups to m.p.d.languages.vc.

(2) I'd like to have all these managed structures (value classes) created
around my managed/unmanaged C functions and unmanaged C++ classes to be
PRIVATE and NOT PUBLIC as their are created now.
Compile with /d1PrivateNativeTypes for the value classes created mapping the
native types.

There is no alternative for the global functions since they are really
needed. Also no current tool (including ILASM) can call global functions )in
the CLR sense) exported from an assembly.
(1) hide, if possible, any managed objects (value classes, arrays and
fields) created around my unmanaged C functions and C++ classes, but most
of
all
If by "hide" you mean "not generate"then that isn't possible since these are
needed for the code to run. If you mean something else besides emitting them
as private, could you clarify?

Thanks.

Ronald Laeremans
Visual C++ team

"Bob Rock" <no***************************@hotmail.com> wrote in message
news:uU*************@tk2msftngp13.phx.gbl... Hello,

in the last few days I've made my first few attempts at creating mixed C++
managed-unmanaged assemblies and looking aftwerwards with ILDASM at what
is
visible in those assemblies from a managed point-of-view I've noticed
that:

1) for each managed and unmanaged C function (not C++ classes) I get a
public managed static method (defined on a 'Global Functions' class) in
the
generated assembly with an export name of the form xyz.FunctionName, where
xyz looks like a C++ mangled random name. As global methods of this
'Global
Functions' class also appear the main and _mainCRTStartup functions and
any
other C library function that gets used inside the defined managed or
unmanaged C functions. In my simple sample applications, for example, I'm
using the printf C standard library function inside my definined functions
and when looking at the generated assembly with ILDASM I find a public
managed static method with the same name.

2) for each unmanaged C++ class I get a public managed structure (value
class) with no managed method visible. Including any C++ standard library
(such as iostrem, string, ecc.) in a project also adds a lot of managed
objects in the form of public managed structures (value classes). And this
happens even if none of the included C++ standard library classes gets
used
in the defined managed/unmanaged C++ classes.

All of the above happens when compiling assemblies in release mode and
having specified to have the compiler produce NO debugging information.
Incredibly I discovered that even for release compiled assemblies some
debugging information still is produced and inserted into the assembly.
Look
under "Project Properties -> C/C++ -> General" and set Debug Information
Format to Disabled to stop debug info from being placed into your
assemblies.

Now, what I'd like to do is:
(1) hide, if possible, any managed objects (value classes, arrays and
fields) created around my unmanaged C functions and C++ classes, but most
of
all
(2) I'd like to have all these managed structures (value classes) created
around my managed/unmanaged C functions and unmanaged C++ classes to be
PRIVATE and NOT PUBLIC as their are created now.

I've tried defining as static both the managed and unmanaged C functions
but
this does not seem to change anything. As for the C++ unmanaged classes it
seems that access specifiers (public, private, protected) may only be
applied to managed classes and so on this front I have not been able to do
anything.

Can anyone help me out???
Thx.
Bob Rock

Nov 17 '05 #2

Bob Rock

> Compile with /d1PrivateNativeTypes for the value classes created mapping
the

native types.

If by "hide" you mean "not generate"then that isn't possible since these are needed for the code to run. If you mean something else besides emitting them as private, could you clarify?

Ronald Laeremans
Visual C++ team

Ronald,

I tried compiling with the /d1PrivateNativeTypes. It compiles fine, and it
makes private the value classes created for the unmanaged classes,
unfortunately it does NOT make private the managed methods created around
the C functions (either managed or unmanaged). Is there any way to make them
private???
BTW, the /d1 option does not appear anywhere printing out all the modifiers
supported by the cl compiler.

Also, while for C standard library functions only the ones used produce a
corresponding managed wrapper in the assembly, for C++ stardard functions
the only inclusion (without using any of the exported classes) make an awful
lot of value classes appear in the assembly. Is there any way to prevent
this from happening???
Regards,
Bob Rock

Nov 17 '05 #3

Ronald Laeremans [MSFT]

Hi Bob,

I tried compiling with the /d1PrivateNativeTypes. It compiles fine, and it
makes private the value classes created for the unmanaged classes,
unfortunately it does NOT make private the managed methods created around
the C functions (either managed or unmanaged). Is there any way to make
them
private???
No, that is what I tried to describe by the following paragraph in my
original reply:

There is no alternative for the global functions since they are really
needed. Also no current tool (including ILASM) can call global functions )in
the CLR sense) exported from an assembly.
<<
BTW, the /d1 option does not appear anywhere printing out all the
modifiers
supported by the cl compiler.
Yes, the following link is the only available documentation:
http://support.microsoft.com/default...b;en-us;822330

Also, while for C standard library functions only the ones used produce a
corresponding managed wrapper in the assembly, for C++ stardard functions
the only inclusion (without using any of the exported classes) make an
awful
lot of value classes appear in the assembly. Is there any way to prevent
this from happening???

No there is not one that I know of. There should be no ill effects though.
Do you have a specific concern?

Ronald

Nov 17 '05 #4