計算機專業(yè)畢業(yè)外文翻譯--托管代碼的優(yōu)點

1、<p><b>　　托管代碼的優(yōu)點</b></p><p>　　Microsoft中間語言與Java字節(jié)代碼共享一種理念：它們都是一種低級語言，語法很簡單(使用數(shù)字代碼，而不是文本代碼)，可以非?？焖俚剞D(zhuǎn)換為內(nèi)部機器碼。對于代碼來說，這種精心設計的通用語法，有很大的優(yōu)點。</p><p><b>　　1. 平臺無關(guān)性</b></p

2、><p>　　首先，這意味著包含字節(jié)代碼指令的同一個文件可以放在任一個平臺中，運行時編譯過程的最后階段可以很容易完成，這樣代碼就可以運行在該特定的平臺上。也就是說編譯為中間語言就可以獲得.NET平臺無關(guān)性，這與編譯為Java字節(jié)代碼就會得到Java平臺無關(guān)性是一樣的。</p><p>　　注意.NET的平臺無關(guān)性目前只是一種可能，因為在編寫本書時，.NET只能用于Windows平臺，但人們正在

3、積極準備，使它可以用于其他平臺(參見Mono項目，它用于創(chuàng)建.NET的開放源代碼的實現(xiàn)，參見http://www.go-mono.com/)。</p><p><b>　　2. 提高性能</b></p><p>　　實際上，IL比Java字節(jié)代碼的作用還要大。IL總是即時編譯的(稱為JIT編譯)，而Java字節(jié)代碼常常是解釋性的，Java的一個缺點是，在運行應用程序時

4、，把Java字節(jié)代碼轉(zhuǎn)換為內(nèi)部可執(zhí)行代碼的過程會導致性能的損失(但在最近，Java在某些平臺上能進行JIT編譯)。</p><p>　　JIT編譯器并不是把整個應用程序一次編譯完(這樣會有很長的啟動時間)，而是只編譯它調(diào)用的那部分代碼(這是其名稱由來)。代碼編譯過一次后，得到的內(nèi)部可執(zhí)行代碼就存儲起來，直到退出該應用程序為止，這樣在下次運行這部分代碼時，就不需要重新編譯了。Microsoft認為這個過程要比一開始

5、就編譯整個應用程序代碼的效率高得多，因為任何應用程序的大部分代碼實際上并不是在每次運行過程中都執(zhí)行。使用JIT編譯器，從來都不會編譯這種代碼。</p><p>　　這解釋了為什么托管IL代碼的執(zhí)行幾乎和內(nèi)部機器代碼的執(zhí)行速度一樣快，但是并沒有說明為什么Microsoft認為這會提高性能。其原因是編譯過程的最后一部分是在運行時進行的，JIT編譯器確切地知道程序運行在什么類型的處理器上，利用該處理器提供的任何特性或特

6、定的機器代碼指令來優(yōu)化最后的可執(zhí)行代碼。</p><p>　　傳統(tǒng)的編譯器會優(yōu)化代碼，但它們的優(yōu)化過程是獨立于代碼所運行的特定處理器的。這是因為傳統(tǒng)的編譯器是在發(fā)布軟件之前編譯為內(nèi)部機器可執(zhí)行的代碼。即編譯器不知道代碼所運行的處理器類型，例如該處理器是x86兼容處理器或Alpha處理器，這超出了基本操作的范圍。例如Visual Studio 6優(yōu)化了一臺一般的Pentium機器，所以它生成的代碼就不能利用Pent

7、ium III處理器的硬件特性。相反，JIT編譯器不僅可以進行Visual Studio 6所能完成的優(yōu)化工作，還可以優(yōu)化代碼所運行的特定處理器。</p><p>　　3. 語言的互操作性</p><p>　　使用IL不僅支持平臺無關(guān)性，還支持語言的互操作性。簡言之，就是能將任何一種語言編譯為中間代碼，編譯好的代碼可以與從其他語言編譯過來的代碼進行交互操作。</p><

8、p>　　那么除了C#之外，還有什么語言可以通過.NET進行交互操作呢？下面就簡要討論其他常見語言如何與.NET交互操作。</p><p>　　(1) VB.NET</p><p>　　Visual Basic 6在升級到Visual Basic .NET時，經(jīng)歷了一番脫胎換骨的變化。Visual Basic是在最近的幾年中演化的，其早期版本Visual Basic 6并不適合運行.N

9、ET程序。例如，它與COM的高度集成，且只把事件處理程序作為源代碼顯示給開發(fā)人員，大多數(shù)后臺代碼不能用作源代碼。另外，它不支持繼承，Visual Basic使用的標準數(shù)據(jù)類型也與.NET不兼容。</p><p>　　Visual Basic 6已經(jīng)升級為Visual Basic .NET，對VB進行的改變非常大，完全可以把Visual Basic .NET當作是一種新語言?，F(xiàn)有的VB6代碼不能編譯為VB.NET代

10、碼，把VB6程序轉(zhuǎn)換為VB.NET時，需要對代碼進行大量的改動，但大多數(shù)修改工作都可以由Visual Studio .NET(VS的升級版本，用于與.NET一起使用)自動完成。如果要把一個VB6項目讀取到Visual Studio .NET中，Visual Studio .NET就會升級該項目，也就是說把VB6源代碼重寫為VB.NET源代碼。雖然這意味著其中的工作已大大減輕，但用戶仍需要檢查新的VB.NET代碼，以確保項目仍可正確工作，

11、因為這種轉(zhuǎn)換并不十分完美。</p><p>　　這種語言升級的一個副作用是不能再把VB.NET編譯為內(nèi)部可執(zhí)行代碼了。VB.NET只編譯為中間語言，就像C#一樣。如果需要繼續(xù)使用VB6編寫程序，就可以這么做，但生成的可執(zhí)行代碼會完全忽略.NET Framework，如果繼續(xù)把Visual Studio作為開發(fā)環(huán)境，就需要安裝Visual Studio 6。</p><p>　　(2) Vi

12、sual C++ .NET</p><p>　　Visual C++ 6有許多Microsoft對Windows的特定擴展。通過Visual C++ .NET，又加入了更多的擴展內(nèi)容，來支持.NET Framework?，F(xiàn)有的C++源代碼會繼續(xù)編譯為內(nèi)部可執(zhí)行代碼，不會有修改，但它會獨立于.NET運行庫運行。如果要讓C++代碼在.NET Framework中運行，就要在代碼的開頭添加下述命令：</p>

13、<p>　　#using <mscorlib.dll></p><p>　　還要把標記/clr傳遞給編譯器，編譯器假定要編譯托管代碼，因此會生成中間語言，而不是內(nèi)部機器碼。C++的一個有趣的問題是在編譯托管代碼時，編譯器可以生成包含內(nèi)嵌本機可執(zhí)行代碼的IL。這表示在C++代碼中可以把托管類型和非托管類型合并起來，因此托管C++ 代碼：</p><p>　　cl

14、ass MyClass</p><p><b>　　{</b></p><p>　　定義了一個普通的C++類，而代碼：</p><p>　　__gc class MyClass</p><p><b>　　{</b></p><p>　　生成了一個托管類，就好像使用C#或VB

15、.NET編寫類一樣。實際上，托管C++比C#更優(yōu)越的一點是可以在托管C++代碼中調(diào)用非托管C++類，而不必采用COM交互功能。</p><p>　　如果在托管類型上試圖使用.NET不支持的特性(例如，模板或類的多繼承)，編譯器就會出現(xiàn)一個錯誤。另外，在使用托管類時，還需要使用非標準的C++特性(例如上述代碼中的__gc關(guān)鍵字)。</p><p>　　因為C++允許低級指針操作，C++編譯器

16、不能生成可以通過CLR內(nèi)存類型安全測試的代碼。如果CLR把代碼標識為內(nèi)存類型安全是非常重要的，就需要用其他一些語言編寫源代碼，例如C# 或VB.NET。</p><p>　　(3) Visual J#</p><p>　　最新添加的語言是Visual J#。在.NET Framework 1.1版本推出之前，用戶必須下載相應的軟件，才能使用J#?，F(xiàn)在J#語言內(nèi)置于.NET Framewor

17、k中。因此，J#用戶可以利用Visual Studio .NET的所有常見特性。Microsoft希望大多數(shù)J++用戶認為他們在使用.NET時，將很容易使用J#。J#不使用Java運行庫，而是使用與其他.NET兼容語言一樣的基類庫。這說明，與C#和VB.NET一樣，可以使用J#創(chuàng)建ASP.NET Web應用程序、Windows窗體、XML Web服務和其他應用程序。</p><p><b>　　(4)

18、腳本語言</b></p><p>　　腳本語言仍在使用之中，但由于.NET的推出，一般認為它們的重要性在降低。另一方面，JScript升級到JScript.NET。ASP.NET頁面可以用JScript.NET編寫，現(xiàn)在可以把JScript.NET當作一種編譯語言來運行，而不是解釋性的語言，也可以編寫輸入量比較大的JScript.NET代碼。有了ASP.NET后，就沒有必要在服務器端的Web頁面上使用

19、腳本語言了，但VBA仍用作Office文檔和Visual Studio宏語言。</p><p>　　(5) COM和COM+</p><p>　　從技術(shù)上講，COM 和 COM+并不是面向.NET的技術(shù)，因為基于它們的組件不能編譯為IL(但如果原來的COM組件是用C++編寫的，使用托管C++，在某種程度上可以這么做)。但是，COM+仍然是一個重要的工具，因為其特性沒有在.NET中完全實現(xiàn)。

20、另外，COM組件仍可以使用——.NET組合了COM的互操作性，從而使托管代碼可以調(diào)用COM組件，COM組件也可以調(diào)用托管代碼(見第29章)。在大多數(shù)情況中，把新組件編寫為.NET組件，其多數(shù)目的是為了更加方便，因為這樣可以利用.NET基類和托管代碼的其他優(yōu)點。</p><p><b>　　原文:</b></p><p>　　Advantages of Managed

21、Code</p><p>　　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 tra

22、nslated into native machine code. Having this well-defined universal syntax for code has significant advantages.</p><p>　　Platform independence</p><p>　　First, it means that the same file contai

23、ning 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

24、IL we obtain platform independence for .NET, in much the same way as compiling to Java byte code gives Java platform independence.</p><p>　　You should note that the platform independence of .NET is only theo

25、retical at present because, at 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 cr

26、eate an open source implementation of .NET, at www.go-mono.com/).</p><p>　　Performance improvement</p><p>　　Although we previously made comparisons with Java, IL is actually a bit more ambitious

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

28、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 compiling the entire appl

29、ication 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</p><p>　　once, the resultant na

30、tive 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 a

31、pplication 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.</p><

32、;p>　　This explains why we can expect that execution of managed IL code will be almost as fast as executing</p><p>　　native machine code. What it doesn’t explain is why Microsoft expects that we will get a

33、 performance</p><p>　　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

34、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.</p><p>　　Traditional compilers wi

35、ll 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 soft

36、ware 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

37、, for example, optimizes for a gener</p><p>　　so the code that it generates cannot take advantage of hardware features of Pentium III processors. On</p><p>　　the other hand, the JIT compiler can

38、 do all the optimizations that Visual Studio 6 can, and in addition it</p><p>　　will optimize for the particular processor the code is running on.</p><p>　　Language interoperability</p>&

39、lt;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 this compiled code should then be interoperable with

40、 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, so let’s</p><p>　　briefly discuss how

41、some of the other common languages fit into .NET.</p><p>　　Visual Basic .NET</p><p>　　Visual Basic .NET has undergone a complete revamp from Visual Basic 6 to bring it up-to-date with .NET. The

42、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 w

43、orks 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><p>　　One side effect of this l

44、anguage 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 d

45、o 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.</p><p>　　Vis

46、ual C++ .NET</p><p>　　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 exis

47、ting 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 F

48、ramework, then you can simply add the following line to the beginning of your code:</p><p>　　#using <mscorlib.dll></p><p>　　You can also pass the flag /clr to the compiler, which then assu

49、mes that you want to compile to managed</p><p>　　code, and will hence emit IL instead of native machine code. The interesting thing about C++ is</p><p>　　that when you compile to managed code, t

50、he compiler can emit IL that contains an embedded native</p><p>　　executable. This means that you can mix managed types and unmanaged types in your C++ code. Thus</p><p>　　the managed C++ code:&

51、lt;/p><p>　　class MyClass</p><p><b>　　{</b></p><p>　　defines a plain C++ class, whereas the code:</p><p>　　__gc class MyClass</p><p><b>　　{&

52、lt;/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</p><p>　　of using managed C++ over C# code is that we can call unma

53、naged C++ classes from managed C++</p><p>　　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 m

54、anaged</p><p>　　types (for example, templates or multiple inheritance of classes). You will also find that you will need to</p><p>　　use nonstandard C++ features (such as the __gc keyword shown

55、in the previous code) when using</p><p>　　managed classes.</p><p>　　Because of the freedom that C++ allows in terms of low-level pointer manipulation and so on, the C++</p><p>　　com

56、piler is not able to generate code that will pass the CLR’s memory type safety tests. If it’s important</p><p>　　that your code is recognized by the CLR as memory type safe, then you’ll need to write your so

57、urce code</p><p>　　in some other language (such as C# or Visual Basic .NET).</p><p>　　Visual J# .NET</p><p>　　The latest language to be added to the mix is Visual J# .NET. Prior to

58、.NET Framework 1.1, users were</p><p>　　able to use J# only after making a separate download. Now the J# language is built into the .NET</p><p>　　Framework. Because of this, J# users are able to

59、 take advantage of all the usual features of Visual Studio</p><p>　　.NET. Microsoft expects that most J++ users will find it easiest to use J# if they want to work with .NET.</p><p>　　Instead of

60、 being targeted at the Java runtime libraries, J# uses the same base class libraries that the rest</p><p>　　of the .NET compliant languages use. This means that you can use J# for building ASP.NET Web applic

61、ations,</p><p>　　Windows Forms, XMLWeb services, and everything else that is possible—just as C# and Visual</p><p>　　Basic .NET can.</p><p>　　Scripting languages</p><p>

62、;　　Scripting languages are still around, although, in general, their importance is likely to decline with the</p><p>　　advent of .NET. JScript, on the other hand, has been upgraded to JScript .NET. We can no

63、w write ASP.NET</p><p>　　pages in JScript .NET, run JScript .NET as a compiled rather than an interpreted language, and write</p><p>　　strongly typed JScript .NET code. With ASP.NET there is no

64、reason to use scripting languages in serverside</p><p>　　Web pages. VBA is, however, still used as a language for Microsoft Office and Visual Studio macros.</p><p>　　COM and COM+</p><

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

66、ged C++, if</p><p>　　the original COM component was written in C++). However, COM+ remains an important tool, because</p><p>　　its features are not duplicated in .NET. Also, COM components will

67、still work—and .NET incorporates</p><p>　　COM interoperability features that make it possible for managed code to call up COM components and</p><p>　　vice versa (this is discussed in Chapter 29)

68、. In general, however, you will probably find it more convenient</p><p>　　for most purposes to code new components as .NET components, so that you can take advantage of the</p><p>　　.NET base cl