C# C++/CLI：我为什么要使用它？

C++/CLI: why should I use it?

提问by Idan

I'm pretty familiar with C++, so I considered learning .NET and all its derivatives (especially C#).

我对 C++ 非常熟悉，所以我考虑学习 .NET 及其所有衍生产品（尤其是 C#）。

Along the way I bumped into C++/CLI, and I want to know if there is any specific use for that language? Is it just suppose to be a intermediate language for transforming from native C++ to C#?

一路上我遇到了 C++/CLI，我想知道该语言是否有任何特定用途？它只是假设是一种从原生 C++ 转换到 C# 的中间语言吗？

Another question that popped to my head is why are there still so many programming languages in .NET framework? (VB, C++/CLI, C#...)

另一个出现在我脑海中的问题是为什么 .NET 框架中还有这么多编程语言？（VB、C++/CLI、C#...）

采纳答案by Hans Passant

Yes, C++/CLI has a very specific target usage, the language (and its compiler, most of all) makes it very easy to write code that needs to interop with unmanaged code. It has built-in support for marshaling between managed and unmanaged types. It used to be called IJW (It Just Works), nowadays called C++ Interop. Other languages need to use the P/Invoke marshaller which can be inefficient and has limited capabilities compared to what C++/CLI can do.

是的，C++/CLI 有一个非常具体的目标用法，该语言（及其编译器，最重要的是）使得编写需要与非托管代码互操作的代码变得非常容易。它内置支持托管和非托管类型之间的封送处理。它曾经被称为 IJW（It Just Works），现在被称为 C++ Interop。其他语言需要使用 P/Invoke 编组器，与 C++/CLI 可以做的相比，它可能效率低下且功能有限。

If you need to interop with native C++, classes that have instance functions and need the new and delete keywords to create/destroy an instance of the class then you have no choice but use C++/CLI. Pinvoke cannot do that, only the C++ compiler knows how much memory to allocate and how to correctly thunk the thispointer for an instance function.

如果您需要与本机 C++、具有实例函数的类进行互操作，并且需要 new 和 delete 关键字来创建/销毁类的实例，那么您别无选择，只能使用 C++/CLI。Pinvoke 不能这样做，只有 C++ 编译器知道要分配多少内存以及如何正确转换this实例函数的指针。

The .NET framework contains code that was written in C++/CLI, notably in System.Data and WPF's PresentationCore. If you don't have unmanaged interop needs or don't have to work with a legacy code base then there are few reasons to select C++/CLI. C# or VB.NET are the better choices. C++/CLI's feature set got frozen around 2005, it has no support for more recent additions like lambdas or Linq syntax. Nor does the IDE support many of the bells and whistles available in the C# and VB.NET IDEs. Notable is that VS2010 will initially ship without IntelliSense support for C++/CLI. A bit of a kiss-of-death there.

.NET 框架包含用 C++/CLI 编写的代码，特别是在 System.Data 和 WPF 的 PresentationCore 中。如果您没有非托管互操作需求或不必使用遗留代码库，那么几乎没有理由选择 C++/CLI。C# 或 VB.NET 是更好的选择。C++/CLI 的功能集在 2005 年左右被冻结，它不支持更近的添加项，如 lambdas 或 Linq 语法。IDE 也不支持 C# 和 VB.NET IDE 中提供的许多花里胡哨的功能。值得注意的是，VS2010 最初将不提供对 C++/CLI 的 IntelliSense 支持。那里有点死神之吻。

UPDATE: revived in VS2012, IntelliSense support is back. Not in the least thanks to C++/CX, a language extension that simplifies writing WinRT apps in C++. Its syntax is very similar to C++/CLI. The Windows Forms project templates were removed, the designer however still works. The new debugging engine in VS2012 doesn't support C++/CLI, you have to turn on the "Managed Compatibility Mode" option in Tools + Options, Debugging, General.

更新：在 VS2012 中恢复，IntelliSense 支持又回来了。至少要归功于 C++/CX，这是一种语言扩展，可简化用 C++ 编写 WinRT 应用程序。它的语法与 C++/CLI 非常相似。删除了 Windows 窗体项目模板，但设计器仍然有效。VS2012新的调试引擎不支持C++/CLI，需要在Tools + Options, Debugging, General中开启“Managed Compatibility Mode”选项。

回答by Alexander Gessler

It's indeed mainly intended as intermediate language to easily link .net code with native, unmanaged C++. Do yourself a favour, don't use it if you don't need to. C++/CLI syntax is a mess.

它确实主要用作中间语言，以便轻松地将 .net 代码与本机非托管 C++ 链接起来。帮自己一个忙，如果不需要，请不要使用它。C++/CLI 语法一团糟。

Regarding your second question ... I think today C# is the dominant language in .net, but not everyone likes its style and paradigms. .net's architecture makes adding new languages easy (see F#, which aims at functional programming).

关于你的第二个问题......我认为今天 C# 是 .net 中的主导语言，但并不是每个人都喜欢它的风格和范式。.net 的架构使得添加新语言变得容易（参见 F#​​，它针对函数式编程）。

回答by Benny

for me, i have to use it when there is no other way to reuse c++ class

对我来说，当没有其他方法可以重用 c++ 类时，我必须使用它

回答by t0mm13b

I have not looked at C++/CLI but it harnesses the .NET world - think of it as a in-between C++ and C# where you have the best of both worlds. It could be useful in situations where you want to use C++ that can easily access .NET objects and it's core BCL. Have a look here at this articlediscussing the primers of C++/CLI. Unfortunately, I have not heard of a Managed C++ application as it has ruffled a lot of C++ friends on the syntax side of things and lost gathering of followers who went back to the unmanaged world of C++.

我没有研究过 C++/CLI，但它利用了 .NET 世界 - 将其视为介于 C++ 和 C# 之间的两个领域。在您想要使用可以轻松访问 .NET 对象及其核心 BCL 的 C++ 的情况下，它可能很有用。看看这里这个文章讨论了C ++ / CLI的引物。不幸的是，我还没有听说过托管 C++ 应用程序，因为它在语法方面激怒了很多 C++ 朋友，并失去了回到非托管 C++ 世界的追随者。

Hope this helps, Best regards, Tom.

希望这会有所帮助，最好的问候，汤姆。

回答by Rob van Groenewoud

I've used C++/CLI to create .NET API's for some unmanaged C++ libraries. Passing and marshalling of parameters takes some getting used to (depending on used types), but once you've got the hang of it, it's really a nice way to bridge the gap between the managed and unmanaged world.

我已经使用 C++/CLI 为一些非托管 C++ 库创建了 .NET API。参数的传递和编组需要一些习惯（取决于使用的类型），但是一旦掌握了它，这确实是弥合托管和非托管世界之间差距的好方法。

回答by Clifford

First C# is not a 'derivitive' of .NET. .NET is not a language, it is an application framework and class library based on the CLR, for which a number of languages exist.

首先，C# 不是 .NET 的“衍生物”。.NET 不是一种语言，它是一个基于 CLR 的应用程序框架和类库，存在多种语言。

That said, the most compelling reason to use .NET is that it is a well designed class library and a much easier way to develop for Windows than Win32 or MFC. However I personally decided that I'd rather learn a new language altogether than learn extensions to an old one, and because C# was designed from the ground up to work with .NET, I suggest that is the language of choice for .NET.

也就是说，使用 .NET 的最令人信服的理由是它是一个设计良好的类库，并且比 Win32 或 MFC 更容易为 Windows 进行开发。然而，我个人决定我宁愿完全学习一门新语言而不是学习旧语言的扩展，而且因为 C# 是从头开始设计用于 .NET，我建议它是 .NET 的首选语言。

C++/CLI is useful is you want to use .NET with some legacy code, and I have used it for creating Windows Forms GUIs and gluing them to existing application code. Its other raison d'etreis that it is the only .NET language that supports mixed managed and native code in a single load module, so it is good for both performance and reuse of legacy code.

如果您想将 .NET 与一些遗留代码一起使用，C++/CLI 很有用，我已经用它来创建 Windows 窗体 GUI 并将它们粘合到现有的应用程序代码中。它的另一个存在理由是它是唯一支持在单个加载模块中混合托管代码和本机代码的 .NET 语言，因此它有利于旧代码的性能和重用。

With respect to the number of languages, Microsoft want every Windows application to be based on .NET because it is better for the security and stability of their OS. The only way that will happen is by supporting multiple languages. Think of .NET as an application platform or OS API, and then the question makes less sense; there will be many languages for .NET for the same reason as there are many languages for any platform. Those reasons are many, including commercial advantage, application fit, politics, supporting existing developers, choice and no doubt more.

关于语言的数量，微软希望每个 Windows 应用程序都基于 .NET，因为这有利于其操作系统的安全性和稳定性。唯一会发生的方法是支持多种语言。将 .NET 视为应用程序平台或 OS API，那么这个问题就没有意义了；.NET 将有多种语言，原因与任何平台都有多种语言相同。这些原因有很多，包括商业优势、应用程序适合性、、支持现有开发人员、选择等等。

回答by user230821

Just so you know. Unless you specify the code to be compiled as unmanaged, when compiling with CLR support it will be compiled as managed code.

只要你知道。除非您指定要编译为非托管代码，否则在使用 CLR 支持进行编译时，它将被编译为托管代码。

While CLI C++ is nice. I find it a pain to code in. There is just something about it that makes me not want to program in it. It isn't even the "^". It is like using a broken .net. I spent 40 minutes coding something fully managed in it that took me 10 minutes in C#. I mean, sometimes I just give up and use C# because it frustrates me when coding in it. I mean if you are going to use .net you might as well use C#(over CLI C++).

虽然 CLI C++ 很好。我发现编写代码很痛苦。只是有一些东西让我不想在其中编程。它甚至不是“^”。这就像使用损坏的 .net。我花了 40 分钟编码一些完全由它管理的东西，而我在 C# 中花了 10 分钟。我的意思是，有时我只是放弃并使用 C#，因为它在编码时让我感到沮丧。我的意思是，如果您打算使用 .net，您不妨使用 C#（通过 CLI C++）。

回答by jalf

Microsoft has changed its stance on this a few times. It was originallyintended as a full-fledged language, essentially something that they wanted all native developers to move to, abandoning native C++ as much as possible.

微软在这方面已经改变了几次立场。它最初的目的是作为一种成熟的语言，本质上是他们希望所有本地开发人员转向的语言，尽可能地放弃本地 C++。

Then a few years ago, they realized that this simply wasn't what their customers wanted. Developers who are moving to .NET anyway generally jump to a language like C#, and the rest have reasons to keeptheir code in the native world, so they stay with C++.

几年前，他们意识到这根本不是他们的客户想要的。无论如何迁移到 .NET 的开发人员通常会跳到像 C# 这样的语言，而其他人有理由将他们的代码保留在本地世界中，所以他们继续使用 C++。

So now, Microsoft intends for C++/CLI to be a "bridge" between native C++ code and managed code written in some .NET language. It's no longer a language they recommend you switching your entire codebase to.

所以现在，微软打算让 C++/CLI 成为本地 C++ 代码和用某种 .NET 语言编写的托管代码之间的“桥梁”。它不再是他们建议您将整个代码库切换到的语言。