外文翻譯---托管代碼的優(yōu)點

1、<p><b>　　翻譯文獻</b></p><p><b>　　英文全文</b></p><p>　　Advantages of Managed Code</p><p>　　Microsoft intermediate language shares with Java byte code the idea

2、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 machine code. Having this well-defined universal syntax for code has signi

3、ficant advantages.</p><p>　　1.Platform independence</p><p>　　First, it means that the same file containing byte code instructions can be placed on any platform; at runtime the final stage of co

4、mpilation 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

5、 code gives Java platform independence.</p><p>　　You should note that the platform independence of .NET is only theoretical at present because, at the time of writing, a complete implementation of .NET is on

6、ly available for Windows. However, there is a partial implementation available.</p><p>　　2.Performance improvement</p><p>　　Although we previously made comparisons with Java, IL is actually a b

7、it 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

8、translating from Java byte code to native executable resulted in a loss of performance (with the exception of more recent cases, where Java is JIT compiled on certain platforms).</p><p>　　Instead of compilin

9、g 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 compiled once, the resultant native

10、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 applic

11、ation code at the start, because of the l</p><p>　　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 Mi

12、crosoft 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 progr

13、am will run on. This means that it can optimize the final executable code to take advantage of any features or particular ma</p><p>　　Traditional compilers will optimize the code, but they can only perform o

14、ptimizations 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 doe

15、sn’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 gener</p>&

16、lt;p>　　3.Language interoperability</p><p>　　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 t

17、his compiled code should then be interoperable with code that has been compiled to IL from another language.</p><p>　　You’re probably now wondering which languages aside from C# are interoperable with .NET,

18、so let’s briefly discuss how some of the other common languages fit into .NET.</p><p>　　(1)Visual Basic .NET</p><p>　　Visual Basic .NET has undergone a complete revamp from Visual Basic 6 to bri

19、ng 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 h

20、eavily 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 impleme</p><

21、p>　　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

22、 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 ch

23、anges for you. If you attempt to read a Visual Basic 6 project into</p><p>　　One side effect of this language upgrade is that it is no longer possible to compile Visual Basic .NET to native executable code.

24、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

25、 Visual Studio 6 installed if you want to continue to work in this developer environment.</p><p>　　(2)Visual C++ .NET</p><p>　　Visual C++ 6 already had a large number of Microsoft-specific exten

26、sions 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

27、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:</p><p&g

28、t;　　#using <mscorlib.dll></p><p>　　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. T

29、he 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++ cod

