Performance of pure native C++ class in a managed C++/CLI DLL comp

[Guest]

I have a class that is writen in unmanaged pure native C++.
This class files (h and cpp) are inserted to a managed C++ (VC++ 2005,
C++/CLI) DLL compoenet.
This DLL compoenet is used in a C# application.

My question is:
Does the performance of the unmanaged pure native C++ class described above
is the same if it was a in a pure unmanaged native C++ DLL component?

 

[Bruno van Dooren [MVP - VC++]]

My question is:

Does the performance of the unmanaged pure native C++ class described
above
is the same if it was a in a pure unmanaged native C++ DLL component?

Yes. The performance of that native class will be the same as if it was in a
native app.
The only thing you have to keep in mind is that every time there is a
native - managed transition, the data is marshalled so if you have lots of
transitions per second, performance will suffer.

 

[Carl Daniel [VC++ MVP]]

Yes. The performance of that native class will be the same as if it
was in a native app.

.... that is assuming, of course, that the .cpp file in question is still
compiled as native code! Just dropping the .cpp and .h into a managed C++
project will most likely result in the code being compiled as managed
(managed code, unmanaged data). In order to ensure that the class is still
unmanaged, it's necessary to bracket #includes of the .h file with something
along the lines of...

#pragma managed(push,off)
#include "myNativeClass.h"
#pragma managed(pop)

This must be done in every managed compiland that #includes this header (or
do it in the header itself, if you don't mind modifying it, or make another
wrapper-header to do it - you get the idea).

Also check the project settings to make sure that the .cpp file containing
the natice class implementation is NOT compiled with /CLR.

The only thing you have to keep in mind is that every time there is a
native - managed transition, the data is marshalled so if you have
lots of transitions per second, performance will suffer.

Yep, that too!

-cd

 

[Guest]

The DLL component is CLI supported and there is some code in this component
that uses the .NET syntax and Frameworks.
So what setting should I do in the project setting for some of my
classes/files to be complied as an unmanaged pure native C++?

Ok, in every file that uses the myNativeClass.h, I will do it like that:

#pragma managed(push,off)
#include "myNativeClass.h"
#pragma managed(pop)

But what about another unmanaged pure native C++ class that is used by the
first unmanaged pure native C++ class?
Do I need also to add the #pragma managed(push,off) and #pragma managed(pop)
in the unmanaged pure native C++ that uses another unmanaged pure native C++
files?

Maybe it's better to simply put all the unmanaged pure native C++
classes/files in a separate unmanaged pure native DLL component, and use the
DLL in another managed C++/CLI DLL component?

What is the safest way to do it? Or event better; what is the deployment
that will make the unmanaged pure native C++ code run the fastest?

 

[Carl Daniel [VC++ MVP]]

The DLL component is CLI supported and there is some code in this
component that uses the .NET syntax and Frameworks.
So what setting should I do in the project setting for some of my
classes/files to be complied as an unmanaged pure native C++?

You can set /CLR on or off in each .cpp file individually. Turn it on for
the whole project,. as you have done, then turn it off for the files
containing only native (unmanaged) code. When you have the VC++ procject
properties dialog open, you can still click on files/projects in the
solution explorer to change the scope that you're working on. Click on the
unmanaged .cpp file to set options for just that file.

Ok, in every file that uses the myNativeClass.h, I will do it like
that:

#pragma managed(push,off)
#include "myNativeClass.h"
#pragma managed(pop)

But what about another unmanaged pure native C++ class that is used
by the first unmanaged pure native C++ class?

Doesn't matter. That's why it's good practice to use the push/pop features
of #pragma managed (and a number of other compiler pragmas, for that
matter). It's safe to wrap everywhere, and the contents of the header file
will always be interpreted as unmanged. For portability/reuse reasons, you
might not want to do the wrapping when the #include is in an unmanged file,
but it does not harm to do so.

Do I need also to add the #pragma managed(push,off) and #pragma
managed(pop) in the unmanaged pure native C++ that uses another
unmanaged pure native C++ files?

Maybe it's better to simply put all the unmanaged pure native C++
classes/files in a separate unmanaged pure native DLL component, and
use the DLL in another managed C++/CLI DLL component?

That is a common solution. If you have a lot of native code to integrate,
it may well be the better solution. Design a pure C or COM interface to the
native code, and then use that component from your managed code.

What is the safest way to do it? Or event better; what is the
deployment that will make the unmanaged pure native C++ code run the
fastest?

Done correctly, either approach will be just as safe and just as performant.
If anything, the performance factors probably lean slightly towards the
mixed-mode DLL, since the compiler-interop can work at the C++ level and you
don't have to force your API into C or COM.

-cd

 

[Ben Voigt [C++ MVP]]

That is a common solution. If you have a lot of native code to integrate,
it may well be the better solution. Design a pure C or COM interface to
the native code, and then use that component from your managed code.

Done correctly, either approach will be just as safe and just as
performant. If anything, the performance factors probably lean slightly
towards the mixed-mode DLL, since the compiler-interop can work at the C++
level and you don't have to force your API into C or COM.

It's probably preferable to make the native code a static library instead of
a DLL. Then you get the benefits of a separate build environment and the
benefits of mixed-mode.