 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / June 2007Performance of pure native C++ class in a managed C++/CLI DLL comp
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?  SignatureThanks Sharon > 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. SignatureKind regards, Bruno van Dooren MVP - VC++ http://msmvps.com/blogs/vanDooren >> My question is: >> Does the performance of the unmanaged pure native C++ class described [quoted text clipped - 3 lines] > 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 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? ----- Thanks Sharon > 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: [quoted text clipped - 5 lines] > 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 [quoted text clipped - 3 lines] > 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 >> Maybe it's better to simply put all the unmanaged pure native C++ >> classes/files in a separate unmanaged pure native DLL component, and [quoted text clipped - 12 lines] > 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. > -cd Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.