C++/CLI

C++/CLI

“C++/CLI”是靜態C++對象模型到CLI的動態組件對象編程模型的捆綁。簡而言之就是如何用C++在·NET中編程,而不是C#或Visual Basic。像C#和CLI本身一樣,C++/CLI正在ECMA(歐洲計算機製造商協會)主持下進行標準化,以最終符合ISO標準。公共語言運行時(CLR)是CLI的微軟版本,它非常適用於微軟的Windows作業系統,相似地,Visual C++2005是C++/CLI的實現。

基本介紹

  • 中文名:C++/CLI
  • 概述 :“C++/CLI”是靜態C++對
  • 相關定義:C++指的是Bjarne Strou
  • 歷史:2003年10月6日,ECMA
相關定義,發展歷史,設計目標,語言學習,語言前景,語法特點,

相關定義

C++指的是Bjarne Stroustrup在BELL實驗室發明的C++語言,它實現了運行時取得速度和尺寸最佳化的靜態對象模型,然而它除了堆分配外不支持程式的動態修改,它準許無限地接近底層設備,但在程式運行過程中幾乎無法操作活動類型,也無法操作與程式相關聯的底層結構。Herb Sutter,C++/CLI的主要構造者之一,稱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++編程經驗。

發展歷史

2003年10月6日,ECMA(歐洲計算機製造商協會)公布成立專家組,負責結合ISO標準C++與通用語言,開發一個可擴展語言的標準,這個新的可擴展語言被稱為C++/CLI標準。
C++/CLI標準是基於Microsoft提交的標準C++與通用語言基礎結構(Common Language Infrastructure)結合的技術。ECMA技術委員會為其建立了語言標準、類庫和運行環境標準,最新的版本是ECMA-335,2005年6月的第三版。

設計目標

(ECMA 2003年12月)
⒈ 為C++程式設計師提供使他們感到自然的優美、統一的語法和語義。
⒉ 為CLI特性提供一流的包括全部現存標準C++類的類型支持。
⒊ 為標準C++特性提供一流的包括全部CLI類的類型支持。
⒋ 無論在任何地方明確說明是(標準C++的)擴展,保留現存標準C++程式的重要性。

語言學習

學習方法
在設計C++/CLI語言中涉及三個方面問題,這同樣貫徹於所有的其他程式開發語言:一是語言級的語法向底層通用類型系統(簡稱CTS)的映射;二是向程式開發人員提供的CLI的底層細節結構的級別選擇;三是超越CLI的直接支持,提供額外的功能性函式的選擇。
第一條對於所有的CLI語言來說都大致相同,第二條和第三條對於不同的CLI語言來說是不同的,相互區別的。根據你需要解決什麼樣的問題,你將選擇這種或那種語言,也有可能混合使用多種CLI語言。學習C++/CLI涉及到了解它在設計過程中的所有這些涉及方面。
學習教程
⒈ Visual C++ 2008 大學教程(第二版)(英文原版:Visual C++ 2008 How to Program,Second Edition)
⒉ Visual C++ 2008入門經典 (英文原版:Beginning Visual C++ 2008)
⒊ C++/CLI in Action
⒋ Foundations of C++/CLI The Visual C++ Language for .NET 3.5
⒌ Pro Visual C++/CLI and the .NET 3.5 Platform
⒍ Expert C++/CLI:.NET for Visual C++ Programmers
從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的初衷是為C++程式設計師轉向.NET平台,但隨著C++/CLI的不斷發展和Microsoft VC++ Team的不懈努力,C++/CLI存在的意義也在不斷發生著變化。Stan Lippman說:“我們希望它能變成.NET平台上的系統程式語言。就是說,它可以用來開發那些驅動一切的程式。你不可能用C#來寫.NET驅動程式,也不能用C#來寫C#編譯器,起碼現在不行,但你可以用C++/CLI做到。你可以在C++/CLI上達到最高的效率和最大的能力,因為我們對於CLI模型的整合更為完整深入。”現在,C++/CLI是作為一座連線過去與未來的橋樑(C++與.NET,現存代碼與未來趨勢)存在,未來,也許如Stan所說,C++/CLI的定位會作為.NET平台中最接近底層的語言來發展。
C++/CLI是新生事物,由於Microsoft VC++ Team精力有限,直到VS2010版本發布,Microsoft一直沒有能夠使C++/CLI支持.NET框架的新特性,如WPF、LINQ等,甚至在最新版本的VS2010中,被Microsoft力推的新智慧型感知系統也不支持C++/CLI。Microsoft Visual C++ Team認為,C++/CLI最大的特點在於Interop,所以大部分精力都用於改進Interop,而不是使C++/CLI成為一種純粹的.NET開發語言。雖然很遺憾,但C++/CLI還是可以通過Interop方便地使用.NET的全部特性。此外,開發小組還承諾在之後的版本中推出“可以使人振奮的C++/CLI特性”,以及使其支持.NET新特性和新的智慧型感知系統。
以目前的情況來說,C++/CLI的發展進度確實令人有些許失望。

語法特點

