Visual Studio 11引入了一些深入的新的語言擴展，官方稱為C + + / CX，這為了支持新的 API 模型在 Windows 8 中。一般人都會熟悉 C + + / CLI （即我們提供針對 CLR 的語言擴展），語法不應該似乎大不相同。 請注意，然而，在 C + + / CX 語法是非常類似于 C + + / CLI，底層實現是非常不同，它不使用 CLR 或垃圾回收器，與它生成完全本機代碼 。 在微軟支持 Windows 8 的設計中，有很多創新，包括純庫的方式，以及集成在語言中的支持的各種方法。有歷史悠久的 Visual c + + 團隊中支持 COM。從 MFC 在 ATL # import ，在針對 CLR 包括原始托管的擴展，C + + / CLI 和 IJW 支持編譯為 MSIL 的本機代碼。 但是并未稱為 WRL （Windows 運行時庫），并支持針對 Windows 8 沒有語言擴展 Windows 8 的開發一個新的 c + + 模板庫。WRL 相當好，它可以看一看，看看所有的低級的細節如何實現的照明。它是由內部使用許多 Windows 團隊，雖然它不會受到許多同樣的問題，ATL 支持 com 經典。 1.創作組件的仍然是非常困難的。要知道很多有關接口的低級的規則。 2.需要單獨的工具 (MIDL） 給作者接口/類型。 3.有沒有辦法自動地圖接口從低級到更高的級別 (現代) 形式，引發異常，并且具有真正的返回值。 4.沒有統一的創作和消費模式。 與一些 Windows 運行庫中的新概念，這些缺點變得更難比在經典 COM/ATL.接口繼承并不是基于 vtable 的像是在經典.com，類繼承基于一個類似的機制來聚合，但有一些區別，包括私有和受保護的接口支持。盡管有需要一個低級的工具，像 WRL 對于絕大多數的用途，但它實在太難用，是我們可以做很多更好地同時仍然保留性能，并提供大量的控制。 ?# Import 功能，無法在 VC6 提供了良好的機制，為消費具有類型庫的 COM 對象。類似 Windows 運行庫 （它使用一個新的.winmd 文件），但時，它能提供良好的消費體驗，它不進行創作。由于 Windows 移動模型很多事都異步的創作的回調是非常重要的而且沒有不包括至少一些創作的許多消費情況。此外，創作是很重要的寫作為每一頁的用戶界面的應用程序和用戶定義的控制是從現有的運行時類派生的類。 微軟團隊早就決定應公開的類和接口比 ABI 定義什么的更高級別。支持現代 c + + 的功能，如異常被認為是重要，以及將繼承 （均為接口和類） 的運行時定義映射到 c + +，很自然的一種。 拿到 WinRT 類或接口的指針。這也是接口的如何判斷一個低級版本和接口的高級別版本之間的區別。有很多不同的建議，包括只使用*、 使用*用修飾符，并使用各種其他字符如@符號。在原始的擴展做為托管代碼中，事實上未使用*修飾符 （__gc）。 很多人都已存在的 C + + / CLI 的語法。引用計數是一種形式的垃圾回收，使用^表示"refcounted"指針在 ZW 符合得很好。取消引用^的收益率%，也像 C + + / CLI。雖然很多概念都表示相同的方式，有幾個領域，我們決定偏離 C + + / CLI。例如，在 C + + / CX，默認接口的類指定通過屬性的接口列表時中 C + + / CLI 是類本身的屬性。 在 C + + / CX 有了更好的開發模式比 C + + 進行互操作時的 CLI 引用類型與常規類型。在 C + + / CLI，托管對象可以左右移動在內存中運行時，垃圾回收器。這意味著不能得到真正的成員的地址 （不固定） 或甚至將基元類型 （如int） 除了嵌入到您的類。也不能把^到本機類或結構。在 C + + / CX，對象在內存中做不能移動，因此所有這些限制都不見了。可以將任何類型投入 ref 類，您可以將^放在任意位置。這種模式是以正常的 c + + 類型更加友好和使程序員更靈活地在 C + + / CX。  趕緊下載VS11體驗吧 [http://www.microsoft.com/click/services/Redirect2.ashx?CR_CC=200098144](http://www.microsoft.com/click/services/Redirect2.ashx?CR_CC=200098144) ? ?