A Closer Look at Intermediate Language
From what we learned in the previous section, Microsoft intermediate language obviously plays a fundamentalrole 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