30、e. Thus the managed C++ code:</p><p>　　class MyClass</p><p><b>　　{</b></p><p>　　defines a plain C++ class, whereas the code:</p><p>　　__gc class MyClass<

31、/p><p><b>　　{</b></p><p>　　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 c

32、all unmanaged C++ classes from managed C++ code without having to resort to COM interop.</p><p>　　The compiler raises an error if you attempt to use features that are not supported by .NET on managed types (

33、for example, templates or multiple inheritances 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.</p&g

34、t;<p>　　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 importa

35、nt 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).</p><p>　　(3)Visual J# .NET</p><

36、p>　　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. Bec

37、ause 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 tar

38、geted at the Java runtime libraries, J# uses the same base class li</p><p>　　(4)Scripting languages</p><p>　　Scripting languages are still around, although, in general, their importance is likel

39、y to decline with the advent of .NET. JScript, on the other hand, has been upgraded to JScript .NET. We can now write ASP.NET pages in JScript .NET, run JScript .NET as a compiled rather than an interpreted language, and

40、 write strongly typed JScript .NET code. With ASP.NET there is no reason to use scripting languages in serverside Web pages. VBA is, however, still used as a language for Microsoft Office and Vis</p><p>　　(5

41、)COM and COM+</p><p>　　Technically speaking, COM and COM+ aren’t technologies targeted at .NET, because components based on them cannot be compiled into IL (although it’s possible to do so to some degree usi

42、ng managed C++, if the original COM component was written in C++). However, COM+ remains an important tool, because its features are not duplicated in .NET. Also, COM components will still work—and .NET incorporates COM

43、interoperability features that make it possible for managed code to call up COM components and v</p><p><b>　　中文譯文</b></p><p><b>　　托管代碼的優(yōu)點</b></p><p>　　Micros

44、oft中間語言與Java字節(jié)代碼共享一種理念：它們都是一種低級語言，語法很簡單(使用數(shù)字代碼，而不是文本代碼)，可以非?？焖俚剞D換為內部機器碼。對于代碼來說，這種精心設計的通用語法，有很大的優(yōu)點。</p><p><b>　　1. 平臺無關性</b></p><p>　　首先，這意味著包含字節(jié)代碼指令的同一個文件可以放在任一個平臺中，運行時編譯過程的最后階段可以很容易

45、完成，這樣代碼就可以運行在該特定的平臺上。也就是說編譯為中間語言就可以獲得.NET平臺無關性，這與編譯為Java字節(jié)代碼就會得到Java平臺無關性是一樣的。</p><p>　　注意.NET的平臺無關性目前只是一種可能，因為在編寫本書時，.NET只能用于Windows平臺，但人們正在積極準備，使它可以用于其他平臺。</p><p><b>　　2. 提高性能</b>&

46、lt;/p><p>　　實際上，IL比Java字節(jié)代碼的作用還要大。IL總是即時編譯的(稱為JIT編譯)，而Java字節(jié)代碼常常是解釋性的，Java的一個缺點是，在運行應用程序時，把Java字節(jié)代碼轉換為內部可執(zhí)行代碼的過程會導致性能的損失(但在最近，Java在某些平臺上能進行JIT編譯)。</p><p>　　JIT編譯器并不是把整個應用程序一次編譯完(這樣會有很長的啟動時間)，而是只編譯它

47、調用的那部分代碼(這是其名稱由來)。代碼編譯過一次后，得到的內部可執(zhí)行代碼就存儲起來，直到退出該應用程序為止，這樣在下次運行這部分代碼時，就不需要重新編譯了。Microsoft認為這個過程要比一開始就編譯整個應用程序代碼的效率高得多，因為任何應用程序的大部分代碼實際上并不是在每次運行過程中都執(zhí)行。使用JIT編譯器，從來都不會編譯這種代碼。</p><p>　　這解釋了為什么托管IL代碼的執(zhí)行幾乎和內部機器代碼的執(zhí)

48、行速度一樣快，但是并沒有說明為什么Microsoft認為這會提高性能。其原因是編譯過程的最后一部分是在運行時進行的，JIT編譯器確切地知道程序運行在什么類型的處理器上，利用該處理器提供的任何特性或特定的機器代碼指令來優(yōu)化最后的可執(zhí)行代碼。</p><p>　　傳統(tǒng)的編譯器會優(yōu)化代碼，但它們的優(yōu)化過程是獨立于代碼所運行的特定處理器的。這是因為傳統(tǒng)的編譯器是在發(fā)布軟件之前編譯為內部機器可執(zhí)行的代碼。即編譯器不知道代碼

49、所運行的處理器類型，例如該處理器是x86兼容處理器或Alpha處理器，這超出了基本操作的范圍。例如Visual Studio 6優(yōu)化了一臺一般的Pentium機器，所以它生成的代碼就不能利用Pentium III處理器的硬件特性。相反，JIT編譯器不僅可以進行Visual Studio 6所能完成的優(yōu)化工作，還可以優(yōu)化代碼所運行的特定處理器。</p><p>　　3. 語言的互操作性</p><

50、;p>　　使用IL不僅支持平臺無關性，還支持語言的互操作性。簡言之，就是能將任何一種語言編譯為中間代碼，編譯好的代碼可以與從其他語言編譯過來的代碼進行交互操作。</p><p>　　那么除了C#之外，還有什么語言可以通過.NET進行交互操作呢？下面就簡要討論其他常見語言如何與.NET交互操作。</p><p>　　(1) VB.NET</p><p>　　Vi

51、sual Basic 6在升級到Visual Basic .NET時，經歷了一番脫胎換骨的變化。Visual Basic是在最近的幾年中演化的，其早期版本Visual Basic 6并不適合運行.NET程序。例如，它與COM的高度集成，且只把事件處理程序作為源代碼顯示給開發(fā)人員，大多數(shù)后臺代碼不能用作源代碼。另外，它不支持繼承，Visual Basic使用的標準數(shù)據(jù)類型也與.NET不兼容。</p><p>　　V

52、isual Basic 6已經升級為Visual Basic .NET，對VB進行的改變非常大，完全可以把Visual Basic .NET當作是一種新語言?，F(xiàn)有的VB6代碼不能編譯為VB.NET代碼，把VB6程序轉換為VB.NET時，需要對代碼進行大量的改動，但大多數(shù)修改工作都可以由Visual Studio .NET(VS的升級版本，用于與.NET一起使用)自動完成。如果要把一個VB6項目讀取到Visual Studio .NET中

53、，Visual Studio .NET就會升級該項目，也就是說把VB6源代碼重寫為VB.NET源代碼。雖然這意味著其中的工作已大大減輕，但用戶仍需要檢查新的VB.NET代碼，以確保項目仍可正確工作，因為這種轉換并不十分完美。</p><p>　　這種語言升級的一個副作用是不能再把VB.NET編譯為內部可執(zhí)行代碼了。VB.NET只編譯為中間語言，就像C#一樣。如果需要繼續(xù)使用VB6編寫程序，就可以這么做，但生成的可

54、執(zhí)行代碼會完全忽略.NET Framework，如果繼續(xù)把Visual Studio作為開發(fā)環(huán)境，就需要安裝Visual Studio 6。</p><p>　　(2) Visual C++ .NET</p><p>　　Visual C++ 6有許多Microsoft對Windows的特定擴展。通過Visual C++ .NET，又加入了更多的擴展內容，來支持.NET Framework

55、?，F(xiàn)有的C++源代碼會繼續(xù)編譯為內部可執(zhí)行代碼，不會有修改，但它會獨立于.NET運行庫運行。如果要讓C++代碼在.NET Framework中運行，就要在代碼的開頭添加下述命令：</p><p>　　#using <mscorlib.dll></p><p>　　還要把標記/clr傳遞給編譯器，編譯器假定要編譯托管代碼，因此會生成中間語言，而不是內部機器碼。C++的一個有趣的問

56、題是在編譯托管代碼時，編譯器可以生成包含內嵌本機可執(zhí)行代碼的IL。這表示在C++代碼中可以把托管類型和非托管類型合并起來，因此托管C++ 代碼：</p><p>　　class MyClass</p><p><b>　　{</b></p><p>　　定義了一個普通的C++類，而代碼：</p><p>　　__gc

57、 class MyClass</p><p><b>　　{</b></p><p>　　生成了一個托管類，就好像使用C#或VB.NET編寫類一樣。實際上，托管C++比C#更優(yōu)越的一點是可以在托管C++代碼中調用非托管C++類，而不必采用COM交互功能。</p><p>　　如果在托管類型上試圖使用.NET不支持的特性(例如，模板或類的多繼承)

58、，編譯器就會出現(xiàn)一個錯誤。另外，在使用托管類時，還需要使用非標準的C++特性(例如上述代碼中的__gc關鍵字)。</p><p>　　因為C++允許低級指針操作，C++編譯器不能生成可以通過CLR內存類型安全測試的代碼。如果CLR把代碼標識為內存類型安全是非常重要的，就需要用其他一些語言編寫源代碼，例如C# 或VB.NET。</p><p>　　(3) Visual J#</p>

59、;<p>　　最新添加的語言是Visual J#。在.NET Framework 1.1版本推出之前，用戶必須下載相應的軟件，才能使用J#?，F(xiàn)在J#語言內置于.NET Framework中。因此，J#用戶可以利用Visual Studio .NET的所有常見特性。Microsoft希望大多數(shù)J++用戶認為他們在使用.NET時，將很容易使用J#。J#不使用Java運行庫，而是使用與其他.NET兼容語言一樣的基類庫。這說明，與

60、C#和VB.NET一樣，可以使用J#創(chuàng)建ASP.NET Web應用程序、Windows窗體、XML Web服務和其他應用程序。</p><p><b>　　(4) 腳本語言</b></p><p>　　腳本語言仍在使用之中，但由于.NET的推出，一般認為它們的重要性在降低。另一方面，JScript升級到JScript.NET。ASP.NET頁面可以用JScript.N

61、ET編寫，現(xiàn)在可以把JScript.NET當作一種編譯語言來運行，而不是解釋性的語言，也可以編寫輸入量比較大的JScript.NET代碼。有了ASP.NET后，就沒有必要在服務器端的Web頁面上使用腳本語言了，但VBA仍用作Office文檔和Visual Studio宏語言。</p><p>　　(5) COM和COM+</p><p>　　從技術上講，COM 和 COM+并不是面向.NE

62、T的技術，因為基于它們的組件不能編譯為IL(但如果原來的COM組件是用C++編寫的，使用托管C++，在某種程度上可以這么做)。但是，COM+仍然是一個重要的工具，因為其特性沒有在.NET中完全實現(xiàn)。另外，COM組件仍可以使用——.NET組合了COM的互操作性，從而使托管代碼可以調用COM組件，COM組件也可以調用托管代碼。在大多數(shù)情況中，把新組件編寫為.NET組件，其多數(shù)目的是為了更加方便，因為這樣可以利用.NET基類和托管代碼的其他優(yōu)