【正文】 托管代碼的優(yōu)點 Microsoft中間語言與 Java字節(jié)代碼共享一種理念：它們都是一種低級語言，語法很簡單 (使用數(shù)字代碼，而不是文本代碼 )，可以非?？焖俚剞D(zhuǎn)換為內(nèi)部機器碼。對于代碼來說，這種精心設計的通用語法，有很 大 的優(yōu)點。 1. 平臺無關性 首先，這意味著包含字節(jié)代碼指令的同一 個 文件可以放在任一 個 平臺中，運行時編譯過程的最后階段可以很容易完成，這樣代碼就可以運行在該特定的平臺上。 也就是說 編譯為中間語言就可以獲得 .NET 平臺無關性，這與編譯為 Java字節(jié)代碼就會得到 Java平臺無關性是一樣的。 注意 .NET的平臺無關性目前只是一種可能，因為在編寫本書時， .NET 只能用于 Windows平臺，但人們正在積極準備，使它可以用于其他平臺 (參見 Mono 項目，它用于創(chuàng)建 .NET 的開放源代碼的實現(xiàn)，參見 2. 提高性能 實際上， IL比 Java字節(jié)代碼的作用還要大。 IL 總是即時編譯的 (稱為 JIT 編譯 )，而 Java字節(jié)代碼常常是解釋性的， Java的一個缺點是，在運行應用程序時，把 Java字節(jié)代碼轉(zhuǎn)換為內(nèi)部可執(zhí)行代碼的過程會導致性能的損失 (但在最近， Java在某些平臺上能進行 JIT編譯 )。 JIT編譯器并不是把整個應用程序一次編譯完 (這樣會有很長的啟動時間 )，而是只編譯它調(diào)用的那部分代碼(這是其名稱由來 )。代碼編譯過一次后，得到的內(nèi)部可執(zhí)行代碼就存儲起來，直到退出該應用程序為止，這樣在下次運行這部分代碼時，就不需要重新編譯了。 Microsoft認為這個過程要比一開始就編譯整個應用程序代碼的效率高得多，因為任何應用程序的大部分代碼實際上并不是在每次運行過程中都執(zhí)行。使用 JIT 編譯器，從來都不會編譯這種代碼。 這解釋了為什么托管 IL 代碼的執(zhí)行幾乎和內(nèi)部機器代碼的執(zhí)行速度一樣快，但是并沒 有說明為什么Microsoft 認為這會提高性能。其原因是編譯過程的最后一部分是在運行時進行的， JIT 編譯器確切地知道程序運行在什么類型的處理器上，利用該處理器提供的任何特性或特定的機器代碼指令來優(yōu)化最后的可執(zhí)行代碼。 傳統(tǒng)的編譯器會優(yōu)化代碼，但它們的優(yōu)化過程是獨立于代碼所運行的特定處理器的。這是因為傳統(tǒng)的編譯器是在發(fā)布軟件之前編譯為內(nèi)部機器可執(zhí)行的代碼。即編譯器不知道代碼所運行的處理器類型，例如該處理器是 x86兼容處理器或 Alpha處理器，這超出了基本操作的范圍。例如 Visual Studio 6優(yōu)化了一臺 一般的 Pentium機器，所以它生成的代碼就不能利用 Pentium III處理器的硬件特性。相反， JIT 編譯器不僅可以進行 Visual Studio 6所能完成的優(yōu)化工作，還可以優(yōu)化代碼所運行的特定處理器。 3. 語言的互操作性 使用 IL不僅支持平臺無關性，還支持語言的互操作性。簡言之，就是能將任何一種語言編譯為中間代碼，編譯好的代碼可以與從其他語言編譯過來的代碼進行交互操作。 那么除了 C之外，還有什么語言可以通過 .NET 進行交互操作呢？下面就簡要討論其他常見語言如何與 .NET 交互操作。 (1) Visual Basic 6在升級到 Visual Basic .NET時，經(jīng)歷了一番脫胎換骨的變化。 Visual Basic是在最近的幾年中演化的，其早期版本 Visual Basic 6并不適合運行 .NET程序。例如，它與 COM的高度集成，且只把事件處理程序作為源代碼顯示給開發(fā)人員，大多數(shù)后臺代碼不能用作源代碼。另外，它不支持繼承， Visual Basic使用的標準數(shù)據(jù)類型也與 .NET不兼容。 Visual Basic 6已經(jīng)升級為 Visual Basic .NET，對 VB 進行的改變非常大，完全可以把 Visual Basic .NET當作是一種新語言?，F(xiàn)有的 VB6代碼不能編譯為 ，把 VB6程序轉(zhuǎn)換為 ，需要對代碼進行大量的改動，但大多數(shù)修改工作都可以由 Visual Studio .NET(VS的升級版本，用于與 .NET 一起使用 )自動完成。如果要把一個 VB6項目讀取到 Visual Studio .NET中， Visual Studio .NET 就會升級該項目，也就是說把 VB6源代碼重寫為 源代碼。雖然這意味著其中的工作已大大減輕，但用戶仍需要檢查新的 代碼，以確 保項目仍可正確工作，因為這種轉(zhuǎn)換并不十分完美。 這種語言升級的一個副作用是不能再把 編譯為內(nèi)部可執(zhí)行代碼了。 只編譯為中間語言，就像 C一樣。如果需要繼續(xù)使用 VB6 編寫程序，就可以這么做，但生成的可執(zhí)行代碼會完全忽略 .NET Framework，如果繼續(xù)把 Visual Studio作為開發(fā)環(huán)境，就需要安裝 Visual Studio 6。 (2) Visual C++ .NET Visual C++ 6有許多 Microsoft對 Windows的特定擴展。通過 Visual C++ .NET， 又加入了更多的擴展內(nèi)容，來支持 .NET Framework?，F(xiàn)有的 C++源代碼會繼續(xù)編譯為內(nèi)部可執(zhí)行代碼，不會有修改，但它會獨立于 .NET運行庫運行。如果要讓 C++代碼在 .NET Framework中運行，就要在代碼的開頭添加下述命令： using 還要把標記 /clr 傳遞給編譯器，編譯器假定要編譯托管代碼，因此會生成中間語言，而不是內(nèi)部機器碼。C++的一個有趣的問題是在編譯托管代碼時，編譯器可以生成包含內(nèi)嵌本機可執(zhí)行代碼的 IL。這表示在 C++代碼中可以把托管類型和非托管類型合 并起來，因此托管 C++ 代碼： class MyClass { 定義了一個普通的 C++類，而代碼： __gc class MyClass { 生成了一個托管類，就好像使用 C或 。實際上，托管 C++比 C更優(yōu)越的一點是可以在托管 C++代碼中調(diào)用非托管 C++類，而不必采用 COM交互功能。 如果在托管類型上試圖使用 .NET不支持的特性 (例如，模板或類的多繼承 )，編譯器就會出現(xiàn)一個錯誤。另外，在使用托管類時，還需要使用非標準的 C++特性 (例如上述代碼中的 __gc關鍵字 )。 因為 C++允許低 級指針