C++/CX 和 C++/CLI 依赖答案

【问题标题】：C++/CX and C++/CLI dependencyC++/CX 和 C++/CLI 依赖
【发布时间】：2014-02-20 07:32:15
【问题描述】：

从语法和编译过程来看，C++/CX 和 C++/CLI 有什么关系？ https://softwareengineering.stackexchange.com/questions/162168/what-are-c-cx-and-c-cli-and-how-do-they-relate-to-c-and-winrt 没那么全面。谁有更多信息？

【问题讨论】：

认为他们有任何东西的共同点并没有多大帮助。语法看起来很相似，因为它们都解决了相同的问题，都与外部类型系统交互。

标签： c++-cli c++-cx

【解决方案1】：

（此回答代表我作为一名参与C++/CX实现的测试人员的个人经验，不应理解为代表任何人的意见。）

在内部，当 Windows 宣布他们正在构建 Windows 运行时，并且由 The Powers That Be 决定 DevDiv 的主要目标之一是支持此 API 并提供对各种语言的有用预测时，一个小型设计团队旨在研究由此为 C++ 团队带来的独特挑战和机遇。我成为了分配给这个功能的编译器测试员之一，当时我们称之为“MoCOM”（现代 COM）。就上下文而言，重要的是要指出，我不是语言设计团队的成员，但我知道设计的一些早期草稿。

目前尚不清楚这种最终语言将采用何种形式，并且有许多不同的提案（其中一些比其他的低级）。有一点变得很清楚：最终的目标是充分利用新的 Windows 运行时，同时开发与 C++ 兼容的东西，并且在幕后具有高性能且完全原生。开发这种新语言的时间也很少。

WinRT 的设计者还仔细研究了不同语言使用它们的运行时意味着什么，并强烈考虑了 .NET 语言（尤其是 C#）如何与它们的运行时互操作。这意味着许多 WinRT 概念相当巧妙地映射到现有的 .NET 概念上。（这两个运行时试图解决许多相同的问题并提供相似的功能集，所以这并不完全令人惊讶。）

最后，这意味着 C++/CLI 的现有语法与 WinRT 的概念非常匹配，并且已经解决了许多更哲学的挑战，即如何以一种方式表示所有这些相同的概念与 C++ 语法兼容（在不同程度上）。它还具有已经在具有大量现有测试的编译器中实现的优势。最后，智能感知团队当时正在努力实现 C++/CLI 智能感知，因此我们可以通过少量额外支出获得 C++/CX 智能感知（至少与全新的语法相比）。

但是，尽管语法相同，但实际的代码生成却截然不同。在 .NET 中，运行时为您做了很多繁重的工作；语言定义了表达式的类型和 MSIL，但运行时做了很多繁重的工作：类型布局、本机代码生成、垃圾收集等。

几个例子：

在原生 C++/CX 世界中，^ 在概念和语法上类似于 C++/CLI ^（它表示指向接口或类的指针），但在实现中却大不相同。在 C++/CLI 中，您只需告诉运行时它是某种类型的托管指针（MSIL 中的 *），而运行时在 C++/CX 中“做了魔法”，^ 是编译器需要的智能指针在适当的时间（例如超出范围时）插入 AddRefs 和 Releases。
C++/CLI 中的“gcnew”变成了简单的单行 MSIL。 C++/CX 中的“ref new”需要确定合适的工厂，创建工厂的实例，然后要求工厂创建底层类的实例。
在 C++/CLI 中，您只需对类指针进行函数调用，在 C++/CX 中，如果您有一个类指针，您必须确定请求的函数实际位于的适当接口，该接口的 QI，然后根据 QI 的结果调用函数。

这些差异很多，每个概念图都提出了独特的挑战。此外，我的示例都是关于消费 WinRT 类型的；让编译器也能够创作与 WinRT 兼容的类型，这完全是另一回事。

这就是说：虽然 C++/CLI 和 C++/CX 的语法非常相似，但实际上实现完全不同。这是很多工作，但也是设计团队有意选择开发一种与 WinRT 概念兼容但不依赖 .NET 运行时的语言（因为它是不必要的，而且有理论上的性能优势）。

如果您想了解更多关于幕后实际发生的事情，Deon Brewis 是语言扩展的设计者之一和主要开发人员，他在构建 2011：http://channel9.msdn.com/Events/Build/BUILD2011/TOOL-690C。（我是键盘后面的那个人。）

【讨论】：