C++/CLI 是标准 ISO C++ 的扩展吗？答案

【问题标题】：Is C++/CLI an extension of Standard ISO C++?C++/CLI 是标准 ISO C++ 的扩展吗？
【发布时间】：2014-08-06 07:03:43
【问题描述】：

Microsofts C++/CLI 是在 C++ 标准（C++98 或 C++11）之上构建的，还是只是“相似”并且存在偏差？

或者，具体来说，是否每个符合 ISO 标准的 C++ 程序（C++98 或 C++11）也是符合 C++/CLI 的程序？

注意：我将上面的 Wikipedia 文章解释为仅将 C++/CLI 与 MC++ 进行比较，而不是与 ISO 标准 C++ 进行比较。

【问题讨论】：

我不得不使用它一次并且不喜欢这种体验。（最后我选择了 Java / JNI 路线而不是 C#）。我会说这是一个偏差。在我看来，^ 指针的内容很粗俗，并且与 C++11 的std::shared_ptr 不相称。你第二段的答案肯定是否定的。
@Bathsheba 从我对维基百科文章的粗略阅读来看，^ptr 可能与 *ptr 不同，就像托管与非托管一样。比如!Finalizer 和~Destructor。两者仍然可以在 Std-C++ 之上。感谢您的美丽评论，但我的问题与美丽无关；-)
@Bathsheba shared_ptr 在您为它编写适当的适配器后，在 CLI 程序中工作得很好。例如 std::function 也是如此。一旦你有了一些适配器/转换样板代码，CLI 的体验并不是那么糟糕：那么它是迄今为止最简单的桥接 .Net 和 C++ 应用程序的方法 - 话虽如此，后者也是我的唯一原因会考虑再次使用 CLI，它擅长于此，但对于其余部分，它更像 meh

标签： c++-cli iso

【解决方案1】：

当然，它是对 C++03 的扩展，可以编译任何与添加的关键字不冲突的兼容 C++03 程序。它唯一不支持的是一些 Microsoft 对 C++ 的扩展，这些扩展与 __fastcall 和 __try 等托管代码执行根本不兼容。 MC++ 是他们的第一次尝试，通过在所有添加的关键字前加上下划线来保持兼容性。语法相当强制并且没有被他们的客户很好地接受，C++/CLI 放弃了这种做法并且具有更直观的语法。顺便说一句，以 C++ Primer 闻名的 Stanley Lippman 也参与其中。

编译器可以使用#pragma managed 在托管代码生成和本机代码生成之间动态切换，该产品是一个包含 MSIL 和本机机器代码的 .NET 混合模式程序集。从本地 C++ 源生成的 MSIL 并不完全等同于由 C# 或 VB.NET 编译器生成的那种。它不会神奇地变得可验证，也不会得到垃圾收集器的喜爱，您可以很容易地破坏堆或破坏堆栈。也没有优化器喜欢，MSIL 在运行时被转换为机器代码，并像普通托管代码一样被优化，具有抖动中固有的时间限制。将太多本机 C++ 代码翻译成 MSIL 是一个很常见的错误，编译器隐藏得太好了。

C++/CLI 以引入后来被 C++11 采用的语法而著称。比如nullptr、override、final 和enum class。有点问题，实际上，__nullptr 开始能够区分托管空指针和本机空指针。他们从来没有为 enum class 找到一个很好的解决方案，您必须将其声明为 public 才能获得托管枚举类型。一些 C++11 扩展工作，除了它已经有的扩展很少，auto 很好，但没有 lambda 表达式，在 .NET 编程中相当损失。自 2005 年以来，该语言已被冻结。

C++/CX 语言扩展也是值得注意的，它使为商店和电话应用程序编写 C++ 代码变得可口。语法与 C++/CLI 非常相似，包括 ref class 和语法中的帽子。但是对于分配有ref new 而不是gcnew 的对象，后者会误导太多。否则非常在运行时与 C++/CLI 不同，您会从 C++/CX 中获得纯本机代码。语言扩展隐藏了底层的 COM 互操作代码，自动对对象进行引用计数，将错误代码转换为异常并映射泛型。与 C++/CLI 语法的相似之处并非偶然，它们基本上执行相同的角色。将类 C++ 语法映射到外部类型系统。

【讨论】：

【解决方案2】：

CLI 是一组标准 C++ 的扩展。 CLI 完全支持标准 C++ 并添加了更多内容。因此，每个 C++ 程序都将使用启用的 CLI 进行编译，除非您使用 CLI 保留字，这是扩展的弱点，因为它不遵守扩展的双下划线规则（此类保留字必须以 __ 开头） .

您可以通过以下方式在 GUI 中停用这些扩展：

配置属性 -> 常规 -> 公共语言运行时支持

甚至Bjarne Stroustrup calls CLI 一个扩展：

关于 CLI 绑定/扩展 C++ 的名称这个困难且有争议的问题，我更喜欢 C++/CLI 作为“ISO C++ 的 CLI 扩展”的简写。保留 C++ 作为名称的一部分提醒人们什么是基础语言，并有助于使 C++ 成为具有 C++/CLI 扩展的 C++ 的正确子集

语言扩展总是可以被称为偏离标准，因为它不会使用没有 CLI 支持的编译器进行编译（例如 ^ 指针）。

【讨论】：

不能作为扩展，除非它使用标准强制语义编译每个符合标准的程序。 情况并非如此。（追求高兼容性并不意味着实现完全兼容。无论如何，前身 Managed C++ 已停产，因为它遵循 C++ 标准使其过于繁琐。）
大多数扩展都以某种方式破坏了兼容性，但大多数扩展都尊重附加保留字的两个下划线规则。我不认为，仅凭这一事实就足以将 CLI 归类为“非扩展”。
有一个非常简单的方法，它可以是一个扩展而不是一个派生，只使用实现私有符号，如果需要，添加一个包含文件，将它们更改为更好的符号.此外，C 和 C++ 有很多常见的实际扩展：它们的存在不会以任何方式改变任何符合标准的程序的行为。对于一些常见的列表，您可能需要查看 C 标准附件 J（大多数在 C++ 中也很常见）。