A Closer Look at Intermediate Language

From what we learned in the previous section, Microsoft intermediate language obviously plays a fundamental
role in the .NET Framework. As C# developers, we now understand that our C# code will be
compiled into IL before it is executed (indeed, the C# compiler only compiles to managed code). It makes
sense, then, that we should now take a closer look at the main characteristics of IL, since any language
that targets .NET would logically need to support the main characteristics of IL too.
Here are the important features of IL:
❑ Object-orientation and use of interfaces
❑ Strong distinction between value and reference types
❑ Strong data typing
❑ Error handling through the use of exceptions
❑ Use of attributes
Let’s now take a closer look at each of these characteristics.

Support for Object Orientation and Interfaces

The language independence of .NET does have some practical limitations. IL is inevitably going to implement
some particular programming methodology, which means that languages targeting it are going to
have to be compatible with that methodology. The particular route that Microsoft has chosen to follow for
IL is that of classic object-oriented programming, with single implementation inheritance of classes.
Those readers unfamiliar with the concepts of object orientation should refer to Appendix A for more
information. Appendix A is posted at www.wrox.com.
Besides classic object-oriented programming, IL also brings in the idea of interfaces, which saw their first
implementation under Windows with COM. .NET interfaces are not the same as COM interfaces; they do
not need to support any of the COM infrastructure (for example, they are not derived from IUnknown,
and they do not have associated GUIDs). However, they do share with COM interfaces the idea that they
provide a contract, and classes that implement a given interface must provide implementations of the
methods and properties specified by that interface.

Object orientation and language interoperability

We have now seen that working with .NET means compiling to IL, and that in turn means that you will
need to use traditional object-oriented methodologies. However, that alone is not sufficient to give us
language interoperability. After all, C++ and Java both use the same object-oriented paradigms, but they
are still not regarded as interoperable. We need to look a little more closely at the concept of language
To start with, we need to consider exactly what we mean by language interoperability. After all, COM
allowed components written in different languages to work together in the sense of calling each other’s
methods. What was inadequate about that? COM, by virtue of being a binary standard, did allow components
to instantiate other components and call methods or properties against them, without worrying
about the language the respective components were written in. In order to achieve this, however, each
object had to be instantiated through the COM runtime, and accessed through an interface. Depending on
the threading models of the relative components, there may have been large performance losses associated
with marshaling data between apartments or running components or both on different threads. In
the extreme case of components that are hosted as an executable rather than DLL files, separate processes
would need to be created in order to run them. The emphasis was very much that components could talk
to each other, but only via the COM runtime. In no way with COM did components written in different
languages directly communicate with each other, or instantiate instances of each other—it was always
done with COM as an intermediary. Not only that, but the COM architecture did not permit implementation
inheritance, which meant that it lost many of the advantages of object-oriented programming.

An associated problem was that, when debugging, you would still have to debug components written
in different languages independently. It was not possible to step between languages in the debugger.
So what we really mean by language interoperability is that classes written in one language should be
able to talk directly to classes written in another language. In particular:
❑ A class written in one language can inherit from a class written in another language.
❑ The class can contain an instance of another class, no matter what the languages of the two
classes are.
❑ An object can directly call methods against another object written in another language.
❑ Objects (or references to objects) can be passed around between methods.
❑ When calling methods between languages we can step between the method calls in the debugger,
even when this means stepping between source code written in different languages.
This is all quite an ambitious aim, but amazingly, .NET and IL have achieved it. In the case of stepping
between methods in the debugger, this facility is really offered by the Visual Studio .NET IDE rather
than by the CLR itself.

Distinct Value and Reference Types

As with any programming language, IL provides a number of predefined primitive data types. One
characteristic of IL, however, is that it makes a strong distinction between value and reference types.
Value types are those for which a variable directly stores its data, while reference types are those for which
a variable simply stores the address at which the corresponding data can be found.
In C++ terms, reference types can be considered to be similar to accessing a variable through a pointer,
while for Visual Basic, the best analogy for reference types are objects, which in Visual Basic 6 are always
accessed through references. IL also lays down specifications about data storage: instances of reference
types are always stored in an area of memory known as the managed heap, while value types are normally
stored on the stack (although if value types are declared as fields within reference types, then they will be
stored inline on the heap). We will discuss the stack and the heap and how they work in Chapter 3.

Strong Data Typing

One very important aspect of IL is that it is based on exceptionally strong data typing. What we mean by
that is that all variables are clearly marked as being of a particular, specific data type (there is no room in
IL, for example, for the Variant data type recognized by Visual Basic and scripting languages). In particular, IL does not normally permit any operations that result in ambiguous data types.
For instance, Visual Basic 6 developers are used to being able to pass variables around without worrying too much about their types, because Visual Basic 6 automatically performs type conversion. C++ developers are used to routinely casting pointers between different types. Being able to perform this kind of operation can be great for performance, but it breaks type safety. Hence, it is permitted only under certain circumstances in some of the languages that compile to managed code. Indeed, pointers (as opposed to references) are only permitted in marked blocks of code in C#, and not at all in Visual Basic (although they are allowed in managed C++). Using pointers in your code causes it to fail the memory type safety checks performed by the CLR.

You should note that some languages compatible with .NET, such as Visual Basic .NET, still allow some
laxity in typing, but that is only possible because the compilers behind the scenes ensure the type safety
is enforced in the emitted IL.
Although enforcing type safety might initially appear to hurt performance, in many cases the benefits
gained from the services provided by .NET that rely on type safety far outweigh this performance loss.
Such services include:
❑ Language interoperability
❑ Garbage collection
❑ Security
❑ Application domains
Let’s take a closer look at why strong data typing is particularly important for these features of .NET.

2007-07-14 19:49:00


Ultimele 25 posturi adăugate

01:18:55Să tacă..cuvintele.. —» Licurici de suflet
00:40:37Am presimtit disparitia lui Răzvan Ciobanu. Cu 1 luna si jumatate inaintea accidentului am avut o premonitie —» Eterica
21:54:18Suparata pe taxisti ca o discrimineaza „La scandal…cu BORODACHI”№ 26 —» Curaj.TV | Media alternativă
15:35:00(Фото) Как прошел Eco Moto Fest в Чимишлии —» Заметки Начинающего Журналиста
14:25:22somothèque —» turn up the silence
13:49:29Concediu —» Primul meu blog
10:58:36SPERANŢĂ BINECUVÂNTATĂ —» adevaruri biblice
10:39:09O atracție turistică excepțională – Pont Du Gard din Franța, cel mai înalt apeduct roman din lume —» Elena Robu
10:08:47Jurnal de tată: prima vizită la bunici —» Andrei Albu - omul alb cu gînduri negre
08:42:51Octavian Țîcu către Nelly Ciobanu și Doina Sulac care au cântat ieri la concertul lui Dodon: ”V-ați pozorît” —» Elena Robu
07:49:33Înger și demon —» Primul meu blog
06:41:23My Pillow Tv Offer —» Andrei Fornea
06:09:44Bathroom Shower Designs Without Doors —» Andrei Fornea
05:36:20DIN POEZIA BURIAȚILOR —» Leo Butnaru
04:00:00100 de ilustrații pentru predici (II) —» O parte din Mine
03:26:35Am presimtit disparitia lui Răzvan Ciobanu. Cu 1 luna si jumatate inaintea accidentului am avut o premonitie —» Eterica
01:19:54Am presimtit disparitia lui Răzvan Ciobanu. Cu 1 luna si jumatate inaintea accidentului am avut o premonitie —» Eterica
19:21:56Alee de pini ameninţată de gherete şi trotuare —» Curaj.TV | Media alternativă
19:11:27Înger și demon —» Primul meu blog
17:50:10Prima zi de școala, anul de studii 2019 – 2020 —» Liceul Teoretic “Mihail Sadoveanu”, Călăraşi
17:47:13A semnat pentru Brega şi pleacă la Ierusalim pe jos —» Curaj.TV | Media alternativă
17:06:41Spaghetti with Shrimp, Olive Oil, Garlic & Wine —» ajna-blogging-press
16:11:16Călărășenii doresc bugetare participativă! —» Centrul Comunitar Instruire, Acces Informaţie Călăraşi
14:10:36Documentar: Samizdat în numele credinţei —» O parte din Mine
13:51:02Octavian Țîcu îndeamnă cetățenii să boicoteze așa-zisa „eliberare” —» Elena Robu