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

20:20:22Transmisiunea în direct a meciului dintre Radu Albot și Roger Federer —» un alt blog
16:00:50BREXIT: Petiţia pentru ca Marea Britanie să rămână în UE depăşeşte patru milioane de semnături —» Elena Robu
14:16:12Pornesc pe jos spre Laponia să-l certe pe Moșul —» Curaj.TV | Media alternativă
13:36:4512 strategii de sporire a încrederii angajaților în echipa de conducere —» Divers Media
12:29:00Sânge de sclav. Despre Moldova - Franța 1-4 —» Sandu GRECU
12:01:49De aproape 3 ani nu și-a văzut nepoții —» Curaj.TV | Media alternativă
10:10:42Franța: Mii de soldaţi, mobilizaţi împotriva „vestelor galbene”. În ce condiţii au voie să tragă —» Elena Robu
09:46:39Moldindconbank anunță lucrări de mentenanță pentru 24 martie —» edufin.md
07:49:07Виноградная ярмарка "Ia Moldova acasă" пройдет уже завтра! —» Заметки Начинающего Журналиста
07:39:34Открыта регистрация для участия в акции "Good Deeds Day - День Добрых Дел" —» Заметки Начинающего Журналиста
06:16:09Eroul de 13 ani care a alertat autorităţile în cazul autobuzului şcolar incendiat în Italia va primi o recompensă deosebită —» Elena Robu
05:56:17Me again —» Primul meu blog
20:12:55Александр Густав Эйфель - Инженер-строитель, создателя всемирно известной башни в Париже —» Удивительные истории из жизни великих людей
18:45:25Coral: The animal that acts like a plant, but is an active predator, and makes its own rocks for a house —» ajna-blogging-press
17:47:30«Sapiens. Краткая история человечества» Юваль Ной Харари —» Блог Ирэн – Рецензии книг
17:33:06Pogromul de la Chișinău. Din 2019 —» Gheorghe Erizanu
16:52:10Moses’ last message —» Erik and Elena Brewer's Weblog
15:35:05Voi sunteți sarea pământului | Pastor Vasile Filat —» Moldova Creștină
15:33:46Porți mortale căzătoare în parc la Aiud —» Curaj.TV | Media alternativă
15:06:12Ajutati si faceti un bine aproapelui vostru #Telefonati parintii —» Curaj.TV | Media alternativă
12:43:35Cel mai așteptat meci de fotbal: Franța și Moldova se întâlnesc astăzi pentru prima dată pe stadionul Zimbru din Chișinău. Ce scrie presa franceză —» Elena Robu
12:32:54Xiaomi Redmi Note 7 – Noul Rege de buget (review) —» ITMOLDOVA
12:00:42Арт-проект. 1.5 художника —» Art and fashion design
11:07:25ZAȚ* —» Andrei LANGA. Blogul personal
09:49:59Cu gingășie și luciditate, Eleonora Lisnic ne îndeamnă să nu privim în urmă —» Eleonora Lisnic în versuri