C++/CLICLI:Common Language Infrastructure)是一門用來代替C++託管擴展(下文使用MC++指代)新的語言規範。重新簡化了C++託管擴展的語法,提供了更好的代碼可讀性。和微軟.NET的其他語言一樣,微軟向ECMA提交了C++/CLI的標準。C++/CLI現在可以在Visual C++ 2005上開發。C++/CLI的部分特性已經申請了專利。
1 語法改變
C++/CLI是一門獨立的語言(比如新的關鍵字),而不是像C++託管擴展一樣是C++的超集 (C++託管擴展有一些不標誌的關鍵字如__gc和__value)。所以,C++/CLI對於這些語法有較大的改變,尤其是去除了一些意義不明確的關鍵字,增加了一些.NET的特性.
很多不一致的語法,像MC++的不同版本用法的操作符new()被區分開:在C++/CLI,.NET引用類型的創建要使用新的關鍵字gcnew。並且C++/CLI增加了新的泛型概念(與C++ templates相似,但還是有很大的區別)。
回到MC++,有兩類指針: 用__nogc標識的指針是傳統意義上的C++指針,而用__gc標識的指針為.NET中的引用。但在C++/CLI里,唯一的指針就是傳統意義上的C++指針,而.NET引用類型使用一個“句柄”來獲取,使用新的語法“類名^”代替了MC++的“類名*”。新的句法使得託管和非託管代碼混合開發更加方便;它指明了對象將會被垃圾回收器自動銷毀還是手動銷毀。
範例代碼:
// C++託管擴展
#using <mscorlib.dll>
using namespace System::Collections;
__gc class referencetype
{
protected:
String* stringVar;
int intArr __gc[];
ArrayList* doubleList;
public:
referencetype(String* str,int* pointer,int number) // 哪個是託管的?
{
doubleList = new ArrayList();
System::Console::WriteLine(str->Trim() + number.ToString());
}
};
// C++/CLI
#using <mscorlib.dll>
using namespace System::Collections::Generic;
ref class referencetype
{
protected:
String^ stringVar;
array<int> intArr;
List<double>^ doubleList;
public:
referencetype(String^ str,int* pointer,int number) // 不會再分不清了吧?
{
doubleList = gcnew List<double>();
System::Console::WriteLine(str->Trim() + number);
}
};
⒈2 跟蹤引用(Tracking reference)
C++/CLI里的一個“跟蹤引用”也是一個句柄,但它是傳地址而不是傳值。等同於在C#中加了“ref”關鍵字,或Visual Basic .NET的“ByRef”。C++/CLI使用“^%”語法來定義一個跟蹤引用。與傳統C++中的“*&;”語法相似。
下面的示例了“跟蹤引用”的使用。如果把“^%”改成“^”(也就是使用普通的句柄),10個字元串將不會被修改,而只會生成那些字元串的副本,這些都是因為那些引用已經不是傳地址而是傳值。
int main()
{
array<String^>^ arr = gcnew array<String^>;⑽;
int i = 0;
for each(String^% s in arr)
s = gcnew String(i++.ToString());
return 0;
}
上面的代碼示例了用戶如何用C++/CLI做一些其他.NET語言不能做的事情,比如C#就不允許在foreach循環中這樣做。例如foreach(ref string s in arr)在C#中是非法的。
⒈3 析構(Finalizer/Destructor)
C++/CLI的另一個變化就是使用“!類名()”來聲明一個託管類型的“析構方法”(在垃圾回收器回收對象之前的不確定的時間由CLR調用),而原來的“~類名()”是用來定義“傳統的析構函式”(能被用戶自己調用)。另外,下面的例子說明了如何在C++/CLI中託管對象如何自動調用“傳統析構函式”。
在一個典型的.NET程式中(例如直接使用CIL)編程,可以由用戶自己調用的“析構方法”是用實現IDisposable接口,通過編寫Dispose方法來實現顯式釋放資源;而不確定的“析構方法”是通過重載Finalize函式來實現的。
// C++/CLI
ref class MyClass // :IDisposable (編譯器自動實現IDisposable接口)
{
public:
MyClass(); // 構造函式
~MyClass(); // (確定的) 析構函式 (編譯器使用IDisposable.Dispose來實現)
protected:
!MyClass(); // 析構方法 (不確定的) (編譯器通過重載virtual void Finalize來實現)
public:
static void Test()
{
MyClass auto; // 這不是個句柄,它將調用MyClass的默認構造函式
// 使用auto對象
// 函式返回前自動調用auto的析構函式(IDisposable.Dispose,由~MyClass()定義)來釋放資源
// 以上代碼等效於:
MyClass^ user = gcnew MyClass();
try { /* 使用auto對象 */ }
finally { delete user; /* 由編譯器調用auto.Dispose() */ }
}
};
// C#
class MyClass : IDisposable
{
public MyClass() {} // 構造函式
~MyClass() {} // 析構方法 (不確定的) (編譯器通過重載virtual void Finalize來實現),與C++/CLI的!MyClass()等效
public void Dispose() {} // Dispose方法
public static void Test()
{
using(MyClass auto = new MyClass())
{ /* 使用auto對象 */ }
// 因為使用了using句法,編譯器自動調用auto.Dispose()
// 以上代碼等效於:
MyClass user = new MyClass();
try { /* 使用user對象 */ }
finally { user.Dispose(); }
}
}

相關詞條

熱門詞條

聯絡我們