C++/CLI：优于 C#答案

【问题标题】：C++/CLI : Advantages over C#C++/CLI：优于 C#
【发布时间】：2009-12-11 09:33:34
【问题描述】：

托管 C++/CLI 与 C# 相比有什么主要优势吗？绝对不是我认为的语法，因为 C++/CLI 中的以下代码真的很难看，

C++/CLI 代码：

[Out]List<SomeObject^>^% someVariable

上面与 C# 代码比较：

out List<SomeObject> someVariable

出于好奇，与上述相比，C++/CLI 中是否有更丑陋的语法。

【问题讨论】：

标签： c# c++-cli declaration

【解决方案1】：

它几乎完全是一种互操作性语言 - 既允许 .Net 代码访问旧版 C++ 库，也允许扩展现有（本机）C++ 代码库以访问 .Net 库（以及这些主题的一些变体）。

虽然可以仅在 C++/CLI 中编写完全成熟的应用程序，并且它甚至为您提供了一些纯 C++ 中不可用的语言功能（例如垃圾收集），但我怀疑有很多真正会这样做的人。如果您已经远离纯 C++ 并且没有与 .Net 互操作的目标，那么可能会有更自然的选择（例如 D 或 Scala - 取决于您想要的方向中）。

同样，从纯 C# 迁移到 C++/CLI 可以说可以带来 C++ 模板的优势，但这种需求很少会导致您迈出这一步。

【讨论】：

我可以添加支持这一点。在以前的项目中，我必须在 C# asmx Web 服务应用程序和 IBM 中间件之间编写一个接口，该中间件只有一个 C++ api 库（不是 dll，而是一个静态库）。 C++/CLI 是创建这个桥的唯一选择。
A D .Net 实施正在进行中。可能在不久的将来，D 可以与 .Net 互操作。

【解决方案2】：

与本机 C++ 代码更容易互操作是一大优势。

是否是主要优势是主观的。

除非您想与现有的本机 C++ 代码混合，否则使用 C# 可能会更好。

【讨论】：

好答案。但这并不是真正主观的 - 当（且仅当）您别无选择只能处理现有的本机代码时，这是一个主要优势。
这仍然是主观的。如果您需要使用现有的 DLL，您可以选择使用 C# 和使用 P/Invoke 与现有代码进行互操作。无论是“主要”优势还是“次要”优势，更容易的互操作与“主要”优势还是“次要”优势，C# 完全取决于提出问题的人。

【解决方案3】：

我能想到使用 C++/CLI 的 3 个主要原因：

您已经有一个大型 C++ 项目并希望在其中使用 .NET（无论您是否希望将来完全迁移它）
您想使用用 C 或 C++ 编写的库。对于简单的库，您可以使用 C#/PInvoke，但例如如果库带有复杂的类型系统，您最好创建 C++/CLI 包装器，而不是在 C# 中重新创建类型系统
项目中的部分最好用 C++ 编写。例如。如果您正在进行语音识别或图像处理，C++ 可能更适合这项任务。

【讨论】：

您能否详细说明关于语音识别或图像处理的第 3 点？
C++ 中的图像处理 => boost.org/doc/libs/1_41_0/libs/gil/doc/index.html

【解决方案4】：

能够直接使用本机头文件是一个巨大的优势，但不是唯一的优势。

堆栈语义比 C# 为IDisposable 管理提供的任何东西都要好得多。 C++/CLI 有一个统一的语法来正确管理变量IDisposable 和不是的变量，既作为局部变量又作为成员字段。比较：

ref class MyClass
{
   FileStream fs;
}

对

class MyClass : IDisposable
{
  FileStream fs;

  void IDisposable.Dispose() { Dispose(true); }
  ~MyClass() { Dispose(false); }

  public virtual void Dispose(bool disposing) { if (disposing) fs.Dispose(); }
}

现在哪种语言看起来很丑？

然后是模板、interior_ptr、#define、本地 DLL 导出、指向成员的指针，以及可能我忘记的其他几件事。

【讨论】：

我同意，除了#define。从我的角度来看，它在许多项目中的巨大而冷漠的用法是 PITA。

【解决方案5】：

使用 C++/CLI 可以很容易地与原生 C++ 代码交互

【讨论】：

【解决方案6】：

托管 C++ 的优势在于可以轻松混合托管代码和非托管代码。但是，如果您的所有（或几乎所有）代码都将被管理，那么绝对应该使用 C#（并且您仍然可以使用 invoking unmanaged code from C# 使用 DllImport attribute）。

【讨论】：

【解决方案7】：

CLI/C++ 比 C# 有很多优势。

性病库
反汇编程序（如 Reflector）无法查看原生 C++/C，因为它们实际上不是 CLI（无需混淆（尽管优秀的黑客已经可以做到这一点））。
Mingling C/C++ 项目作为与 .Net 语言一起使用的包装器。 C++/CLI 不是一种语言，只是用 C/C++ 添加了对 .Net 的支持。
通过指向堆上 C/C++ 对象的 C/C++ 指针对内存进行一些控制。

我讨厌必须信任 GC 才能找到卡在 gen 2 上的对象。天知道什么时候会从托管堆中释放它。

【讨论】：

【解决方案8】：

作为一名主要使用 C# 的程序员，我发现自己不得不使用 C++/CLI 有点痛苦。但是，作为一种互操作语言，它在必须使用本机代码方面远胜过 C#。 Visual Studio 中的 C++/CLI IDE 缺少很多 C# 风格的功能。

总体而言，它有它的位置，只要存在原生代码，它就会一直存在。如果不需要的话，我不希望必须使用 C++/CLI IDE 从头开始创建 WinForm 应用程序。

【讨论】：

【解决方案9】：

你只需要在需要的时候转向c++\cli，如果你可以使用c#满足你的要求，为什么还要去c++\cli

【讨论】：

【解决方案10】：

一般来说，我认为 C++/CLI 的主要优势在于 C++ 开发人员非常熟悉。如果您不是来自 C++ 背景，那么请选择 C#。

【讨论】：

我认为不是。我来自 C++ 背景（混合了 Java 和 Delphi），而 C# 非常容易掌握。不需要 C++/CLI 只是为了熟悉。我很幸运能摆脱 C++ 语法 :)
有趣，我已经有一段时间没有做任何 C++ 了，但我认为 C++/CLI 语法会比 C# 更熟悉，但我想不会！

【解决方案11】：

非托管 c++ 应用程序不需要框架即可运行，c# 只能在具有 dotnet 框架 1、2、3 或 4 的机器上运行。令人惊讶的是，没有这些框架仍然有多少机器运行。

【讨论】：