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