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 類或介面的指標。這也是介面的如何判斷一個低級版本和介面的進階別版本之間的區別。有很多不同的建議,包括只使用*、 使用*用修飾符,並使用各種其他字元如@符號。在原始的擴充做為Managed 程式碼中,事實上未使用*修飾符 (__gc)。
很多人都已存在的 C + + / CLI 的文法。引用計數是一種形式的記憶體回收,使用^表示"refcounted"指標在 ZW 符合得很好。取值 (Dereference)^的收益率%,也像 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