Programming Languages: Managed versus Native

If you’re ready to learn how to code, you have a tough choice ahead of you: which programming language to learn first. While there are a plethora of languages to choose from, the vast majority approach coding from one of two opposed philosophies: managed or native. This article will help you decide between the two.

I frequent a number of forums, and periodically someone always brings up the question of whether C# or C++ is the better language to use when learning how to program. This illustrates the battle of native coding, represented by C++, and managed coding, used by the Microsoft-made C#. I will not observe the question from the point view of what differences are between the two and which can be learned with less headaches.

Rather than fall into that trap, we will explore the war between native and managed coding, examining it first from the side of the market, and later consider the advantages you gain while coding. 

Finally, we will sum it up in a stylish manner by giving to you some advice that will point out when to use one or the other approach. Remember that this is just for the purpose of guidance, and may be subject to change based on the details of your own project. 

Coding languages are divided into two or three different groups depending on the level of their complexity. "Level of complexity" in this case indicates how abstract they are, and at which level they communicate with the hardware.

First there are the low-level programming languages. These have only a minimal level of abstraction, and no concept of Object Oriented Programming (OOP). They interact directly with almost every level of hardware you possess. Assembly belongs at this level, as does any native code that does not require a compiler or interpreter to run. 

On the other side of the coin, you will find high-level coding. Anything in this category features a very high level of abstraction. OOP is at home here, and you are completely separated from the hardware. Instead, you receive at your disposal a multitude of functions, and each one internally handles hardware-related tasks.

Furthermore, at this level you will not find anything like pointers; nor will you work with the memory directly. You just create the objects and let the Garbage Collector take care of this task. Languages that work like this include C#, Java, Python and Perl. They are called managed codes.

Of course, these distinctions are made purely on the level of theory. In everyday usage, some languages can move slightly towards one or the other direction. The third road is in the middle between the two; not surprisingly, it is called middle-level coding. This is the most low-level high-level coding, to be more exact; here we are talking about the C/C++ group. Although this group has a minimal idea of management, it is still strongly native code, with everything that implies (i.e. leaving many tasks to the user).

The languages of middle-level coding know about OOP, and maintain a good level of readability and direct memory handling with the help of the pointers. In return, though, middle-level coding loses a lot of direct hardware access. There are languages that are between even these languages, so think of these terms as a representation of the general concept, not a rule and point of reference.

{mospagebreak title=The Marketing}

It is no secret that in the last decade, ever since the .Net platform appeared, Microsoft has been trying to push its product. Every single day you will find more articles cropping up about how to work with it. From every corner, you hear that this is what you want to use.

Many native coders have found this to be a good reason to worry. Tom Archer, handling Contest Strategies over at MSDN, tried to answer this question from his own point of view. You are probably aware that Microsoft gets the most out of its Windows operating system and the Office suite. Not surprisingly, Microsoft’s main purpose is to spread the operating system and the suite even further. Before any operating system can become popular, it needs to have many task-specific applications so the vast majority can use the OS in the ways they want to. This lets the OS extend to fit other people’s desires.

Developing an application from scratch to something close to perfection takes time and effort from an entire developing team. This is not healthy or beneficial for a new OS that wants to spread, as many companies will refuse to pay this price.

The solution is to develop, along with your OS, a language that also integrates well into the operating system and makes it possible to develop complex applications with just a few people in a short period of time. The .Net framework with its C# way of programming was made for this sole purpose.

Surely Microsoft already took advantage of this approach with the Microsoft Foundation Class Library inside C++. As mentioned on the previous page, this is still considered native code, and leaves many agonizing tasks to the user. Microsoft wants to remove that burden.

All of this sounds good in theory, but there is of course a difference between what was intended and what actually came out, which will be covered on the following page. Regardless, to popularize the OS and with it the Office suite, Microsoft decided to make the technology freely available.

The reason that you see more whte papers and articles about C# and the .Net framework on the Microsoft Developers Network (and in general) is because Microsoft tries to promote the new technologies that will make it easier to develop applications for Windows.

In addition, the fact that C/C++ has now been around for 20 years, and C# less than a decade, means that there are more aspects of C# that have not been covered, while the subject of C/C++ has already been explored from every point of view. Until a significant amount of new introductions are made to the languages, it will be hard to produce as much content about C/C++ as is being produced about a completely new and constantly changing language like C#.

In fact, you can observe this in the numbers representing the visitor count to the specific parts of MSDN. The Visual Studio, .Net, VB.Net, and Vista sections receive the most visitors, representing the strongest interest of the public towards the new technologies; in other places, they cannot find reliable information.

These are indicators of an interest in managed coding through the .Net platform, and point out the relatively small amount of information about them. In addition, it is a fact that people will search for what they cannot comprehend or information to help them when they are stuck. Therefore, we have a product that is excessively promoted; nevertheless, the question remains: in theory, everything sounds good, but has Microsoft had success in the execution of this project?

{mospagebreak title=The Fight}

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++.

{mospagebreak title=The Decision} 

As we’ve arrived at the final page, it is safe to say that you now know enough about managed and native code for you to make your own decision; however, let me sum up and present some advice at to when to use each.

Now that we know the advantages of each one, we can safely state that C# was built for speed of development and minimizing the amount of bugs that can occur. C++, on the other hand, gives you control over the hardware but makes you responsible for doing that efficiently; also, it is up to you to write as bug-free as you can. If you pull all of this off gracefully, you will be rewarded with extra speed and greater control over what is happening behind the scenes.

In general, it is a good idea to use managed code for business applications, as these require stability, efficiency, and security with a short development time, unless you already have a big company that can support that financially.

Managed code should also be used for web sites, unless you write one with a real time system at its center, like a consistently updated sales site. You can choose ASP.Net or Java as managed codes, or even interpreted ones like PHP and PERL.

When you’re creating real time, mission-critical applications, the perfect solution looks to be native code. This is the case for operating systems, RDBMS engines, kernels, drivers, games, real time simulations, and so forth. If you generally write applications that require speed, you want to stick with these. This would be true of applications that play music, edit videos, or process photos. 

The portability issue can also be a major deciding factor. If you use the application only on devices that have the .Net Framework already installed, you may want to reduce the development time and stick with C#.

History is repeating itself. This war was already fought on a different level, between Assembly code and C. As those results showed, there is no such thing as an absolute winner, as each one has its place, and both of them can co-exist. You still need C++ to write managed code, as we should not forget that C# eventually is created inside C++. As I said before, everything has its place and time, so you just need to figure out what you want and what is more appropriate for you!

With the belief that you have accumulated all the knowledge you need to make your decision, I’m going to end this article, but not before I point out that you can post your thoughts related to it here on the blog or join our forum over on DevHarware and act accordingly there. “Live with Passion!”

[gp-comments width="770" linklove="off" ]