top
Loading...
無用單元的收集

CLR中的無用單元收集程序監控一個軟件的資源,一旦系統中的可用資源減少到了一個極限,發現無用的對象后就會消滅它。無用單元的收集帶來的一個好處是你無需擔心最常見的循環調用問題,在一個循環調用中,子對象調用父對象,而父對象又調用了子對象。在一個調用調度系統中,循環調用可能使任一對象都不能被釋放或消滅,而無用單元收集程序則可以發現這種循環調用,并消滅它,這也意味著釋放最近對一個對象的調用無需立即消滅這個對象。

無用單元收集帶來的后果是:我們無須再依賴于一個類的Terminate事件。事實上,如果線程被阻塞了,Terminate事件也不可能得到執行,這也就是所謂的不確定性終止,與它相對的是由COM提供的確定性終止。確定性終止的缺乏和由于無用單元收集而引起的對內存單元的重新調度和緊湊在互聯網上的新聞組中引起了熱烈的討論。我認為這些限制會引起你的不快,因為你已經習慣了確定性終止,也許你并不依賴于Terminate事件而認為這無關緊要。無用單元收集程序并非是萬能的,在使用時仍然會有許多限制。

從引用計數到無用單元收集只是說明Visual Studio.NET的基礎架構不再是COM的一部分。在VB.NET中,你仍然可以使用ActiveX服務器、ActiveX控制等COM對象,但必須通過適當的"wrapper"才行。提到"wrapper"這個詞,就可能意味著性能上的折扣和執行上的差異。如果要移植一個使用了大量的COM對象的軟件,就需要進行很好的測試和規劃,甚至重新設計部分代碼才能確保移植成功。坦率地說,你會遇上挫折,還記得把VBX向OCX移植的惡夢嗎?

在開發語言中的變化還不僅僅局限于架構的變化,這些變化中的大多數都有積極的意義,但我認為并非所有這些變化都是積極的。在過去的VB版本中,你可以用多種不同的方法來完成同一件任務,既沒有統一的編碼標準也無法執行這么一個標準。微軟對VB進行了一些比較顯著的改變,以便"凈化"這種語言,在大多數情況下,你只有一種方法可以完成某一任務。

首先,向過程的參數傳遞數據的缺省方法由傳遞地址(ByRef)改成了傳遞數值(ByVal),這是其中變化最大的部分,原因是向參數傳遞地址要比傳遞數值的風險要大得多,這種風險主要來自調用過程可能在無意間改變參數。當然還可以用地址傳送參數,但必須改變新的缺省的調用方法。

其次,拋棄了Set語句。把一個對象的地址傳遞給一個變量只要用一個等號就可以了,對象與其他的數據類型沒有什么區別。這看起來很"酷",但也有一定的負作用:缺省的屬性不能用了。例如,再不能用下面的方式來引用一個屬性了:

Text1 = "What, me worry?"

而必須使用如下的方式:

Text1.Text = "What, me worry?"

初一看這似乎是一個不必要的變化,但必須拋棄缺省的屬性了。例如,假設有一個被稱作objFoo的對象變量,不使用Set語句,我們就不清楚這個語句引用了什么:

objFoo = Text1

這個語句引用的是Text1變量呢還是Text1變量的值的Text屬性呢?我們不能確定這一點,編譯器也不能。因此,不要Set語句也就必須拋棄缺省屬性。

一個我所不喜歡的變化:不能再使用不同的范圍定義Property Get、Property Set過程。VB.NET中沒有了Property Let語句:對于對象和變量時都使用Property Set語句,這就意味著不能再使用一個與Public Property Get一塊兒使用的Friend Property Let過程。如果你是用VB創建組件的話可就有麻煩了,許多組件開發人員創建組件時使用了Friend Property Set過程,這樣應用軟件就能改變一個變量,只有使用Public Property Get過程客戶才能存取變量。我一直希望能為這種變化找一個可以接受的理由,但我找不出來。

微軟表示將使VB實現"現代化",它在許多方面都做得很好,但仍然有一些問題使我感到困惑。例如,While...Wend語句很早以前就應該取消了,因為Do...Loop語句就可以完成相應的功能,微軟并沒有拋棄While...Wend,而是將它令人困惑地改成了While... End語句。

我最不喜歡的變化是:微軟改變了我們已經習慣了的數據類型的含意。在.NET中,Integer類型的數據是32位的,Long型數據是64位的,我不敢想象開發人員會在使用變量時出什么樣的錯誤,API調用的是16位的整數還是32位的整數呢?天呀!我希望微軟能重新考慮這個決定。創建一些新的變量類型,例如Int32和Long64。難道微軟會強迫我們重新學習常見的數據類型?

一個最需要的變化:VB.NET引入了Option Strict關健字,在可以使用Option Explicit的地方就可以使用它。Option Strict語句取代了Evil Type Coercion(tm),這個語句可以使一個數字轉換為一個字符串或完成其他的數據類型轉換任務,Setting Option Strict可以讓Visual Basic.NET不完成任何強制類型轉換。請注意VB.NET并不能完全控制數據類型的轉換,它只能向"下"而不能向"上"轉換數據類型。例如,如果不使用一個語句明確地指出,就不能將一個定義為Single類型的變量的值賦給一個Double類型的變量,否則就有丟失數據的危險。但是,可以把Double類型變量的值設定為一個Single變量的值而不會有丟失數據的危險。Option Strict可以使開發人員減少許多數據類型方面的錯誤,包括許多極難調試的錯誤。另外還有一點需要提醒你:如果在一個項目中使用了Option Strict,就不能再完成后聯編了。

 

易于反編譯的中間語言
窗體和新的IDE

作者:http://www.zhujiangroad.com
來源:http://www.zhujiangroad.com
北斗有巢氏 有巢氏北斗