計(jì)算機(jī)專業(yè)外文翻譯----托管代碼的優(yōu)點(diǎn)

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

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

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

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

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

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

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

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

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

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

11、因?yàn)檫@種轉(zhuǎn)換并不十分完美。</p><p>　　這種語(yǔ)言升級(jí)的一個(gè)副作用是不能再把VB.NET編譯為內(nèi)部可執(zhí)行代碼了。VB.NET只編譯為中間語(yǔ)言，就像C#一樣。如果需要繼續(xù)使用VB6編寫程序，就可以這么做，但生成的可執(zhí)行代碼會(huì)完全忽略.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對(duì)Windows的特定擴(kuò)展。通過Visual C++ .NET，又加入了更多的擴(kuò)展內(nèi)容，來支持.NET Framework?，F(xiàn)有的C++源代碼會(huì)繼續(xù)編譯為內(nèi)部可執(zhí)行代碼，不會(huì)有修改，但它會(huì)獨(dú)立于.NET運(yùn)行庫(kù)運(yùn)行。如果要讓C++代碼在.NET Framework中運(yùn)行，就要在代碼的開頭添加下述命令：</p>

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

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

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

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

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

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

19、腳本語(yǔ)言了，但VBA仍用作Office文檔和Visual Studio宏語(yǔ)言。</p><p>　　(5) COM和COM+</p><p>　　從技術(shù)上講，COM 和 COM+并不是面向.NET的技術(shù)，因?yàn)榛谒鼈兊慕M件不能編譯為IL(但如果原來的COM組件是用C++編寫的，使用托管C++，在某種程度上可以這么做)。但是，COM+仍然是一個(gè)重要的工具，因?yàn)槠涮匦詻]有在.NET中完全實(shí)現(xiàn)。

20、另外，COM組件仍可以使用——.NET組合了COM的互操作性，從而使托管代碼可以調(diào)用COM組件，COM組件也可以調(diào)用托管代碼(見第29章)。在大多數(shù)情況中，把新組件編寫為.NET組件，其多數(shù)目的是為了更加方便，因?yàn)檫@樣可以利用.NET基類和托管代碼的其他優(yōu)點(diǎn)。</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