-- 作者:wangxinxin
-- 發布時間:2010-12-10 15:10:38
-- C++:最強大的.NET語言之內存與資源
【IT168技術文檔】
當運行環境中包含垃圾回收機制時,區別開內存管理和資源管理,就非常重要了。典型地來說,垃圾回收器只對包含對象的內存之分配與釋放感興趣,它可不關心你的對象是否擁有其他的資源,如數據庫連接或核心對象的句柄。
內存管理
本地C++為程序員提供了超越內存管理的直接控制能力,在堆棧上分配一個對象,意味著只有在進入特定函數時,才會為對象分配內存,而當函數返回或堆棧展開時,內存被釋放。可使用操作符new來動態地為對象分配內存,此時內存分配在CRT堆中,并且需要程序員顯存地對對象指針使用操作符delete,才能釋放它。這種對內存的精確控制,也是C++可用于編寫極度高效的程序的原因之一,但如果程序員不小心,這也是內存泄漏的原因。另一方面,你不需要求助于垃圾回收器來避免內存泄漏--實際上這是CLR所采取的方法,而且是一個非常有效的方法,當然,對于垃圾回收堆,也有其他一些好處,如改進的分配效率及引用位置相關的優勢。所有這一切,都可以在C++中通過庫支持來實現,但除此之處,CLR還提供了一個單一的內存管理編程模型,其對所有的編程語言都是通用的,想一想與C++中COM自動化對象相交互和調度數據類型所需做的一切工作,就會發現其重要意義所在--橫跨數種編程語言的垃圾回收器,作用是非常巨大的。
為了效率,CLR也保留了堆棧的概念,以便值類型可在其上分配,但CLR也提供了一個newobj中間語言指令,以在托管堆中分配一個對象,但此指令只在C#中對引用對象使用操作符new時提供。在CLR中,沒有與C++中的delete操作符對應的函數,當應用程序不再引用某對象時,分配的內存最后將由垃圾回收器回收。
當操作符new應用于引用類型時,托管C++也會生成newobj指令,當然,對此使用delete操作符是不合法的。這確實是一個矛盾,但同時也證明了為什么用C++指針概念來表示一個引用類型不是一個好的做法。
在內存管理方面,除了上述在對象構造一節討論過的內容,C++/CLI沒有提供任何新的東西;資源管理,才是C++/CLI的拿手好戲。
資源管理
CLR只有在資源管理方面,才能勝過本地C++。Bjarne Stroustrup的"資源獲取即初始化"的技術觀點,基本定義了資源類型的模式,即類的構造函數獲取資源,析構函數釋放資源。這些類型是被當作堆棧上的局部對象,或復雜類型中的成員,其析構函數自動釋放先前分配的資源。一如Stroustrup所言"對垃圾回收機制來說,C++是最好的語言,主要是因為它生成很少的垃圾。"
也許有一點令人驚訝,CLR并沒有對資源管理提供任何顯式運行時支持,CLR不支持類似析構函數的C++概念,而是在 .NET Framework中,把資源管理這種模式,提升到一個IDisposable核心接口類型的中心位置。這種想法源自包裝資源的類型,理應實現此接口的單一Dispose方法,以便調用者在不再使用資源時,可調用該方法。不必說,C++程序員會認為這是時代的倒退,因為他們習慣于編寫那些缺省狀態下清理就是正確的代碼。
因為必須要調用一個方法來釋放資源,由此帶來的問題是,現在更難編寫"全無異常"的代碼了。因為異常隨時都可能發生,你不可能只是簡單地在一段代碼后,放置一個對對象的Dispose方法的調用,這樣做的話,就必須要冒資源泄漏的風險。在C#中解決這個問題的辦法是,使用try-finally塊和using語句,在面對異常時,可提供一個更可靠的辦法來調用Dispose方法。有時,構造函數也會使用這種方法,但一般的情況是,你必須要記住手工編寫它們,如果忘記了,生成的代碼可能會存在一個悄無聲息的錯誤。對缺乏真正析構函數的語言來說,是否需要try-finally塊和using語句,還有待論證。
對托管C++來說,情節也非常類似,也需要使用一個try-finally語句,但其是Microsoft對C++的擴展。雖然很容易編寫一個簡單的Using模板類來包裝GCHandle,并在模板類的析構函數中調用托管對象的Dispose方法,但托管C++中依然沒有C# using語句的對等物。
|