發(fā)布日期： 11/26/2004 | 更新日期： 11/26/2004
Kate Gregory
Gregory Consulting
適用于：
Microsoft Visual C++
Microsoft.NET 公共語言運(yùn)行庫 (CLR)
C++/CLI 擴(kuò)展
Microsoft .NET Framework
WinFX
摘要： 本文針對（至少到目前為止）在新的和現(xiàn)有的應(yīng)用程序中還沒有以Microsoft .NET Framework 為目標(biāo)開發(fā)平臺的 C++ 程序員。 文中為如何轉(zhuǎn)向 .NET Framework 而且避免拋棄現(xiàn)有代碼中的投資提供了一些指導(dǎo)，并闡述了為什么應(yīng)該考慮轉(zhuǎn)向 .NET Framework ，這不僅適用于新的開發(fā)工作，對現(xiàn)有應(yīng)用程序亦然。
本頁內(nèi)容
為什么要使用公共語言運(yùn)行庫？
Microsoft 總是支持程序員從他們自己的代碼中訪問操作系統(tǒng)功能。 在 Windows 的早期，我們從 C 語言程序中使用 Windows API ，進(jìn)行函數(shù)調(diào)用（比如 GetMessage(), TranslateMessage(), 等等）以達(dá)到目的。 隨著時(shí)間變遷， Windows 功能開始使用 COM 組件比如 Shell 來公開。 為了充分利用 Windows 完整的功能，程序員學(xué)會了 COM 的概念，創(chuàng)建了許多 COM 應(yīng)用程序。 這種演變?nèi)栽诶^續(xù)，如今，為了充分發(fā)揮 WinFX 的功能，你的應(yīng)用程序應(yīng)該使用公共語言運(yùn)行庫，也稱 CLR 了。 WinFX 是一種托管 API ，設(shè)計(jì)成從為 CLR 編寫的托管應(yīng)用程序中調(diào)用，通過 WinFX ，你的應(yīng)用程序能夠利用 Avalon 和 Indigo 這樣的新技術(shù)的功能。 WinFX 是基于 .NET 對象模型的。
訪問操作系統(tǒng)功能當(dāng)然不是 CLR 的唯一優(yōu)勢： .NET Framework 提供了比 COM 和 DCOM 更佳而且更簡單的組件模型。 .NET Framework 中包含的托管代碼庫所能提供的功能，遠(yuǎn)遠(yuǎn)超出了操作系統(tǒng)本身，這使我們能夠?qū)⒕Ψ旁趹?yīng)用程序中專門解決特定問題的部分，而用不著再去處理許多人已經(jīng)解決過的問題。 同樣，可以構(gòu)建一個(gè)基于組件的解決方案，而不需涉及以前與 COM 和 DCOM 部署相關(guān)的那些困難。
相關(guān)語言回顧
這是否意味著你應(yīng)該重新編寫所有應(yīng)用程序呢？ 當(dāng)然不是。 如果原來的應(yīng)用程序是用 C++ 編寫的，現(xiàn)在不對代碼做任何改變就可以針對 CLR 進(jìn)行編譯。 重新編寫會帶來巨大風(fēng)險(xiǎn)，因?yàn)樵趯⒊绦蛞浦驳搅硪环N語言比如 C# 時(shí)，可能在能夠工作的代碼中引入錯(cuò)誤。 重新編寫和轉(zhuǎn)換代碼所能期望的最佳值，也不過是實(shí)現(xiàn)與以前同樣的功能。 如果想以 CLR 為目標(biāo)平臺根本不需要這樣做。 相反，你的時(shí)間和精力可以花在使用新的系統(tǒng)功能和擴(kuò)展應(yīng)用程序的功能上。
自 .NET Framework, CLR 和 C# 發(fā)布以來的幾年中，許多開發(fā)人員都對 Microsoft 的 C++ 計(jì)劃感到驚奇。 有些人推測 C# 將取代 C++ ，事實(shí)上當(dāng)然并非如此。 C# 是一種比 C++ 更容易學(xué)習(xí)的語言，它提供了訪問 CLR 功能的途徑。 對于已經(jīng)了解 C++ 的人來說，要訪問 CLR 的功能，無需學(xué)習(xí)其他語言， C++ 具備 C# 中沒有的功能，因此轉(zhuǎn)向 C# 實(shí)際上將會喪失一些能力。
Microsoft Visual C++ 的每個(gè)版本與標(biāo)準(zhǔn)的兼容性都比前一版更好，當(dāng)前版本 Visual C++ .NET 2003 ，大約與 ISO C++ 標(biāo)準(zhǔn)達(dá)到了 98% 兼容。 這一版本中訪問 CLR 功能的關(guān)鍵字都以雙下劃線開始，因此不會干擾與標(biāo)準(zhǔn)的兼容性。 雖然這種方式可行，但是很笨拙，而且不夠直觀。 Visual C++ 2005 中將包含一個(gè)新的 C++ 到 .NET 的綁定，該綁定正在以 C++/CLI 的名稱進(jìn)行標(biāo)準(zhǔn)化。 這一修訂包括當(dāng)前 C++ 標(biāo)準(zhǔn)中沒有的關(guān)鍵字，但是同樣不會干擾符合標(biāo)準(zhǔn)的 C++ 程序，因?yàn)樗鼈冏袷?ISO C++ 的標(biāo)準(zhǔn)擴(kuò)展機(jī)制。 C++/CLI 擴(kuò)展的國際標(biāo)準(zhǔn)正在由 ECMA 制定，最終將提交給 ISO 。 與今天的 C# 一樣， C++/CLI 將被標(biāo)準(zhǔn)化，因此 Microsoft 將不會是 C++/CLI 編譯器的唯一來源。 Visual C++ 2005 現(xiàn)在已經(jīng)處于 beta 版，因此我們可以立即探討這些新的擴(kuò)展。 在這篇白皮書中，我們將在代碼示例中使用新的 C++/CLI 語法。 （ CLI 代表的是公共語言基礎(chǔ)結(jié)構(gòu)，是 .NET Framework 的標(biāo)準(zhǔn)化部分，包括 .NET 公共語言運(yùn)行庫。)
理解 .NET 上的 C++
當(dāng)你編寫在 CLR 上運(yùn)行的代碼時(shí)，你所編寫的就是托管代碼。 標(biāo)準(zhǔn) C++ 代碼，也就是能夠在任何符合標(biāo)準(zhǔn)的 C++ 編譯器上編譯的代碼，可以編譯成非托管（本機(jī)）代碼或者編譯成 MSIL ： 只需使用一個(gè)編譯器開關(guān)即可。 指定 /clr 選項(xiàng)，編譯器就會生成 MSIL ，一個(gè)在 CLR 上運(yùn)行的程序集。 使你的代碼成為托管的就是使用 編譯器選項(xiàng)。 不需要使用任何特殊的關(guān)鍵字或者太多改變代碼（如果需要改變的話），就能夠通過 /clr 選項(xiàng)干凈利索地進(jìn)行編譯。
編寫了托管代碼之后，就可以（如果你愿意）使用 CLR 功能了，比如基類庫： 這是能夠?qū)崿F(xiàn) XML 操作、加密解密、數(shù)據(jù)訪問等等功能的強(qiáng)大的類庫。 非托管代碼，即沒有使用 /clr 選項(xiàng)編譯的代碼，就無法聲明托管類的實(shí)例，并按托管代碼的方式直接調(diào)用它們的方法。 可以通過 .NET Interop 從非托管代碼中訪問托管代碼，該技術(shù)能夠使 .NET 對象看上去像是一個(gè) COM 組件。 這種方式與將代碼編譯成托管的，并直接調(diào)用托管代碼相比，肯定要慢。
無論是否使用基類庫（和其他托管庫），你仍然可以用 C++ 編寫程序，仍然擁有 C++ 賦予你的所有功能和靈活性。 可以使用模板，編寫操作符重載，創(chuàng)建內(nèi)聯(lián)函數(shù)，等等。 編譯為 MSIL 并不會阻止你使用任何 C++ 功能。 比如說，多重繼承被排除在外不是因?yàn)榇a編譯為 MSIL 了，而只是因?yàn)槟憔帉懙氖峭泄艽a而已。
托管和非托管類型
一個(gè)普通的 C++ 類，就是編程語言入門課程中教授的那種，將定義一個(gè)非托管類型：
class A
{
private:
int x;
public:
A(int xx): x(xx) {}
};
無論是否帶 /clr 選項(xiàng)編譯代碼（托管還是非托管代碼），這都是一個(gè)非托管類型，也俗稱為非托管類或者非托管數(shù)據(jù)。 這個(gè)類的實(shí)例可以分配在堆棧中，這也是編程語言入門課程中教授的內(nèi)容：
A something(3);
它們還可以在本機(jī)或者非托管堆中創(chuàng)建：
A* otherthing = new A(4);
程序員然后還必須記住清除非托管堆中的對象，使用 delete 操作符：
delete otherthing;
無論是哪一種方式，都不會涉及垃圾回收器，即使代碼編譯為 MSIL ，而且應(yīng)用程序運(yùn)行在運(yùn)行庫上。
但是你也可能需要編寫托管類型（也稱托管類或者托管數(shù)據(jù)）。 這些類型可以從其他程序集中調(diào)用，其他運(yùn)行在運(yùn)行庫上的托管代碼，無論其他程序集是用什么語言編寫的。 用 C# 、用 Visual Basic .NET 或者用你沒有聽說過但是碰巧能編譯成 MSIL 的語言編寫的代碼，都可以使用你的托管類型。 這種交互是由運(yùn)行庫托管的，而且在大多數(shù)情況下，你的代碼和其他程序集所創(chuàng)建的那些類型實(shí)例的生存期也是由運(yùn)行庫托管的。
這些托管類型是第一級的 .NET 對象。 用 C++/CLI 創(chuàng)建托管類型，可以采取一種自然的語法，與傳統(tǒng) C++ 區(qū)別不大：
ref class R
{
private:
int x;
public:
R(int xx): x(xx) {}
};
這個(gè)類定義使用了一個(gè)空格關(guān)鍵字——僅包含一個(gè)空格的關(guān)鍵字。 從技術(shù)上說， C++/CLI 中并沒有 ref 關(guān)鍵字，而只有 ref class 關(guān)鍵字。 這意味著你可以使用名為 ref 的變量而不會引起沖突。 而且這個(gè)類 R 可以被用 C# 或者 Visual Basic .NET 或者其他支持 .NET 的語言編寫的代碼所使用。 可以用 C++/CLI 編寫一個(gè)類庫，使用你作為一位 C++ 程序員多年形成的技術(shù)和技巧，然后將這個(gè)庫用在根本沒有使用 C++ 編寫的應(yīng)用程序中。 它們只需要是運(yùn)行在 CLR 上的應(yīng)用程序即可。
依然是 C++
轉(zhuǎn)向 CLR 并不意味著要轉(zhuǎn)向 C# 。 許多 C++ 開發(fā)人員在 C# 發(fā)布時(shí)轉(zhuǎn)向了 C# 。 其原因多種多樣： C# 的向?qū)Ш驮O(shè)計(jì)器支持更好，而且管理層經(jīng)常會支持新語言，僅僅是因?yàn)樗?，而一些開發(fā)人員并沒有認(rèn)識到托管應(yīng)用程序也能夠用 C++ 創(chuàng)建。 但是許多開發(fā)人員都拒絕這種轉(zhuǎn)向，甚至某種程度上完全拒絕轉(zhuǎn)向 CLR 。 拒絕的理由中常見的主題是： “我喜歡 C++ ?！?C++ 具有其他語言不具備的功能，比如真正的確定性析構(gòu)和模板。 選擇用 C++ 編寫托管代碼時(shí)，你可以獲得所有 C++ 的功能和所有 CLR 功能： 可謂魚與熊掌兼得。
確定性析構(gòu)
在其他支持 .NET 的語言比如 Visual Basic .NET, C# , 或者 Visual C++ .NET 2003 C++ 托管擴(kuò)展中，實(shí)例的位置取決于要創(chuàng)建的類型。 如果創(chuàng)建的是一個(gè)托管類型的實(shí)例，它將創(chuàng)建在托管堆中：
Dim o as new R(3) ' VB.NET
R o = new R(3); // C#
R* o = new R(3); // managed extensions for C++
實(shí)例（在所有這些例子中都是 o ）使用的內(nèi)存是由運(yùn)行庫托管的，可以被垃圾回收器清除或者重新組織。
相反，如果你創(chuàng)建的是一個(gè)值類型的實(shí)例，在所有三種語言中，實(shí)例都是在堆棧中創(chuàng)建的：
Dim i As Int32 = 7 ' VB.NET
int i = 7; // C#
int i = 7; // managed extensions for C++
只有在 C++/CLI 中你能夠獲得自由，自行決定在哪里創(chuàng)建對象，是否想讓實(shí)例的內(nèi)存由運(yùn)行庫托管。 你可以在托管堆中創(chuàng)建一個(gè)引用類的實(shí)例（即前面用 ref class 關(guān)鍵字定義的那個(gè)實(shí)例），如下：
R^ o = gcnew R(3); // C++/CLI
如果愿意，可以在堆棧中創(chuàng)建實(shí)例：
R os(3);
o 和 os 之間的區(qū)別在它們的生存期上，或者說得更加具體一些，是對它們生存期的控制力。 如果編寫的是托管代碼，你可能不會介意放棄對內(nèi)存的控制權(quán)，反而愿意信任運(yùn)行庫和垃圾回收器為你管理內(nèi)存。 但是開發(fā)人員仍然需要操心與內(nèi)存無關(guān)的清除工作： 比如關(guān)閉文件或者連接。 垃圾回收本身不足以處理你在應(yīng)用程序中使用的所有資源。 在 C++ 中，這種與內(nèi)存無關(guān)的清除通常是在析構(gòu)函數(shù)中進(jìn)行的。
托管堆中的對象是通過句柄 o 訪問的，當(dāng)控制達(dá)到帶有 gcnew 的那一行時(shí)對象就開始存在。 未來某個(gè)時(shí)候， o 將超出控制范圍。 可能控制已經(jīng)超過用 return 或者 exit 語句聲明它的代碼塊，可能代碼塊是 if, for, 或者 while 語句的謂詞而且控制已經(jīng)以通常的方式離開，或者出現(xiàn)了異常。 無論原因如何， o 都將超出范圍。 這時(shí)候，事情變得有些復(fù)雜。 如果任何代碼都有句柄的副本，副本將到處都是，然后只要范圍中有句柄，對象就將繼續(xù)在托管堆中存在。 如果句柄對象應(yīng)該回收了，但是回收的準(zhǔn)確時(shí)間并不知道，因此何時(shí)運(yùn)行析構(gòu)函數(shù)是未知的。 這取決于應(yīng)用程序施加的內(nèi)存壓力數(shù)量等等因素。
對于堆棧中的對象 os ，情況就大大不同了。 在超出范圍后（按照使 o 超出范圍的同樣情況），對象的一切就結(jié)束了。 它的析構(gòu)函數(shù)，如果有的話，將在 os 離開范圍后立即運(yùn)行。 你可以準(zhǔn)確地知道與內(nèi)存無關(guān)的清除何時(shí)發(fā)生，而且能夠盡快發(fā)生。 這就是所謂確定性析構(gòu)。
順便提及， os 實(shí)例（我們認(rèn)為它在堆棧中）實(shí)際上使用的是托管堆上的內(nèi)存（依然是由垃圾回收器托管的）。 析構(gòu)函數(shù)并不回收該實(shí)例使用的內(nèi)存；它關(guān)心的是與內(nèi)存無關(guān)的清除。 引用類型只能模擬為在堆棧中。 如果你已經(jīng)習(xí)慣不管內(nèi)存管理，并信任垃圾回收器處理一切，這種模擬是非常理想的。
C# 中的 using 構(gòu)造提供了類似的能力，但是 C++ 中的自動范圍更簡單： 編寫的代碼更少，而且不會忘記。 在 C++ 中的析構(gòu)函數(shù)和可以用其他語言編寫的托管類型中的 Dispose() 方法之間有很好的對應(yīng)關(guān)系： 實(shí)際上它們是相同的。 當(dāng) C# 代碼使用你的托管類型并調(diào)用 Dispose() 時(shí)，實(shí)際上運(yùn)行的就是析構(gòu)函數(shù)。 如果 C++/CLI 代碼使用一個(gè)不是用 C++ 編寫的托管類型，并在堆棧中創(chuàng)建它，當(dāng)實(shí)例超出范圍時(shí)，就不會運(yùn)行一個(gè) C++ 析構(gòu)函數(shù)，而是運(yùn)行一個(gè) Dispose() 方法。 對于 C++ 開發(fā)人員而言，這就是確定性析構(gòu)。 這意味著我可以這樣編寫 C# 代碼：
{
using( System::Data::SqlClient::SqlConnection conn
= new System::Data::SqlClient::SqlConnection(connString) ) {
// work with the connection in some way
// including code that might throw an exception
using( System::Data::SqlClient::SqlCommand cmd
= new System::Data::SqlClient::SqlCommand(
queryString, conn) ) {
// work with the command
// must write "using"s to call Dispose or Close
}
}
}
在 C++ 中，我可以編寫這樣的代碼：
{
System::Data::SqlClient::SqlConnection conn(connString);
// work with the connection in some way
// including code that might throw an exception
System::Data::SqlClient::SqlCommand cmd(queryString, %conn);
// work with the command
// don't call Dispose or Close explicitly
}
SqlConnection 和 SqlCommand 對象實(shí)現(xiàn)了 IDisposable ，但是 C++/CLI 程序員不需要記著調(diào)用 Dispose() 。 編寫代碼更少，不會遺忘，都是 C++ 中析構(gòu)機(jī)制的自然優(yōu)點(diǎn)。 使用 CLR 上的這一機(jī)制非常自然和直觀，而無需要求庫用 C++ 編寫或者實(shí)現(xiàn)析構(gòu)函數(shù)。
模板
C++/CLI 中使我們能夠在堆棧中創(chuàng)建托管類型實(shí)例的因素，也使我們能夠在傳統(tǒng) C++ 模板中使用托管類型：
set<String^>^ SetofStrings;
. . .
String^ s = "Hello World";
SetofStrings->insert( s );
這意味著使用托管類型（無論是你自己的還是來自基類庫）時(shí)， STL 中的一切都可以訪問。 C++/CLI 帶有一些輔助模板，包括 auto_close<> （這是一個(gè)智能指針的 Variant ，能夠調(diào)用它所包裝的實(shí)例的 Close 方法），和 marshal_as<> ，能夠轉(zhuǎn)換相關(guān)的類型比如 System::String 和 std::string 。
混合托管和本機(jī)開發(fā)
如果你還在猶豫是否用 /clr 選項(xiàng)重新編譯標(biāo)準(zhǔn)非托管 C++ 代碼，請不要煩惱！ 在一個(gè)應(yīng)用程序中混合和匹配托管和本機(jī)（非托管）代碼是非常直接的。
從托管代碼，你可以調(diào)用任何現(xiàn)有的非托管代碼，就像非托管到非托管似的。 包含頭文件，與庫連接之后，然后就一切就緒了。 你是調(diào)用一個(gè)老的 C 語言庫，一個(gè) C++ 庫還是一個(gè) COM API 都無關(guān)緊要。 你所調(diào)用的代碼使用了什么庫也無關(guān)緊要。 只需 #include 并如常繼續(xù)即可。 你的代碼可以在托管呼叫代碼和非托管目標(biāo)代碼之間過渡，然后為托管代碼帶來最高性能的回報(bào)。 其他支持 .NET 的語言都沒有這樣的選擇。 這種功能，以前被稱為 It Just Works interop ，現(xiàn)在稱為 C++ Interop 。
從非托管代碼可以訪問所有托管類型，不過需要包裝為 COM 類型。 regasm 實(shí)用工具為托管類型生成和注冊類型庫，可以使用編譯器支持（比如 #import ）從本機(jī)代碼中訪問組件。 這一選擇會影響性能： 可以改而選擇用 /clr 編譯呼叫代碼，并直接通過運(yùn)行庫訪問托管類型。 為了保持 C++ 的理念，選擇由你決定。
.NET 路線圖
C++/CLI 為你提供了極大的余地，可以選擇如何訪問由 CLR （以及由 WinFX ）提供的功能。 如果你要編寫一個(gè)新的應(yīng)用程序，用 C++/CLI 編寫以 CLR 為目標(biāo)平臺所具有的優(yōu)點(diǎn)是不可抗拒的。 可以擁有可靠性，可以訪問重要的托管 API ，從托管庫中獲得極高的開發(fā)人員生產(chǎn)率，而又無需放棄訪問本機(jī)庫或者任何 C++ 范型。 進(jìn)行這種決策簡直是再清楚不過了： 用 C++/CLI 為 Windows 編寫一個(gè)托管應(yīng)用程序。
那么現(xiàn)有的應(yīng)用程序怎么辦呢？ 有些應(yīng)用程序已經(jīng)到了它們生存周期的末期： 你已經(jīng)不想增加功能或者進(jìn)行明顯改動了。 用戶不再指望它與其他應(yīng)用程序集成。 像這樣的應(yīng)用程序無需轉(zhuǎn)向 .NET 。 它們將在未來運(yùn)行在 Microsoft Windows 代號 "Longhorn" 之上，因此可以不去管它們。
剩下的就是還沒有到生存期末期的現(xiàn)有應(yīng)用程序了。 你想維護(hù)和增強(qiáng)這些應(yīng)用程序，可能還計(jì)劃在增強(qiáng)中使用托管庫。 或者你可能愿意以 CLR 為目標(biāo)平臺以減少大型分布式應(yīng)用程序部署時(shí)的麻煩。 基本上，有三種選擇： 重寫，集成或者遷移。
重寫是風(fēng)險(xiǎn)最大的一種方式。 必須完整地閱讀代碼，找出 .NET 世界中有等效物的庫和構(gòu)造。 例如，原來可能使用 MFC 構(gòu)建 Windows 應(yīng)用程序的用戶界面： 而今天 .NET 中的等效物是 Microsoft Windows 窗體，在 "Longhorn" 時(shí)代是 Avalon 。 可以使用 ADO 或者 MFC 數(shù)據(jù)訪問類處理數(shù)據(jù)： 而 .NET 的等效物是 Microsoft ADO.NET ，使用 DataSet 或者 DataReader 類。 尋找這些庫和構(gòu)造的工作量是非常大的。 然后還要重新編寫應(yīng)用程序的大部分，在此過程中還可能引入錯(cuò)誤，所以還必須進(jìn)行全面測試。 這都需要時(shí)間和成本，但是當(dāng)工作全部完成，你將擁有一個(gè)現(xiàn)代的應(yīng)用程序，全部用 C++/CLI 編寫，盡可能使用托管庫。
如果當(dāng)前代碼基礎(chǔ)比較老，而且已經(jīng)更新多次，或者你的開發(fā)團(tuán)隊(duì)并不能很好地理解，但是它又必須以某種方式改進(jìn)或者更新，那么重新編寫可能是最適合你的方式。 如果必須創(chuàng)建可以驗(yàn)證的程序集以用于部分信任情況，可能也需要采取一些重新編寫的方式。 雖然對于大多數(shù)開發(fā)人員來說這一方式是第一計(jì)劃，但是實(shí)際上它應(yīng)該是最后的選擇。 如果現(xiàn)在你的代碼很簡潔，文檔齊全，性能很好，應(yīng)該盡可能拒絕進(jìn)行重新編寫。
集成方式是將所有 .NET 庫（基類庫， WinFX, Indigo, Avalon, 等等）都視為要使用的新庫。 現(xiàn)有的代碼基礎(chǔ)保持不變，用使用這些新庫的新模塊擴(kuò)展它。 可以將應(yīng)用程序的主干代碼重新編譯為 MSIL ，直接調(diào)用運(yùn)行庫中的新庫，并使用 C++ Interop 訪問老庫。 或者，可以將主干代碼保留為本機(jī)（非托管）代碼，使用 COM 可調(diào)用包裝來包裝托管類型，將它們公開給舊代碼。 進(jìn)行一些性能測試有助于進(jìn)行決策。 可以根據(jù)選擇用 /clr 編譯部分代碼基礎(chǔ)。
遷移方式處于上面兩個(gè)極端之間。 在你的應(yīng)用程序已經(jīng)分成多個(gè)組件或者層時(shí)最適合。 （巨大的單塊應(yīng)用程序是非常難于維護(hù)的，因此無論如何都應(yīng)該將應(yīng)用程序組件化，但是這種重構(gòu)也是一種形式的重新編寫，會帶來風(fēng)險(xiǎn)。） 然后可以將每個(gè)組件用公開托管類型的 C++/CLI 代碼包裝起來。 新的主干應(yīng)用程序可以使用這些托管類型，新的托管類型也可以與 .NET 庫交互。 隨著時(shí)間推移，在包裝中的本機(jī)“核心”可以重新編寫為完全的托管代碼，只使用托管庫，如果有重要的性能原因或者代碼安全原因需要如此的話。
小結(jié)
無論進(jìn)行何種開發(fā)： 從頭編寫一個(gè)新的應(yīng)用程序，維護(hù)我們無需做太多工作的現(xiàn)有應(yīng)用程序，或者使一個(gè)歷盡滄桑的老應(yīng)用程序重新煥發(fā)青春， .NET Framework 都可以使你的工作更加簡單。 使用 C++/CLI 將應(yīng)用程序與 CLR 集成，或者將應(yīng)用程序遷移到 CLR ，都比將應(yīng)用程序移植到 C# 更加可行。 C++/CLI 為我們提供了CLR 上 C++ 的功能和靈活性，提供了真正的確定性析構(gòu)（即使是托管類型），提供了性能最高的交互操作。 對于任何要以 CLR 為目標(biāo)平臺的開發(fā)應(yīng)用程序的 C++ 程序員而言，這都是一種非常自然的選擇。
作者簡介
Kate Gregory 是一位 Microsoft 地區(qū)經(jīng)理， Visual C++ MVP ，以及《 Microsoft Visual C++ .NET 2003 Kick Start 》一書的作者。 Gregory 咨詢公司為全北美提供咨詢和開發(fā)服務(wù)，專門利用最新技術(shù)從事軟件開發(fā)、集成項(xiàng)目、技術(shù)寫作、指導(dǎo)和培訓(xùn)。
轉(zhuǎn)到原英文頁面