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

1、<p>　　Advantages of Managed 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 tex

2、t), which can be very quickly translated into native machine code. Having this well-defined universal syntax for code has significant advantages.</p><p>　　Platform independence</p><p>　　First, i

3、t 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.

4、 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.</p><p>　　You should note that the platform

5、independence of .NET is only theoretical 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

6、the Mono project, an effort to create 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

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

8、 the process of 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>　　Ins

9、tead 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 compiled</p>

10、<p>　　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 effi

11、cient 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

12、never be compiled.</p><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 Mic

13、rosoft expects that we will get a 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 pro

14、cessor 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.</p>&l

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

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

17、 Alpha processor. Visual Studio 6, 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

18、 other hand, the JIT compiler can 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>　　Langu

19、age 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 this compiled code

20、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, so let’s</p>

21、<p>　　briefly discuss how 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 br

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

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

24、;p>　　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 co

25、ding 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 envir

26、onment.</p><p>　　Visual 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 .NE

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

28、C++ code to run within the .NET Framework, 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

29、 to the compiler, which then assumes 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 wh

30、en you compile to managed code, the 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>

31、<p>　　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&

32、lt;/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</p><p>　　of using managed C++ over

33、 C# code is that we can call unmanaged 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 th

34、at are not supported by .NET on managed</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

35、 (such as the __gc keyword shown 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,

36、the C++</p><p>　　compiler 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,

37、then you’ll need to write your source 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

38、 mix is Visual J# .NET. Prior to .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. Beca

39、use of this, J# users are able to 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.

40、</p><p>　　Instead of 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

41、# for building ASP.NET Web applications,</p><p>　　Windows Forms, XMLWeb services, and everything else that is possible—just as C# and Visual</p><p>　　Basic .NET can.</p><p>　　Script

42、ing languages</p><p>　　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 up

43、graded to JScript .NET. We can now 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 .NE

44、T code. With ASP.NET there is no 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&

45、gt;　　COM and COM+</p><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 t

46、o do so to some degree using managed 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

47、 .NET. Also, COM components will 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

48、(this is discussed in Chapter 29). 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&l

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

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

51、ows平臺，但人們正在積極準備，使它可以用于其他平臺(參見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的一個缺

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

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

54、理器提供的任何特性或特定的機器代碼指令來優(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機器，所以它生成的

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

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

57、c 6并不適合運行.NET程序。例如，它與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代碼不

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

59、確保項目仍可正確工作，因為這種轉(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&

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

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

62、t;p>　　class MyClass</p><p><b>　　{</b></p><p>　　定義了一個普通的C++類，而代碼：</p><p>　　__gc class MyClass</p><p><b>　　{</b></p><p>　　生成了一個托管類

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

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

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

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

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