231 cazuri COVID-19 în Moldova
227 – cazuri active
2 – cazuri vindecate
2 – cazuri fatale
Actualizarea datelor: 29 martie 2020 ora 14:41


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
interoperability.
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.

Sursa
2007-07-14 19:49:00



Comenteaza





Ultimele 25 posturi adăugate

07:23:19Decorator Pattern —» Un nene Project
21:18:38Secundanţii coronavirusului —» Un PUNCT din .FR
20:40:24Despre Ora planetei #palavre —» Curaj.TV | Media alternativă
20:33:00Prima persoană dintr-o familie regală care moare din cauza coronavirusului —» Elena Robu
19:55:29Curăţirea sfântul locaş —» adevaruri biblice
19:12:01Cruce* —» Andrei LANGA. Blogul personal
19:03:12Joker —» APort | "Pentru un român care știe citi, cel mai greu lucru e să nu scrie." I.L. Carag
18:42:00Doua femei se pling ca au fost agresate de Sefa Centrului de Familie Parcani, Soroca —» Curaj.TV | Media alternativă
17:51:20Observer Pattern —» Un nene Project
17:03:33Remember ION GUŢU (12 04.1963 – 26.03. 1999) —» Biblioteca de Arte 'Tudor Arghezi'
13:20:33COVID-19 —» … mai mult emoţii, decît cuvinte.
11:41:12POESIA... (POEZIA*)... de Hector Berenguer —» Andrei LANGA. Blogul personal
11:34:17Ce activități să faci cu copiii în timpul Orei Pământului —» Sunt MAMĂ!
11:18:25O activista civica este ingrijorata de Împărtăşania pe la case si de alimentatia la spital —» Curaj.TV | Media alternativă
10:28:39Cruce* —» Andrei LANGA. Blogul personal
09:26:50Sfântul Ioan Scărarul, despre bârfirea „din dragoste” —» Portalul Tineretului Ortodox din Moldova
08:49:58Mama: Eu —» Viata pe Tinder – Viata amoroasa pe Tinder
08:45:20Coronavirusul a explodat în SUA, unde numărul de pacienți infectați a depășit 100.000 —» Elena Robu
01:57:14LA découverte —» turn up the silence
21:02:44Spune ca la Mănăstire nu s-a auzit de coronavirus si se saruta icoanele —» Curaj.TV | Media alternativă
20:45:22(VIDEO) Francezii au ieșit la ferestre și i-au aplaudat pe medicii și asistentele care depun eforturi uriașe pentru combaterea coronavirusului —» Elena Robu
19:39:14COVID-19 pozitiv – este noul normal —» apostu
19:05:24La Peste —» turn up the silence
18:54:4027 martie – Ziua Mondială a Teatrului —» Biblioteca de Arte 'Tudor Arghezi'
18:28:06Hoții distrug pădurile în timp ce oamenii se ascund de COVID-19 —» Curaj.TV | Media alternativă