細說ＶＢ．ＮＥＴ（中）
2024-07-21 02:21:07
供稿：網(wǎng)友
細說ｖｂ．ｎｅｔ（中）
（作者：青蘋果工作室編譯 2001年03月07日 14:47）
易于反編譯的中間語言
無論你用vb、c#或其它.net語言編寫應用程序，vs.net代碼都編譯成為中間語言(il)。當應用程序運行時，一個即時編譯器(jitter)處理il代碼并把它編譯成為機器語言。這意味著在理論上可能為windows以外的平臺創(chuàng)建.net運行庫，但現(xiàn)在關于類似的事情還沒有任何官方消息。中間語言的一個缺陷是：它像vb5以前的vb版本一樣，容易被反編譯。這種可能性使許多開發(fā)者普遍地質(zhì)疑.net架構的安全性。
clr在il層次內(nèi)外影響代碼，對它的修改將使所有使用clr的語言受益。然而，語言只是和代碼如何被解釋為il有關，對特定語言的優(yōu)化可以根據(jù)特定語言的語法來編寫，這樣在技術上就可能使.net語言之間的性能差別很小。不管怎樣，大體上藍圖是美好的。例如，clr使vb的調(diào)試和監(jiān)測工具和c#的相應工具相當，它做到了這一點因為它們本來就是相同的工具。
clr提供不平行的跨語言集成，包括跨語言繼承代碼的能力。所有使用clr的語言共享一個通用類型系統(tǒng)，它使使用多種語言開發(fā)應用程序變得更簡單。我不喜歡把 c api 聲明翻譯成vb里可以使用的形式，所以我很贊賞通用類型系統(tǒng)帶來的好處。
在clr中運行的代碼被稱為被管理代碼，被管理代碼使用的內(nèi)存完全由clr來控制。被管理代碼帶來很多好處，包括跨語言集成、跨語言異常處理和簡化的部件相互作用模型。visual basic被限制為只能以被管理代碼的方式工作，然而c#擁有跳到非被管理代碼的能力(執(zhí)行到運行庫之外)，并能做像指針操作這類事情。這是vb和c#不同等的情況之一。這種能力到底有多重要取決于你想干什么。
clr造成的體系結構差別要比跨語言集成、共享功能和被管理代碼等深刻。首先，visual studio.net的支撐結構不是 com。另外，vb.net里的所有東西，甚至字符串都是對象。因為這些和其它一些原因，microsoft改變了支撐結構處理對象的方式。com實現(xiàn)了一個引用計數(shù)方案，這樣每次引用一個對象時，計數(shù)器遞增。當一個對象引用超出作用域或被釋放時，計數(shù)器遞減，當引用計數(shù)減少到零時就終止這個對象。microsoft聲稱在.net架構下引用計數(shù)的開銷太大，以至于不能在 .net中實現(xiàn)它，所以它放棄了引用計數(shù)轉(zhuǎn)而使用垃圾收集。
垃圾收集需要新體系結構
clr垃圾收集器主要是監(jiān)視一個程序的資源，當可用資源達到確定的閾值時尋找無用的對象，并在發(fā)現(xiàn)它們的時候清除這些對象。垃圾收集的一大好處就是你不再需要擔心大多數(shù)普通的循環(huán)引用，即子對象引用了父對象，然后父對象又引用了子對象。在引用計數(shù)方案下，循環(huán)引用使兩個對象都不能被釋放和清除。然而，垃圾收集器會發(fā)現(xiàn)循環(huán)引用并清除它們。這也意味著釋放對象的最后一個引用時不再需要立即清除對象。
垃圾收集的一個后果是：你再也不能指望一個類的 terminate 事件能在適當?shù)臅r機發(fā)出。實際上，如果線程被阻塞，可能根本就不會發(fā)出 terminate 事件。和com提供的確定化終止相反，它被稱為不確定的終止。缺乏確定化終止，以及因為垃圾收集器重新安排并壓縮內(nèi)存從而不能使用指針的事實，在新聞組里激發(fā)了一波激烈的辯論。我想這些新限制可能會令你痛恨，因為你要依靠確定化終止；也可能你漠不關心，因為你不依賴 terminate 事件。垃圾收集并不是萬靈藥，實現(xiàn)弱引用依然需要做一些考慮。
從引用計數(shù)到垃圾收集只是 visual studio.net 的支撐結構不是 com 這個事實的表象之一。你能在vb.net中使用com對象，比如說activex服務器或activex控件。然而，你必須通過包裝訪問這些對象。任何時候聽到“包裝”這個術語，你應該明白你面對著性能損失，并且對象的行為可能有所不同。如果當計劃移植一個使用了大量com對象的工程，就需要認真地測試和計劃，可能需要重新規(guī)劃應用程序的結構才能移植成功。坦率地說，你要有遭受挫折的準備。還記得從vbx遷移到 ocx的過程嗎？我記得，我的精神病醫(yī)生也記得。我很快就要再去看他了 ;-)
語言本身的變化要遠遠超過體系結構的變化。大部分改變確有道理，但我并不認為所有的改變都是如此。以前版本的vb允許你以很多方法來做很多事，以至于統(tǒng)一的編碼標準要么不存在要么就很難強加于人。microsoft對vb做了大量的改變?yōu)榈木褪恰扒逦边@種語言。很多情況下，原來你有好幾種方法做一件事，現(xiàn)在就只有一種了。billy hollis 提供了語法變化的詳細列表，包括廢棄的關鍵字列表，但有些東西需要在這里重復一下。
首先，向過程參數(shù)傳遞數(shù)據(jù)的默認方法由引用(byref)變成了傳值(byval)。這個改變主要是因為引用要比傳值的風險大得多。它的風險主要是調(diào)用過程中的數(shù)據(jù)可能被無意中篡改。你仍然能通過引用傳遞數(shù)據(jù)，但這一改變使你需要修改新的默認調(diào)用方法來使用引用。
set語句消失了
其次，set 語句消失了。在 vb.net 里如果你需要向變量傳遞一個對象引用，所需要的只是一個等號，對象被視為同其它值一樣。這很酷，但也有副作用：默認屬性消失了。例如，你不再能用這種方式引用一個屬性：
text1 = "what, me worry?"
作為替代，你必須顯式地引用屬性：
text1.text = "what, me worry?"
也許一眼看來不需要這種改變，但確實必須去掉默認屬性。例如，假定你有一個叫objfoo的對象變量，不用set語句，下面的語句所設置的引用就產(chǎn)生了歧義性：
objfoo = text1
這條語句是應該設置到text1的引用，還是以text1的text屬性來填充objfoo？你不能確定，編譯器也不能。拋棄set語句同時要求拋棄默認屬性。
有一個改變我不喜歡：你不再能在不同的作用域里聲明property get和property set過程。注意 vb.net 沒有 property let 語句：對象和數(shù)值都用 property set。這意味著你不能用一個 friend property let 過程來對應一個 public property get。用vb建立組件時可能會有麻煩。許多組件開發(fā)者創(chuàng)建 friend property set 過程以使他們的應用程序能改變一個值，但提供 public property get 過程以使他們的客戶程序能取回值。我希望我能為這個改變找到一個合適的理由，可是我找不到。
microsoft說它力圖使語言保持清晰并使之現(xiàn)代化—大部分情況下它做得不錯—但這個作用域問題和其它幾個問題令人感到困惑。例如，while...wend 很早以前就應該消失了，因為 do...loop 完成同樣的功能。然而，microsoft 不僅沒能去掉 while...wend，還把它改成了 while...end while 來給自己找了更多的麻煩。真奇怪！
我最不喜歡的改變是：microsoft改變了你已經(jīng)使用的數(shù)據(jù)類型含義。在 .net 里，integer 現(xiàn)在是 32 位，而 long 變成了 64 位。我心存恐懼地想：開發(fā)者 (包括我自己) 會多么頻繁地使用錯誤的變量啊。那個api到底是接受一個16位的 integer還是32位的？老天！我希望microsoft重新考慮這個決定并使用新的變量類型，比如int32和long64。無論遷移到 vb.net的移植工具是多么的好，它也不能改變開發(fā)者的記憶。為什么要逼著我們再學一遍普通的數(shù)據(jù)類型呢？
最后，最需要的一個改變是：vb.net引入了 option strict 關鍵字，你可以使用它來代替 option explicit。option strict 結束了萬惡的類型強制(tm)，通過它vb樂于讓你把一個數(shù)值賦值給一個字符串，然后像犯罪一樣做另一個操作。設置 option strict 告訴 visual basic.net 不要為你做任何類型強制。注意 vb.net 并不是徹底的控制狂，它允許類型向下轉(zhuǎn)換，但不允許向上。例如，不使用像 sngvariable = csng(dblvariable) 這樣的語句進行顯式類型轉(zhuǎn)換，你就不能把聲明為 single 的變量賦值給聲明為 double 的變量。因為這有丟失數(shù)據(jù)的風險。然而，你能不使用顯式類型轉(zhuǎn)換就把聲明為 double 的變量賦值給聲明為 single 的變量，因為這并沒有丟失數(shù)據(jù)的危險。使用 option strict 能幫助開發(fā)者減少很多類型錯誤，包括那些很難調(diào)錯的。但有一個附加的缺陷：在工程里使用了 option strict 后，就不能進行 后編聯(lián)了。
<<<<<上一頁：概要、vb獲得了繼承能力、一切都是對象、自由線程的危險
>>>>>下一頁：表單和新ide面孔、創(chuàng)建編譯的服務器端代碼、正確之路
