计算机专业毕业外文翻译--托管代码的优点

《计算机专业毕业外文翻译--托管代码的优点》由会员分享，可在线阅读，更多相关《计算机专业毕业外文翻译--托管代码的优点（6页珍藏版）》请在毕设资料网上搜索。

1、托管代码的优点 Microsoft 中间语言与 Java 字节代码共享一种理念：它们都是一种低级语言，语法很简单 (使用数字代码，而不是文本代码 )，可以非常快速地转换为内部机器码。对于代码来说，这种精心设计的通用语法，有很 大 的优点。 1. 平台无关性 首先，这意味着包含字节代码指令的同一 个 文件可以放在任一 个 平台中，运行时编译过程的最后阶段可以很容易完成，这样代码就可以运行在该特定的平台上。 也就是说 编译为中间语言就可以获得 .NET 平台无关性，这与编译为 Java 字节代码就会得到 Java 平台无关性是一样的。 注意 .NET 的平台无关性目前只是一种可能，因为在编写本书时

2、， .NET 只能用于 Windows 平台，但人们正在积极准备，使它可以用于其他平台 (参见 Mono 项目，它用于创建 .NET 的开放源代码的实现，参见http:/www.go- 2. 提高性能 实际上， IL 比 Java 字节代码的作用还要大。 IL 总是即时编译的 (称为 JIT 编译 )，而 Java 字节代码常常是解释性的， Java 的一个缺点是，在运行应用程序时，把 Java 字节代码转换为内部可执行代码的过程会导致性能的损失 (但在最近， Java 在某些平台上能进行 JIT 编译 )。 JIT 编译器并不是把整个应用程序一次编译完 (这样会有很长的启动时间 )，而是只编

3、译它调用的那部分代码(这是其名称由来 )。代码编译过一次后，得到的内部可执行代码就存储起来，直到退出该应用程序为止，这样在下次运行这部分代码时，就不需要重新编译了。 Microsoft 认为这个过程要比一开始就编译整个应用程序代码的效率高得多，因为任何应用程序的大部分代码实际上并不是在每次运行过程中都执行。使用 JIT 编译器，从来都不会编译这种代码。 这解释了为什么托管 IL 代码的执行几乎和内部机器代码的执行速度一样快，但是并没 有说明为什么Microsoft 认为这会提高性能。其原因是编译过程的最后一部分是在运行时进行的， JIT 编译器确切地知道程序运行在什么类型的处理器上，利用该处理

4、器提供的任何特性或特定的机器代码指令来优化最后的可执行代码。 传统的编译器会优化代码，但它们的优化过程是独立于代码所运行的特定处理器的。这是因为传统的编译器是在发布软件之前编译为内部机器可执行的代码。即编译器不知道代码所运行的处理器类型，例如该处理器是 x86 兼容处理器或 Alpha 处理器，这超出了基本操作的范围。例如 Visual Studio 6 优化了一台 一般的 Pentium机器，所以它生成的代码就不能利用 Pentium III 处理器的硬件特性。相反， JIT 编译器不仅可以进行 Visual Studio 6 所能完成的优化工作，还可以优化代码所运行的特定处理器。 3. 语

5、言的互操作性 使用 IL 不仅支持平台无关性，还支持语言的互操作性。简言之，就是能将任何一种语言编译为中间代码，编译好的代码可以与从其他语言编译过来的代码进行交互操作。 那么除了 C#之外，还有什么语言可以通过 .NET 进行交互操作呢？下面就简要讨论其他常见语言如何与 .NET 交互操作。 (1) VB.NET Visual Basic 6 在升级到 Visual Basic .NET 时，经历了一番脱胎换骨的变化。 Visual Basic 是在最近的几年中演化的，其早期版本 Visual Basic 6 并不适合运行 .NET 程序。例如，它与 COM 的高度集成，且只把事件处理程序作为

6、源代码显示给开发人员，大多数后台代码不能用作源代码。另外，它不支持继承， Visual Basic 使用的标准数据类型也与 .NET 不兼容。 Visual Basic 6 已经升级为 Visual Basic .NET，对 VB 进行的改变非常大，完全可以把 Visual Basic .NET 当作是一种新语言。现有的 VB6 代码不能编译为 VB.NET 代码，把 VB6 程序转换为 VB.NET 时，需要对代码进行大量的改动，但大多数修改工作都可以由 Visual Studio .NET(VS 的升级版本，用于与 .NET 一起使用 )自动完成。如果要把一个 VB6 项目读取到 Visu

7、al Studio .NET 中， Visual Studio .NET 就会升级该项目，也就是说把 VB6源代码重写为 VB.NET 源代码。虽然这意味着其中的工作已大大减轻，但用户仍需要检查新的 VB.NET 代码，以确 保项目仍可正确工作，因为这种转换并不十分完美。 这种语言升级的一个副作用是不能再把 VB.NET 编译为内部可执行代码了。 VB.NET 只编译为中间语言，就像 C#一样。如果需要继续使用 VB6 编写程序，就可以这么做，但生成的可执行代码会完全忽略 .NET Framework，如果继续把 Visual Studio 作为开发环境，就需要安装 Visual Studio

8、 6。 (2) Visual C+ .NET Visual C+ 6 有许多 Microsoft 对 Windows 的特定扩展。通过 Visual C+ .NET， 又加入了更多的扩展内容，来支持 .NET Framework。现有的 C+源代码会继续编译为内部可执行代码，不会有修改，但它会独立于 .NET运行库运行。如果要让 C+代码在 .NET Framework 中运行，就要在代码的开头添加下述命令： #using 还要把标记 /clr 传递给编译器，编译器假定要编译托管代码，因此会生成中间语言，而不是内部机器码。C+的一个有趣的问题是在编译托管代码时，编译器可以生成包含内嵌本机可执行

9、代码的 IL。这表示在 C+代码中可以把托管类型和非托管类型合 并起来，因此托管 C+ 代码： class MyClass 定义了一个普通的 C+类，而代码： _gc class MyClass 生成了一个托管类，就好像使用 C#或 VB.NET 编写类一样。实际上，托管 C+比 C#更优越的一点是可以在托管 C+代码中调用非托管 C+类，而不必采用 COM 交互功能。 如果在托管类型上试图使用 .NET 不支持的特性 (例如，模板或类的多继承 )，编译器就会出现一个错误。另外，在使用托管类时，还需要使用非标准的 C+特性 (例如上述代码中的 _gc 关键字 )。 因为 C+允许低 级指针操作

10、， C+编译器不能生成可以通过 CLR 内存类型安全测试的代码。如果 CLR 把代码标识为内存类型安全是非常重要的，就需要用其他一些语言编写源代码，例如 C# 或 VB.NET。 (3) Visual J# 最新添加的语言是 Visual J#。在 .NET Framework 1.1 版本推出之前，用户必须下载相应的软件，才能使用J#。现在 J#语言内置于 .NET Framework 中。因此， J#用户可以利用 Visual Studio .NET 的所有常见特性。 Microsoft希望大多数 J+用户认为他们在使用 .NET 时，将很容易使用 J#。 J#不使用 Java 运行库，而

11、是使用与其他 .NET兼容语言一样的基类库。这说明，与 C#和 VB.NET 一样，可以使用 J#创建 ASP.NET Web 应用程序、 Windows窗体、 XML Web 服务和其他应用程序。 (4) 脚本语言 脚本语言仍在使用之中，但由于 .NET 的推出，一般认为它们的重要性在降低。另一方面， JScript 升级到JScript.NET。 ASP.NET 页面可以用 JScript.NET 编写，现在可以把 JScript.NET 当作一种编译语言来运行，而不是解释性的语言，也可以 编写输入量比较大的 JScript.NET 代码。有了 ASP.NET 后，就没有必要在服务器端的W

12、eb 页面上使用脚本语言了，但 VBA 仍用作 Office 文档和 Visual Studio 宏语言。 (5) COM 和 COM+ 从技术上讲， COM 和 COM+并不是面向 .NET 的技术，因为基于它们的组件不能编译为 IL(但如果原来的COM 组件是用 C+编写的，使用托管 C+，在某种程度上可以这么做 )。但是， COM+仍然是一个重要的工具，因为其特性没有在 .NET 中完全实现。另外， COM 组件仍可以使用 .NET 组合了 COM 的互操作性，从而使托管代码可以调用 COM 组件， COM 组件也可以调用托管代码 (见第 29 章 )。在大多数情况中，把新组件编写为 .

13、NET 组件，其多数目的是为了 更加 方便，因为这样可以利用 .NET 基类和托管代码的其他优点。 原文 : 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 (based on numeric codes rather than text), which can be very quickly translated into native machi

14、ne 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

15、 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. You should note that the platform independence of .NET is only theoretical at present because, at

16、the time of writing, a complete implementation of .NET is only available for Windows. However, there is a partial implementation available (see for example the Mono project, an effort to create an open source implementation of .NET, at www.go- Performance improvement Although we previously made comp

17、arisons with Java, IL is actually a bit more ambitious than Java byte code. IL is always Just-In-Time compiled (known as JIT compilation), 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 e

18、xecutable resulted in a loss of performance (with the exception of more recent cases, where Java is JIT compiled on certain platforms). 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 cal

19、led (just-in-time). When code has been compiled once, 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

20、 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 na

21、tive machine code. What it doesnt 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 th

22、at it can optimize the final executable code to take advantage of any features or particular machine code instructions offered by that particular processor. 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 doesnt know