轉自:CSDN?? 自己做記錄? 大家不要砸磚頭 明年中旬研究這塊
什么是C++/CLI呢？C++當然指的是Bjarne Stroustrup在BELL實驗室發明的C++語言，它實現了運行時取得速度和尺寸最佳化的靜態對象模型，然而它除了堆分配外不支持程序的動態修改，它準許無限地接近底層設備，但在程序運行過程中幾乎無法操作活動類型，也無法操作與程序相關聯的底層結構。Herb Sutter，C++/CLI的主要構造者之一，稱C++是一門“混凝土”式的語言。
CLI指的是通用語言結構，一種支持動態組件編程模型的多重結構，在許多情況下，這代表了一個與C++對象模型完全顛倒了的模式。一個時實的軟件層，有效地執行系統，在底層操作系統與程序之間運行。操作底層的設備受到一定的限制，操作執行程序中的活動類型及與程序相關聯的下部結構得到了支持。反斜杠（/）代表C++和CLI的捆綁，這個捆綁帶來的細節問題是本文主要討論的問題。
所以，“什么是C++/CLI”問題的最初、最接近答案是：它是靜態C++對象模型到CLI的動態組件對象編程模型的捆綁。簡而言之，它就是你如何用C++在.NET中編程，而不是C#或Visual Basic.NET。象C#和CLI本身一樣，C++/CLI正在ECMA（歐洲計算機制造商協會）主持下進行標準化，以最終符合ISO標準。
實時通用語言（CLR）是CLI的微軟版本，它非常適用于微軟的Windows操作系統，相似地，Visual C++2005是C++/CLI的實現。
作為第二個近似的答案，我認為C++/CLI是.NET編程模式與C++的結合，正如以前將模板與C++結合起來產生的泛型編程。所有這種結合中，企業所擁有的C++的投資以及開發人員使用C++的經驗將得到保存，而這恰恰是使用C++/CLI進行開發的重要基礎。
閱讀導航
學習C++/CLI的方法
在設計C++/CLI語言中涉及三個方面問題，這同樣貫徹于所有的其他程序開發語言：一是語言級的語法向底層通用類型系統（簡稱CTS）的映射；二是向程序開發人員提供的CLI的底層細節結構的級別選擇；三是超越CLI的直接支持，提供額外的功能性函數的選擇。
從C++/CLI到CTS的映射？
使用C++/CLI編程時間了解底層的CTS非常重要。CTS包括以下三種常用類的類型：
1、多態引用類型，這正是對于所有繼承類所要使用的。
2、非多態值類型，這用于實時高效的具體類型，例如數值類型。
3、抽象的接口類型，這用于定義一個操作集，也可以用于實現接口的引用或值類型集合。
CLI的細節
設計一個CLI語言時第二個必須要考慮的問題是將CLI的底層執行模式融入到語言的細節級別。這種語言用于解決什么問題？這種語言是否有必須的工具來解決這些問題？這種語言可能吸引什么樣的程序開發人員？
存在的問題
在垃圾收集器掃描緊縮狀態下，位于托管堆上的任何對象非常可能面對重新定位問題。指向對象的指針可以實時跟蹤并修改。開發人員不能自己手動跟蹤，所以，如果你獲許取得一個可能位于托管堆上的值類型的地址時，除了本地指針外，還需要有一個跟蹤形態的指針。
額外增加的功能
在垃圾收集器掃描緊縮狀態下，位于托管堆上的任何對象非常可能面對重新定位問題。指向對象的指針可以實時跟蹤并修改。開發人員不能自己手動跟蹤，所以，如果你獲許取得一個可能位于托管堆上的值類型的地址時，除了本地指針外，還需要有一個跟蹤形態的指針。
小結
C++/CLI代表托管與本地編程的結合，這種綜合已經通過元級相對獨立但又相互平等地組件和二進制元素得到了完成，包括混合模式（本地和CTS類型的元級混合，還有一個本地及CLI對象文件的二進制混合），純模式（本地和CTS類型的源代碼級混合，所有的都被編譯為CLI對象文件），本地分類（可以通過一個特定的打包類來保持CTS類型），和CTS分類（可以保持本地類型為指針）。
當然，C++/CLI開發人員也可以單獨使用CLI類型來編程，并通過這種方式來提供伺服狀態下的可校驗代碼，例如可以作為SQL Server2005的一個SQL存儲過程。
現在，還是回到這個問題上來，什么是C++/CLI？它是進行.NET編程模式的最佳切入點。對于C++/CLI，有一個來自C++的遷移路徑，它不僅包含C++的底層基礎，而且也需要C++編程經驗，對于這些，我感到非常滿意。
學習C++/CLI的方法
在設計C++/CLI語言中涉及三個方面問題，這同樣貫徹于所有的其他程序開發語言：一是語言級的語法向底層通用類型系統（簡稱CTS）的映射；二是向程序開發人員提供的CLI的底層細節結構的級別選擇；三是超越CLI的直接支持，提供額外的功能性函數的選擇。
第一條對于所有的CLI語言來說都大致相同，第二條和第三條對于不同的CLI語言來說是不同的，相互區別的。根據你需要解決什么樣的問題，你將選擇這種或那種語言，也有可能混合使用多種CLI語言。學習C++/CLI涉及到了解它在設計過程中的所有這些涉及方面。
從C++/CLI到CTS的映射？
使用C++/CLI編程時間了解底層的CTS非常重要。CTS包括以下三種常用類的類型：
1、多態引用類型，這正是對于所有繼承類所要使用的。
2、非多態值類型，這用于實時高效的具體類型，例如數值類型。
3、抽象的接口類型，這用于定義一個操作集，也可以用于實現接口的引用或值類型集合。
這個設計方面的問題，即將CTS映射到語言內建的數據類型集合，通常同樣貫穿于所有的CLI語言，雖然不同的CLI語言語法不同。所以，在C#中你可能這么寫：
abstract class Shape { ... } // C#
來定義了一個Shape基類，從該類將導出幾何對象，然而在C++/CLI你將這么寫：
ref class Shape abstract { ... }; // C++/CLI
上述代碼說明了底層的C++/CLI引用類型。這兩種聲明在內層代表的意思是一樣的。相似地，在C#中你這么寫：
struct Point2D { ... } // C#
來定義一個具體的Point2D 類，然而在C++/CLI中這么寫：
value class Point2D { ... }; // C++/CLI
C++/CLI支持的類型集合代表了CTS與本地設備的綜合，這決定了你的語法選擇，例如：
class native {};
value class V {};
ref class R {};
interface class I {};
CTS也支持與本地列舉類型稍微不同的列舉類類型。當然，對于上述兩者CTS是都支持的。例如：
enum native { fail, pass };
enum class CLIEnum : char { fail, pass};
相似地，CTS支持它本身的數組類型，并且它再一次將其與本地數組在行為上區分開來。同時，微軟再次為這兩種類型提供了支持。
int native[] = { 1,1,2,3,5,8 };
array<int>^ managed = { 1,1,2,3,5,8 };
那種認為一種CLI語言比其他CLI語言在向底層的CTS映射中表現的更出色或更完美都是不確切的，相反，每種不同的CLI語言代表著對CTS底層對象模型的不同理解，在下一節你將更清楚地看到這一點。
CLI的細節
設計一個CLI語言時第二個必須要考慮的問題是將CLI的底層執行模式融入到語言的細節級別。這種語言用于解決什么問題？這種語言是否有必須的工具來解決這些問題？這種語言可能吸引什么樣的程序開發人員？
例如，值類型存在于托管堆上，在很多情況下值類型可以看到它們自身的存在。
1、通過隱含的加箱操作，當一個值類型的實例被分配給一個對象或當一個虛擬的方法通過一個值類型來調用；
2、當這個值類型被當作應用引用類類型的成員時；
3、當這個值類型 被當作CLI數組成員時；
需要指出的是，這種情況下開發人員是否被允許操作值類型的地址是CLI語言設計時必須應該予以考慮的問題。
存在的問題
在垃圾收集器掃描緊縮狀態下，位于托管堆上的任何對象非常可能面對重新定位問題。指向對象的指針可以實時跟蹤并修改。開發人員不能自己手動跟蹤，所以，如果你獲許取得一個可能位于托管堆上的值類型的地址時，除了本地指針外，還需要有一個跟蹤形態的指針。
銷售商考慮的是什么？那就是需要簡單和安全，在語言中直接提供跟蹤一個對象或集合的指針使語言復雜化，沒有這種支持，將減少復雜程度，可資利用的、潛在的程序開發人群可能會增加，此外，準許程序開發人員操作生命短暫的值類型，增加了錯誤產生的可能性，程序開發人員可能有意無意地對內存進行錯誤操作，不支持跟蹤指針，一個潛在的更安全地實時環境產生了。
另一方面，效率和靈活性也是必須考慮的一個問題，每一次向同一個對象分配值類型時，一個全新的數值加箱操作發生了，準許存取加箱值類型允許在內存中進行更新，這可能在性能上產生了一個非常巨大的進步。沒有跟蹤形態的指針，你無法用指針算法重新聲明一個CLI數組，這意味著CLI數組不能使用標準模板庫進行重新聲明，也不能使用一般的算法。準許操作加箱數值使設計具有更大地靈活性。
微軟在C++/CLI中選擇地址集合模式來處理托管堆上的值類型。
int ival = 1024;
int^ boxedi = ival;
array<int>^ ia = gcnew array<int>{1,1,2,3,5,8};
interior_ptr<int> begin = &ia[0];
value struct smallInt { int m_ival; ... } si;
pin_ptr<int> ppi = &si.m_ival;
典型地C++/CLI開發人員是一個復雜的系統程序員，承擔著提供下層內部構造和有組織的應用程序的任務，而這些恰恰是未來商業發展的基礎。C++/CLI開發人員必須兼顧可測量性和可執行性，所以必須在系統的高度級上來看待CLI下層結構。CLI細節水平反映了開發人員的臉色。
復雜性本身并不代表對質量的否定，人類比單細胞細菌復雜的多，這當然不是一件壞事，然而，當表達一個簡單的概念變的復雜化后，這常常被認為是一件壞事。在C++/CLI中，CLI開發團隊已經試著提供一種精巧的方法來表達方式一個復雜的事情。
額外增加的功能
第三個設計方面是特定功能性的語言層，它遠遠超過CLI所提供的直接支持，雖然這可能需要在語言層支持和CLI底層執行模式間建立一個映射。但在某些情況下，這恰恰是不可能的，因為語言無法調節CLI的行為。這種情況的例子就是在基類的構造及析構函數中定義虛函數。根據ISO-C++在這種情況下的語言學，需要用每一個基類的構造和虛構函數重新設置虛擬表，而這是不可能的，因為虛擬表句柄是實時管理的，而不是某一個語言來管理。
所以，這個設計方面是在完美性和可行性之間的妥協產物，C++/CLI提供的額外功能主要表現在三個方面：
1、獲取資源的一種形式是對于引用類型的初始化，此外，提供一種自動化工具，用于占用較少資源、所謂的可確定性自動消亡的垃圾收集類型對象。
2、一種深度拷貝形式的語法與C++拷貝構造函數和拷貝分配操作符相一致，但其并不適用與值類型。
3、除了最初的一般性CLI機制外，還有對于CTS類型的C++模板直接支持。這些是我第一篇文章中討論的主題。此外，還提供了針對CLI類型的可校驗STL版本。
讓我們來看一個簡單的例子，一個確定性消亡問題。在垃圾搜集器重新聲明一塊與對象相關聯的內存之前，一個相關的消亡方法，如果存在的話，將被調用。你可以認為這種方法是超級析構函數，因為它與對象的程序生命期無關。這就叫做終結。終結函數是否調用以及什么時間調用都沒有明確規定，這就是垃圾收集器的非確定性終結。
在動態內存管理的情況下，非確定性終結工作非常好，當可用內存變的越來越少時，垃圾收集器介入并開始著手解決問題。然而，非決定性終結也有工作不好的時候，當一個對象維護一個重要資源，例如一個數據庫連接、鎖定某些類別、或者可能是本地的堆內存。在這種情況下，只要是不需要，應立即釋放資源。目前CLI所支持的解決問題的方法是，對于一個類通過執行IDisposable接口提供的Dispose方法釋放資源。這里的問題是執行Dispose方法需要一個清晰的聲明，所以它也就不可能存在調用。
最基本的C++中的設計模式是上述的通過初始化來獲取資源，這意味著類使用構造函數來獲取資源，相反，類使用析構函數來釋放資源。這些行為由類對象在生存期內自動管理。
下面是引用類釋放資源時所做的順序動作：
1、 首先使用析構函數來封裝所有與釋放類有關的資源時所必須的代碼；
2、 析構函數自動調用后，結束類對象的生命期。
對于引用類型來說，CLI沒有類析構函數的概念，所以析構函數不得不映射為在底層執行的其它代碼。此時，在內部，編譯器執行以下操作：
1、 類讓其基類列表繼承自IDisposable接口；
2、 析構函數轉換成IDisposable的Dispose方法。
以上實現了目標的一半，一種實現析構造函數自動調用的方法仍然需要，對于引用類型，一種特殊的基于棧的符號得到支持，也就是說，一個對象的生命期與它的聲明范圍有關。在內部，編譯器將符號轉換為在托管堆上分配引用對象。隨著作用域的終結，編譯器插入一個Dispose方法-用戶定義的析構函數。與對象有關的內存的收回在垃圾收集器的控制下得到執行。
C++/CLI并不是將C++拓展到一個托管的世界，更確切的說，它代表一個完全綜合的范例，某種程度上就象當初將泛編程模式和多重繼承綜合進該語言一樣。我認為C++/CLI開發小組做了一項非常卓有成效的工作。
小結
C++/CLI代表托管和本地編程的結合。在反復過程中，這種綜合已經通過源級相對獨立但又相互平等地組件和二進制元素得到了完成，包括混合模式（本地和CTS類型的源級混合，還有一個本地及CLI對象文件的二進制混合），純模式（本地和CTS類型的源代碼級混合，所有的都被編譯為CLI對象文件），本地分類（可以通過一個特定的打包類來保持CTS類型），和CTS分類（可以保持本地類型為指針）。
當然，C++/CLI開發人員也可以單獨使用CLI類型來編程，并通過這種方式來提供伺服狀態下的可校驗代碼，例如可以作為SQL Server2005的一個SQL存儲過程。
現在，還是回到這個問題上來，什么是C++/CLI？它是進行.NET編程模式的最佳切入點。對于C++/CLI，有一個來自C++的遷移路徑，它不僅包含C++的底層基礎，而且也需要C++編程經驗，對于這些，我感到非常滿意。