是否存在不繼承自System.Object類型的類

標籤：使用   strong   檔案   問題   代碼   c++   .net   設計   

分析問題

　　可能讀者的固有思維認為.NET中所有的類型都必須繼承自System.Object，這樣的認識過於絕對，且不完全正確。在.NET中，.NET設計小組為中繼語言的編譯器ILasm.exe添加了noautoinherit開關，當這個開關被開啟時，編譯器將不會預設年地把類型認為繼承自System.Object。

　　首先介紹一下中繼語言的編譯工具：ILasm.exe。這是.NET Framework提供的一個編譯工具，它的作用是把中繼語言（MSIL）編譯成可執行檔PE檔案。該工具非常有用，它不僅使程式員有機會能夠直接編寫中繼語言並且編譯成PE檔案，而且提供了另外一種部署方式，即手動地編譯所有的中間代碼並且直接部署最終的機器代碼。

　　如果程式員用的開發語言是C#，則在編譯成中繼語言時，類型已經被預設地添加了繼承自System.Object的代碼，這時候無論是否為ILasm.exe開啟noautoinherit開關，產生的類型都將繼承自System.Object，但如果程式員手動地編寫了不繼承自System.Object類型的中間代碼，並且使用noautoinherit開關，則會產生一個特別的無父類的類型。

　　在全託管單語言的編程環境下，設計不繼承自System.Object的類型不會帶來任何好處，相反地，它會導致種種違反常規的運行錯誤。不繼承自System.Object的類型不符合CLS的規範，並且在正常的程式中出現意外的異常。但是為了融合其他程式設計語言（比如C++/CLI），這樣的內建機制有著其獨特的作用。在通常情況下，讀者不需要也不應該建立不繼承自System.Object的類型，但需要注意的是，在特殊的環境下任何代碼不能作出物件類型繼承自System.Object的保證，甚至於不能相信as、is等類型檢查文法的結果。程式員唯一可以並且必須做得就是：時刻準備著捕捉各種意料之外的異常。

答案

　　通過運用ILasm.exe的noautoinherit開關，可以產生不從System.Object繼承的類型，這種類型不是安全的類型，也不建議使用。但是，這樣機制的存在，促使程式員在編寫代碼時不能隨意地把任何對象預設地看成System.Object的子類類型。