C++/CLI：为什么我应该使用它？
我对 C++ 非常熟悉，因此我考虑学习 .NET 及其所有衍生产品（尤其是 C#）。
一路上我接触到了 C++/CLI，我想知道该语言是否有任何特定用途？它只是被认为是从本机 C++ 转换为 C# 的中间语言吗？
我脑海中浮现的另一个问题是为什么 .NET 框架中仍然有这么多编程语言？ （VB、C++/CLI、C#...）
I'm pretty familiar with C++, so I considered learning .NET and all its derivatives (especially 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#?
Another question that popped to my head is why are there still so many programming languages in .NET framework? (VB, C++/CLI, C#...)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
是的，C++/CLI 有一个非常具体的目标用法，该语言（及其编译器，最重要的是）使得编写需要与非托管代码互操作的代码变得非常容易。它具有对托管和非托管类型之间封送的内置支持。它曾经被称为 IJW（It Just Works），现在被称为 C++ Interop。其他语言需要使用 P/Invoke 编组器，与 C++/CLI 相比，它可能效率低下且功能有限。
如果您需要与本机 C++、具有实例函数的类进行互操作，并且需要 new 和 delete 关键字来创建/销毁该类的实例，那么您别无选择，只能使用 C++/CLI。 Pinvoke 无法做到这一点，只有 C++ 编译器知道要分配多少内存以及如何正确调用实例函数的
this指针。.NET 框架包含用 C++/CLI 编写的代码，特别是在 System.Data 和 WPF 的PresentationCore 中。如果您没有非托管互操作需求或不必使用遗留代码库，那么选择 C++/CLI 的理由很少。 C# 或 VB.NET 是更好的选择。 C++/CLI 的功能集在 2005 年左右被冻结，它不支持最近添加的功能，例如 lambda 或 Linq 语法。该 IDE 也不支持 C# 和 VB.NET IDE 中提供的许多功能。值得注意的是，VS2010 最初发布时不提供对 C++/CLI 的 IntelliSense 支持。那里有点死亡之吻。
更新：在 VS2012 中恢复，IntelliSense 支持又回来了。这一点要归功于 C++/CX，这是一种语言扩展，可以简化用 C++ 编写 WinRT 应用程序的过程。它的语法与 C++/CLI 非常相似。 Windows 窗体项目模板已被删除，但设计器仍然可以工作。 VS2012中新的调试引擎不支持C++/CLI，你必须在“工具+选项”、“调试”、“常规”中打开“托管兼容模式”选项。
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.
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.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.
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.
首先，C# 不是 .NET 的“衍生品”。 .NET 不是一种语言，它是一个基于 CLR 的应用程序框架和类库，存在多种语言。
也就是说，使用 .NET 最令人信服的原因是它是一个设计良好的类库，并且是比 Win32 或 MFC 更容易的 Windows 开发方法。不过，我个人决定，我宁愿学习一门新语言，也不愿学习旧语言的扩展，并且因为 C# 是从头开始设计的，旨在与 .NET 一起使用，所以我建议这是 .NET 的首选语言。
如果您想要将 .NET 与一些遗留代码一起使用，C++/CLI 很有用，我已使用它来创建 Windows 窗体 GUI 并将它们粘合到现有应用程序代码。它存在的另一个理由是，它是唯一在单个加载模块中支持混合托管代码和本机代码的 .NET 语言，因此它对于性能和遗留代码的重用都有好处。
在语言数量方面，微软希望每个Windows应用程序都基于.NET，因为这更有利于其操作系统的安全性和稳定性。实现这一目标的唯一方法是支持多种语言。将 .NET 视为应用程序平台或操作系统 API，那么这个问题就没有意义了； .NET 将会有多种语言，就像任何平台都有多种语言一样。这些原因有很多，包括商业优势、应用程序契合度、政治、支持现有开发人员、选择等等。
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.
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.
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'etre is 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.
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.
微软对此的立场已多次改变。它最初的目的是作为一种成熟的语言，本质上是他们希望所有本机开发人员转向的东西，尽可能放弃本机 C++。
几年前，他们意识到这根本不是他们的客户想要的。无论如何，转向 .NET 的开发人员通常会转向 C# 等语言，而其他人则有理由将其代码保留在本机世界中，因此他们继续使用 C++。
因此，现在，Microsoft 打算让 C++/CLI 成为本机 C++ 代码和用某种 .NET 语言编写的托管代码之间的“桥梁”。他们不再建议您将整个代码库切换到这种语言。
Microsoft has changed its stance on this a few times. It was originally intended as a full-fledged language, essentially something that they wanted all native developers to move to, abandoning native C++ as much as possible.
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 keep their code in the native world, so they stay with 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.
它确实主要作为中间语言来轻松地将 .net 代码与本机非托管 C++ 链接起来。帮自己一个忙，如果不需要就不要使用它。 C++/CLI 语法很混乱。
关于你的第二个问题......我认为今天 C# 是 .net 中的主导语言，但并不是每个人都喜欢它的风格和范例。 .net 的架构使得添加新语言变得容易（请参阅 F#，它旨在函数式编程）。
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.
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++/CLI 为一些非托管 C++ 库创建 .NET API。参数的传递和编组需要一些时间来适应（取决于所使用的类型），但是一旦掌握了它的窍门，这确实是弥合托管和非托管世界之间差距的好方法。
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，但它利用了 .NET 世界 - 将其视为 C++ 和 C# 之间的中间体，您可以在其中获得两个世界的优点。当您想要使用可以轻松访问 .NET 对象及其核心 BCL 的 C++ 的情况下，它可能很有用。请查看这篇讨论 C++/CLI 入门知识的文章。不幸的是，我还没有听说过托管 C++ 应用程序，因为它在语法方面激怒了很多 C++ 朋友，并失去了回到非托管 C++ 世界的追随者。
希望这有帮助，
此致，
汤姆.
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 article discussing 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++.
Hope this helps,
Best regards,
Tom.
这篇文章很旧，但我认为缺少最重要的信息：您可以使用它来查看和操作在 C# 中使用的 C++ 框架的源代码。示例：您不使用编译的 OpenCV 二进制文件，而是在解决方案中获取 OpenCV 源代码，并且可以添加一些简单的扩展，或者深入检查某些行为如何存在。或者在金融数学中，您可以使用 QuantLib Sources，等等。这比已经编译的在很多方面充当黑匣子的库要好得多。 .NET 中的 C++/Cli 解决了这个问题。
This post is old but the most important message in my oppinion is missing: You use it for being able to see and manipulate the source code of C++ frameworks you use in C#. Examples: You don't use compiled OpenCV binaries, instead you got the OpenCV sourcecode in your solution and can add simple some Extensions, or deep check how some behavior exists. Or in finanicial math you could QuantLib Sources, and so on. This is much better than having already compield libraries that act as black boxes in a lot of ways. C++/Cli in .NET solves this.
对我来说，当没有其他方法重用 C++ 类时，我必须使用它
for me, i have to use it when there is no other way to reuse c++ class
只是让你知道。除非您指定要编译为非托管代码，否则在使用 CLR 支持进行编译时，它将被编译为托管代码。
虽然 CLI C++ 很好。我发现编写代码很痛苦。有一些东西让我不想在其中编程。它甚至不是“^”。这就像使用损坏的.net。我花了 40 分钟编写了一些完全托管的代码，而我在 C# 中花了 10 分钟。我的意思是，有时我会放弃并使用 C#，因为用它编写代码时它让我感到沮丧。我的意思是，如果您要使用 .net，您不妨使用 C#（而不是 CLI C++）。
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.
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++).