-
Advantages of
Managed Code
Microsoft
intermediate language shares with Java byte code
the idea that it is a low-level language with
a simple syntax , which can be very
quickly translated into native machine code.
Having this
well-defined universal
syntax for code has significant advantages.
Platform independence
First,
it means that the same file containing byte code
instructions can be placed on any platform; at
runtime the final stage of compilation
can then be easily accomplished so that the code
will run on that
particular platform.
In other words, by compiling to IL we obtain
platform independence for .NET, in
much
the same way as compiling to Java byte code gives
Java platform independence.
Performance
improvement
IL is actually a bit more
ambitious than Java byte code. IL is always Just-
In-Time compiled (known as
JIT),
whereas Java byte code was often interpreted. One
of the disadvantages of Java was that, on
execution, the process of translating
from Java byte code to native executable resulted
in a loss of
performance.
Instead of compiling the entire
application in one go (which could lead to a slow
start-up time), the JIT
compiler simply
compiles each portion of code as it is called
(just-in-time). When code has been
,
the resultant native executable is stored until
the application exits, so that it does not
need to be recompiled the next time
that portion of code is run. Microsoft argues that
this process is
more efficient than
compiling the entire application code at the
start, because of the likelihood that large
portions of any application code will
not actually be executed in any given run. Using
the JIT compiler,
such code will never
be compiled.
This explains why we can
expect that execution of managed IL code will be
almost as fast as executing
native
machine code. What it doesn’t explain is why
Microsoft expects that we will get a
performance
improvement. The
reason given for this is that, since the final
stage of compilation takes place at
runtime, the JIT compiler will know
exactly what processor type the program will run
on. This means
that it can optimize the
final executable code to take advantage of any
features or particular machine
code
instructions offered by that particular processor.
实际上，
IL
比
Java
字节代码的作用还要大。
IL
总是即时编译的
(
简称
JIT)
，
而
Java
字节
代码常常是解释型的，
Java
的一个缺点是，在运行应用程序
时，把
Java
字节代码转换为内部可执行代码的过程可可能导
致性能的损失。
JIT
编译器并不是
把整个应用程序一次编译完
(
这样会有很长的启动时间
)
，而是只编译它调用的那部分代
码。代码编译
过一次后，得到的内部可执行代码就存储起来，直到退出该应用程序为止，这样在下次运行这部
< br>分代码时，就不需要重新编译了。
Microsoft
认
为这个过程要比一开始就编译整个应用程序代码的效率高得多，
因为任何应用程序的大部
分代码实际上并不是在每次运行过程中都执行。使用
JIT
编译
器，从来都不会编译这
种代码从来都不会被编译。
这解释了为什么托管
IL
代码的执行几乎和内部机
器代码的执行速度一样快，但是并没有说明为什么
Microsoft
< br>认为这会提高性能。其原因是编译过程的最后一部分是在运行时进行的，
JIT<
/p>
编译器确切地知道程序
运行在什么类型的处理器上，利用该处理器
提供的任何特性或特定的机器代码指令来优化最后的可执行代码。
传统的编译器会优化代码，但它们的优化过程是独立于代码所运行的特定处理器的。这是因为传统的编译
器是在发布软件之前编译为内部机器可执行的代码。即编译器不知道代码所运行的处理器类型
，例如该处理器
是
x86
兼容处理器或
Alpha
处理器，
这超出了基本操作
的范围。
例如
Visual Studio 6
优化了一台一般的
Pentium
机器，
所以它生成的代码就不能利用
Pentium III
处理器的硬件特性。
相反，
JIT
编
译器不仅可以进行
Visual Studio
6
所能完成的优化工作，还可以优化代码所运行的特定处理器。
Traditional compilers will
optimize the code, but they can only perform
optimizations that are
independent of
the particular processor that the code will run
on. This is because traditional compilers
compile
to native executable
before the software is shipped. This means that
the compiler doesn’t know
what type of
processor the code will run on beyond basic
generalities, such as that it will be an
x86-compatible processor or an Alpha
processor. Visual Studio 6, for example, optimizes
for a generic
Pentium machine,
so the code that it generates cannot
take advantage of hardware features of Pentium III
processors. On
the other hand, the JIT
compiler can do all the optimizations that Visual
Studio 6 can, and in addition it
will
optimize for the particular processor the code is
running on.
Language interoperability
The use of IL not only enables platform
independence; it also facilitates language
interoperability.
Simply put, you can
compile to IL from one language, and this compiled
code should then be
interoperable with
code that has been compiled to IL from another
language.
You’re probably now wondering
which languages aside from C# are interoperable
with .NET, so let’s
briefly
discuss how some of the other common languages fit
into .NET.
Visual Basic
.NET
Visual Basic .NET has undergone a
complete revamp from Visual Basic 6 to bring it
up-to-date
with .NET. The way that
Visual Basic has evolved over the last few years
means that in its previous
version,
Visual Basic 6, it was not a suitable language for
running .NET programs. For example, it is
heavily integrated into COM and works
by exposing only event handlers as source code to
the
developer
—
most of
the background code is not available as source
code. Not only that, it does not
support implementation inheritance, and
the standard data types Visual Basic 6 uses are
incompatible
with .NET. Visual Basic 6
was upgraded to Visual Basic .NET, and the changes
that were made to the
language are so
extensive you might as well regard Visual Basic
.NET as a new language. Existing
Visual
Basic 6 code does not compile as Visual Basic .NET
code. Converting a Visual Basic 6 program
to Visual Basic .NET requires extensive
changes to the code. However, Visual Studio .NET
(the
upgrade of VS for use with .NET)
can do most of the changes for you. If you attempt
to read a Visual
Basic 6 project into
Visual Studio .NET, it will upgrade the project
for you, which means that it will
rewrite the Visual Basic 6 source code
into Visual Basic .NET source code. Although this
means that the
work involved for you is
heavily cut down, you will need to check through
the new Visual Basic .NET
code to make
sure that the project still works as intended
because the conversion might not be perfect.
One side effect of this language
upgrade is that it is no longer possible to
compile Visual Basic .NET to
native
executable code. Visual Basic .NET compiles only
to IL, just as C# does. If you need to continue
coding in Visual Basic 6, you may do
so, but the executable code produced will
completely ignore
the
.NET
Framework, and you’ll need to keep Visual Studio 6
installed if you want
to continue to
work
in this developer environment.
Visual C++ .NET
Visual C++ 6
already had a large number of Microsoft-specific
extensions on Windows. With Visual
C++
.NET, extensions have been added to support the
.NET Framework. This means that existing C++
source code will continue to compile to
native executable code without modification. It
also means,
however, that it will run
independently of the .NET runtime. If you want
your C++ code to run within
the .NET
Framework, then you can simply add the following
line to the beginning of your code:
#using <>
You can also pass
the flag /clr to the compiler, which then assumes
that you want to compile to managed
code, and will hence emit IL instead of
native machine code. The interesting thing about
C++ is
that when you compile to managed
code, the compiler can emit IL that contains an
embedded native
executable. This means
that you can mix managed types and unmanaged types
in your C++ code. Thus
the managed C++
code:
class MyClass
{
defines a plain C++ class, whereas the
code:
__gc class MyClass
{
will give you a managed class, just as
if you’d written the class in C# or Visual Basic
.NET. The
advantage
of using
managed C++ over C# code is that we can call
unmanaged C++ classes from managed C++
code without having to resort to COM
interop.
The compiler raises an error
if you attempt to use features that are not
supported by .NET on managed
types (for
example, templates or multiple inheritance of
classes). You will also find that you will need to
use nonstandard C++ features (such as
the __gc keyword shown in the previous code) when
using
managed classes.
Because of the freedom that C++ allows
in terms of low-level pointer manipulation and so
on, the C++
compiler is not able to
generate code that will
pass the CLR’s
memory type safety tests. If it’s
important
that your code is
recognized by the CLR as memory type safe, then
you’ll need to write your source
code
in some other language (such as C# or
Visual Basic .NET).
Visual J# .NET
The latest language to be added to the
mix is Visual J# .NET. Prior to .NET Framework
1.1, users were
able to use J# only
after making a separate download. Now the J#
language is built into the .NET
Framework. Because of this, J# users
are able to take advantage of all the usual
features of Visual Studio
.NET.
Microsoft expects that most J++ users will find it
easiest to use J# if they want to work
with .NET.
Instead of being
targeted at the Java runtime libraries, J# uses
the same base class libraries that the rest
of the .NET compliant languages use.
This means that you can use J# for building Web
applications,
Windows Forms,
XMLWeb services, and everything else that is
possible
—
just as C# and
Visual
Basic .NET can.
Scripting languages
Scripting languages are still around,
although, in general, their importance is likely
to decline with the
advent of .NET.
JScript, on the other hand, has been upgraded to
JScript .NET. We can now write
pages in JScript .NET, run JScript .NET
as a compiled rather than an interpreted language,
and write
-
-
-
-
-
-
-
-
-
上一篇：英文机加工术语
下一篇：高三英语语法填空专练总结