Programming Languages: Managed versus Native - The Fight
(Page 3 of 4 )
Here we confront the two manners of coding, and try to observe which one of them has the advantage and where it still needs to improve. For starters, let me tell you that while C++ code is compiled (though the linker will create an exe that you can start up anywhere in the future), C# code is interpreted.
This was done because you only get to know system-specific data at run-time. By knowing what you are running the application on, it can be compiled especially for that machine, and optimizations can be made from which the application will benefit.
Therefore, when you write the application, usually it has created a MSIL file that will be interpreted later on by the framework. This sounds good in theory, but in practice, additional time is required so that the CLR virtual machine can start up (unless somebody has already done that). In addition, the optimization offered sometimes just does not make up for the time wasted to start up the framework.
Also, I should enumerate the performance penalties that this kind of application can have by using extra memory. More and more, when programmers make a performance comparison, they just write a loop and run the tests. This is wrong; by doing this, you bypass another important disadvantage of C#.
Consider the costs of managed code. This code is achieved by creating additional classes/objects (“cheap objects”) that operate behind the scenes and offer security, garbage collection and other improvements. The presence of this additional object, however, will take up additional memory segments, and their creation takes time, further slowing down an application and increasing its memory usage. You have to pay the price for everything somewhere.
Look over here and here so you can get an idea of the consequences I am talking about. Surely, you get rid of the annoying memory management and pointers that you had to use inside the rival C++ code, where the MFC library offers a reasonable improvement over the old-style Win32 coding procedure.
On the other hand, where managed code is superior to native code is in the development time for a stable application. This takes up less time and generates a more secure application. Vendors can no longer wait years to develop a program; it needs to be done now, in the shortest period of time.
C# will increase the efficiency of your company, and with it, provide the productivity that will result in extra cash. C# tries to move your attention to the design and configuration, rather than forcing you to waste time with typing native code, debugging for overflowed stacks, and so on. Moreover, most of the time the problem is not with the language chosen , but rather with the algorithm you use to accomplish your task.
The portability issue is a little more complicated. C# follows the tongue-in-cheek phrase "code once, debug everywhere" by promising to run on any machine where a virtual CLR machine can be started. This offers a double-edged portability, as many devices developed by Microsoft have this issue. That is also the situation with the Linux OS.
C++ offers portability, but for every operating system you need to do a recompile of the application with new libraries and spread the program differently for different operating systems and devices. You need to be aware, inside C++, of the divergences in the allocation/de-allocation of the objects between libraries, which at times use multiples of an object. Inside managed code, AL will pass these in a reasonable way so you do not have to worry about them. The price paid is that additional objects are created.
But it isn’t all that dark for the C++ side, as device drivers can be written only at this low level, because you need to directly access the hardware. Also, it is much easier to debug a project of this type, as you get to see what happens; it isn't just done by some libraries where you can’t examine what's going on.
In addition, managed code is not suitable for every single situation. Medical devices are one of the prime examples. You need to access all of the data now; you cannot allow any time lags. Besides, you want to work with the hardware directly.
Do you need ultimate control over performance inside critical applications? You had better think so. C++/CLI in the end will let you to work with managed code and use the native code where you need it. Just like you can skip to the Assembly language when you want to have absolute control in C/C++, in the same manner you may integrate the C++ code inside C# where it is required.
To anyone who says C++ is an awkward way to code, let me point out that it also offers great reusability if you stick with cross platform libraries likes the STL and Boost. Many applications still build on C#, as the managed world simply gives too many performance penalties.
For instance, Adobe tried to move over to managed code with its Photoshop, but as inside it has many, many objects, it turned out to be a bad decision and the company abandoned that path. It's also worth mentioning that 3dmx, Office and Windows are written in something very close to C++.
Next: The Decision >>
More C# Articles
More By Gabor Bernat
/ 4 
