While there are a plethora of languages to choose from, the vast majority approach coding from one of two opposed philosophies: managed or native.
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.
At the highest 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.
The third road is in the middle between the two: 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).
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.
Managed code is superior to native code 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.
Attention is paid to the design and configuration.
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 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.
When to use each :
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#.
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.
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++.
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++.Ha Ha Ha...Enjoy reading.
Post a Comment