使用C++/CLI进行100％托管开发的优势是什么？

Question

以下是关于使用C++/CLI进行100％托管开发的优势（可能的缺点列表很长），与C#相比，特别是编译时使用/clr:safe（生成类似于... C#编写的程序集）？特别是在与C#进行比较时（请注意，C++/CLI：优于C＃的优势和使用C++/CLI是否有任何优势，而不是标准C ++或C＃？主要涉及托管/非托管互操作）。例如，以下是我想到的一些：

• 用于托管类型的 C++ 风格引用，比全面使用 非 null 引用 更为简洁，但比起无可奈何或者使用 解决方法 来说更好。

• 泛型不如模板强大

• 预处理器（这可能是一个缺点！但宏对于代码生成很有用）

• 引用类型的堆栈语义--自动调用 IDisposable::Dispose()

• 通过 C++ 析构函数更容易实现 Dispose()

C# 3.0 添加了自动实现属性，因此这不再是 C++/CLI 的优势。

- Ðаn

---

https://dev59.com/D0rSa4cB1Zd3GeqPZMZU - TFD

Answer 1

我认为最大的优势在于托管/非托管互操作性。纯粹使用托管 C++/CLI 编写代码 (至少对我来说) 而不与 C# 或其他 .Net 语言相互操作，似乎完全没有意义。是的，你可以这样做，但为什么要这样呢？

如果你要编写纯托管代码，为什么不使用 C# 呢？特别是（像 nobugs 说的那样）如果 VS2010 取消了对 C++/CLI 的 IntelliSense 支持。而且，在 VS2008 中，C++/CLI 的 IntelliSense 不如 C# 的 IntelliSense；因此，从开发者的角度来看，使用 C# 比使用 C++/CLI 更容易工作/探索/重构。

如果您想要一些 C++ 的好处，例如预处理器、堆栈语义和模板，那么为什么不使用 C++ 呢？

- cmw

---

除了互操作性外，C++/CLI并不适合其他任何用途。你的评论命中要害，如果想编写托管程序集，使用C#就好了。 - Finglas

@Dan，我并不认为这些就足以抵消C#开发的易用性和更好的IDE支持。 - Paolo

Answer 2

奇怪，我喜欢C++/CLI，但你列举出的正是我不喜欢的功能。我的批评如下：

• 好吧。但是意外使用符号帽是相当普遍的，将值类型的值装箱而没有警告。没有办法诊断这个错误。
• 高价之后的力量，你编写的模板在任何其他.NET语言中都无法使用。如果有什么问题，它只会加剧C++模板导出问题。STL/CLR的完全失败也值得思考。
• 额，不。
• 在我看来，这是一个严重的错误。首先提到了如何避免意外装箱的问题已经很困难了。栈语义使得任何初学者都很难解决这个问题。这是一个设计决策，以安抚C++程序员，这没问题，但使用语句是更好的解决方案。
• 不确定它如何更容易。GC.SuppressFinalize()调用是自动的，这就是全部。几乎没有人写终结器，但你无法避免自动生成的代码进行调用。这是低效的，并违反了“你不为所不用”的原则。再加上编写析构函数还会强制自动生成默认终结器。你永远不会使用它，如果你忘记或省略使用析构函数，也不想使用它。

好吧，这可能都是非常主观的。死亡之钟将与VS2010一起到来，它将不支持C++/CLI的IntelliSense功能。

- Hans Passant

---

你从哪里听说VS2010将取消C++的智能感知功能？在Google上快速搜索"VS2010 IntelliSense c++"，只会返回有关IntelliSense改进的信息。-1 除非你能证明你的说法。 - Russ

@Russ - 我的帖子中明确指出，这不是针对C ++，而是针对C ++ / CLI。链接：http://www.codeguru.com/forum/showthread.php?t=477959 。还我我的积分，该死的！ - Hans Passant

虽然我认为我更喜欢一些更新的东西。但我会接受它。+1 是因为提供了证据。 - Russ

啊，Stack Overflow 告诉我我的投票已经太久了，除非回答被编辑过，否则无法更改。(在您的评论中附上证明 +1) - Russ

在普通的C++中，如果构造函数抛出异常，那么作为其一部分构建的任何对象都将运行其析构函数。C++/CLI是否也是这样呢？如果是的话，那似乎比C#更具优势，因为有时候在构建类层次结构时，当构造函数抛出异常时，很难避免内存泄漏。 - supercat

这个答案让我了解到C++一些明显但不常被讨论的负面方面。我想建议编辑，将问题的重点放在回答中，使得每个要点都不需要反复滚动页面回到顶部才能看到。此外，我认为有必要详细阐述预处理器的观点；或许将预处理语言（或者说缺乏语言）的表现力与其他文本处理语言（例如Perl，虽然我不推荐该语言）进行比较可能会更有意义。 - autistic

Answer 3

在C++/CLI中，您可以在类外定义函数，但在C#中无法这样做。但我不知道这是否是一个优势。

- Arve

Answer 4

和其他人一样，我也无法想到任何普遍情况下存在明显优势的例子，因此我的想法转向了情境优势——是否存在特定情况下的优势呢？

优势：在快速原型设计场景中利用技术人员的C++技能。

让我详细说明一下...

我曾经与科学家和（非软件）工程师合作过，这些人没有接受过正式的编程培训。其中许多人使用C ++开发涉及高端物理/数学的特定模块。如果在快速原型设计场景中需要纯.NET模块，并且负责该模块的科学家/工程师的技能集是C ++，我会教他们少量额外的语法（public ref，^和%以及gcnew），并让他们将模块编程为100％托管的C++ / CLI DLL。

我认识到有许多可能的“但是...”回应，但我认为利用技术人员的C++技能是C++ / CLI的一个潜在优势。

- mcdave

Answer 5

我同意你所提到的，并且作为预处理器使用的示例，可以指向：Boost Preprocessor库，用于基于基本类型列表生成一组类型，例如在C++/CLI中的PointI32、PointF32等。

- nietras

Answer 6

在C++/CLI中，您可以将枚举和委托作为泛型约束条件，但在C#中不行。

https://connect.microsoft.com/VisualStudio/feedback/details/386194/allow-enum-as-generic-constraint-in-c

在C#中有一个库可以模拟这些约束。

http://code.google.com/p/unconstrained-melody/

- mjcopple

Answer 7

对于一个假设的产品，可以想象出以下要求：

1. 在Windows上快速上市
2. 最终部署到非Windows平台
3. 不能依赖于Mono来实现非Windows功能

在这种情况下，如果使用C＃来满足第1个要求，则在满足第2和第3个要求时需要进行重写。因此，可以使用C++/CLI进行开发，通过宏和模板技巧适当地混合，使其尽可能像普通的C++一样，以满足第1个要求，然后为了满足第2个要求，需要（a）重新实现所述宏和模板技巧以映射到真正的C++，以及（b）实现在真正的C++中使用的.NET框架类。请注意，（a）和（b）可以在完成一次后在未来重复使用。

最明显的反对意见是“为什么不完全使用本机C ++？”，好吧，也许有很多好东西在庞大的.NET类库中，您想使用它们来尽快进入市场。

我承认这有点牵强，所以我非常怀疑这曾经被做过，但尝试一下会很有趣！

- tragomaskhalos