managed/unmanaged code - can I efficiently run both in the same ap

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

A couple of questions re. managed vs. unmanaged code.
1. I know this depends on the app, but how much faster is unmanaged code
vs. managed code? Is there an average figure for this?
2. Is it as simple as using a #pragma to convert from unmanaged to managed?
And if so, can I simply change my existing code to managed with the #pragma
wherever I want to eliminate transitions, or are there issues with this?
 
A couple of questions re. managed vs. unmanaged code.
1. I know this depends on the app, but how much faster is unmanaged code
vs. managed code? Is there an average figure for this?
The code I use has about 5% difference in speed.
It appears that managed code (C#) compiles similar like if you would have a
none-optimized compile of the C++ code.

The things is to avoid calles between managed/unmanaged too much since you
lose transition speed.
Basically I discoverd that in som parts of your code it will runn slower
while other parts will run faster.
I can only advice you to test your specific type of code.
2. Is it as simple as using a #pragma to convert from unmanaged to managed?
And if so, can I simply change my existing code to managed with the #pragma
wherever I want to eliminate transitions, or are there issues with this?
Not exactly.

For the none-MFC code:
But porting from unmanaged C++ to managed C++/C# is very easy, just copy and
paste, then search and replace and remove all deletes and in 90% of the time
it just runs without need of change.

For the MFC code (like windows dialog boxes, Sendmessage()...) this is going
to be a rewrite.
But luckily, Winforms is so user friendly compared to MFC that recreatign
the forms from scracht wil be really fun.

Only one thing I have to warn you. The .NET way has a different philosophy
than the MFC way, so you might have a hard time to change your programming
style. You will probably stumble om some stupid stuff like converting from
string to int and back. It is done different in the .NET way, but in my
opinion very logical. Once you know it. ;-) Also the security model is
integrated into the managed code. For example a default managd program has
default no access to a LAN drive. As a programmer you mist activate this
part, and also the user that installs that program must give right s for
that program to access the LAN drive. Luckily this can be easily configured
if your installer program, so the user does not need to be an expert in
administration. This took me a few months to find the good way of doing, but
it works fine.
 
Managed code may only be a bit slower when running in Release mode, buts its
much much much slower to link and debug.
If you are converting a large c++ project to managed c++ its almost
unusable, unless youv'e got a ****-hot PC.
It does a full link every time (see
http://www.dotnet247.com/247reference/msgs/36/183691.aspx)
and debugging is unbelieveably slow.
They've said they "may" be sorting some of these problems out in Visual
Studio 2005.
 
Managed code may only be a bit slower when running in Release mode, buts
its
much much much slower to link and debug.
If you are converting a large c++ project to managed c++ its almost
unusable, unless youv'e got a ****-hot PC.
I don't know about the C++, but in C# it is lightning fast.
What I tend to do is to use C# for pure managed functions since I can
program much faster, no slow compile and link time, much better compile
error reports, and no link errors, and it is fully compatible with managed
C++. And The parts that needs managed/unmanage C++ is done in C++.

And C++ and C# are very close on the syntax level. converting C# to C++ and
back is very easy to do.
 
Back
Top