Home > Articles > Programming > C#

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book


C# is a CLR-compliant language. We’ll find out what that really means in the next chapter, but for now you need to know that applications that you write in C# use a different method of translating source code to object code called JUST-IN-TIME COMPILATION (“JIT” is pronounced like “bit”, and sometimes it’s used as a verb, as in, “Code in the CLR is jitted”.)

Pros & Cons


It’s important to understand some of the trade-offs in using JIT compilation, so let’s look at some of those pros and cons in a little more details...

The CLR Is Platform-Agnostic

Microsoft’s version of the CLR runs on various versions of Windows operating systems, including embedded and micro systems. The CLR has also been ported to run on Linux, Mac OS X, BSD and Sun Solaris, among other platforms. (For details, check out www.mono-project.com.) The C# language and parts of the CLR have been accepted as ECMA standards.

Application Components can be Written in Multiple Languages

Because all CLR-compliant languages are compiled to the same intermediate language, an application can use components written in any combination of languages. For the first time, you can use those fast statistical routines written in C++ and the widget your buddy wrote in Visual Basic in your C# code. The CLR goes a long way toward achieving Microsoft’s goal of making language “a lifestyle choice”.

Runtime Compilation can be Slower

The industry rule-of-thumb is that interpreted languages run 30 to 70 times slower than compiled languages. Although Microsoft provides a tool, NGen.exe (for “native generator”) that will perform the final compilation at design-time, tests have indicated that applications compiled to native object code don’t actually run much faster, and, surprisingly, in some instances are actually slower. It appears that the CLR is really smart about adapting code to the runtime environment.

CLR-Compliance Constrains Languages

Some people have complained that since all CLR-compliant languages are compiled to MSIL, none of them can do anything that MSIL can’t do, a kind of “lowest common denominator” programming. In reality, there isn’t much the computer can do that MSIL can’t do, and you always have the option of writing non-compliant code with C#, C++, or some other language, and calling “unsafe” procedures from within a CLR-hosted application.

  • + Share This
  • 🔖 Save To Your Account