51194 cazuri COVID-19 în Moldova
11676 – cazuri active
38217 – cazuri vindecate
1301 – cazuri fatale
Actualizarea datelor: 29 septembrie 2020 ora 00:23

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

21:20:11Tensiuni și intrigi în consiliul local Burlacu —» Curaj.TV | Media alternativă
21:01:55Jurnal de tată: dialoguri de vară despre înghețată, piscină și șuturi —» Andrei Albu - omul alb cu gînduri negre
21:01:08The Transfiguration —» Erik and Elena Brewer's Weblog
17:52:51Fizicianul care răspunde la întrebări —» Curaj.TV | Media alternativă
16:45:30©️ (Ne)împliniri —» Licurici de suflet
12:14:00Mocănița, un tren celebru, dar care-ți dă fiori —» Curaj.TV | Media alternativă
11:16:36Fac politică artiștii?! —» Elena Robu
10:45:18RAPIRE in Germania – Miliardarul Richard OETKER —» Curaj.TV | Media alternativă
08:51:35ПЦР-анализ —» Бессарабские хроники
20:42:391 an și 10 luni: Ilinca a intrat în etapa „nu, nu, nu” —» Andrei Albu - omul alb cu gînduri negre
19:40:49Opozantul rus Aleksei Navalnîi prezintă urme de otrăvire. Poziția Moscovei —» Elena Robu
19:00:02Jandarmii aplică amenzi pentru bere la poarta bisericii —» Curaj.TV | Media alternativă
18:12:45Nimeni nu poartă mască în parcul aglomerat din Drumul Taberei —» Curaj.TV | Media alternativă
14:14:22Mai simplă rețetă de înghețată nu există, doar din 3 ingrediente —» Life is too short to wear boring clothes. - A blog about travel, lifestyle, healthy life and fashio
12:22:32Seceta din R. Moldova: Cea mai modestă recoltă de struguri din ultimii 10 ani —» Elena Robu
09:31:57Cel mai mare dușman al lui Lukashenco este… telefonul mobil —» Cojocari Vitalie
09:29:22Discursul ultimului “dictator din Europa”! —» Cojocari Vitalie
09:06:08COVID-19: Alertă de călătorie în Israel —» Elena Robu
08:32:09Наши услуги. Замеры мощности на нашем Диностенде —» Сажевые фильтры (DPF/ FAP). Чип тюнинг. Теория, практика.
07:55:00Probleme de acces pe strada Konev, din Bălți —» Curaj.TV | Media alternativă
07:26:00Roagă primarul și președintele să-l ajute cu proteza dentară —» Curaj.TV | Media alternativă
06:40:08DOI POEȚI AI AVANGARDEI: Gheorghi CIULKOV și Serghei GORODEȚKI —» Leo Butnaru
04:38:32Îngeri* —» Andrei LANGA. Blogul personal
04:37:54Respirație* —» Andrei LANGA. Blogul personal