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#…)
8 个解决方案
#1
50
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(它只工作)，现在被称为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 this pointer for an instance function.
如果您需要与本机c++、具有实例函数的类进行互操作，并且需要新的和删除关键字来创建/销毁类的实例，那么您只能使用c++ /CLI。Pinvoke不能这样做，只有c++编译器知道要分配多少内存，以及如何正确地为实例函数调用这个指针。
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中。数据和WPF的PresentationCore。如果您没有非托管的内部操作需求，或者不需要使用遗留代码库，那么选择c++ /CLI就没什么理由了。c#或VB。网络是更好的选择。c++ /CLI的特性集在2005年左右被冻结，它不支持最近添加的诸如lambdas或Linq语法。IDE也不支持c#和VB中可用的许多功能。净的ide。值得注意的是，VS2010最初将不支持c++ /CLI的智能感知。有点像死亡之吻。
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中恢复，智能感知支持又回来了。多亏了c++ /CX，这一语言扩展简化了用c++编写WinRT应用程序。它的语法非常类似于c++ /CLI。Windows窗体项目模板被删除，但设计器仍然工作。VS2012中的新调试引擎不支持c++ /CLI，您必须在Tools + Options、debug、General中打开“托管兼容性模式”选项。
#2
16
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'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.
c++ /CLI的有用之处在于，您希望在一些遗留代码中使用. net，我已经将它用于创建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，会有很多语言，就像任何平台都有很多语言一样。这些原因有很多，包括商业优势、应用适合度、政治、支持现有开发人员、选择等等。
#3
15
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.
微软在这方面已经改变了几次立场。它最初的目的是作为一种成熟的语言，本质上是他们希望所有的本地开发人员迁移到，尽可能地放弃本地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 keep their 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语言编写的托管代码之间的“桥梁”。它不再是一种推荐您切换整个代码基的语言。
#4
12
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的主流语言，但并不是所有人都喜欢它的风格和范例。。
#5
8
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。传递和编组参数需要一些习惯(取决于使用的类型)，但是一旦您掌握了它的用法，这确实是一种很好的方式来弥合托管和非托管世界之间的差距。
#6
5
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++.
我没有研究过c++ /CLI，但它利用了。net世界——可以把它看作是c++和c#之间的中间部分，在这两个世界中您都是最好的。在您希望使用c++的情况下，它可能很有用，因为c++可以轻松访问。net对象，而且它是核心的BCL。请看这篇讨论c++ /CLI引物的文章。不幸的是，我还没有听说过托管c++应用程序，因为它在语法方面惹恼了很多c++的朋友，也失去了回到c++这个非托管世界的追随者。
Hope this helps, Best regards, Tom.
祝你好运，汤姆。
#7
0
for me, i have to use it when there is no other way to reuse c++ class
对于我来说，当没有其他方法重用c++类时，我必须使用它
#8
-5
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++)。
#1
50
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(它只工作)，现在被称为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 this pointer for an instance function.
如果您需要与本机c++、具有实例函数的类进行互操作，并且需要新的和删除关键字来创建/销毁类的实例，那么您只能使用c++ /CLI。Pinvoke不能这样做，只有c++编译器知道要分配多少内存，以及如何正确地为实例函数调用这个指针。
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中。数据和WPF的PresentationCore。如果您没有非托管的内部操作需求，或者不需要使用遗留代码库，那么选择c++ /CLI就没什么理由了。c#或VB。网络是更好的选择。c++ /CLI的特性集在2005年左右被冻结，它不支持最近添加的诸如lambdas或Linq语法。IDE也不支持c#和VB中可用的许多功能。净的ide。值得注意的是，VS2010最初将不支持c++ /CLI的智能感知。有点像死亡之吻。
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中恢复，智能感知支持又回来了。多亏了c++ /CX，这一语言扩展简化了用c++编写WinRT应用程序。它的语法非常类似于c++ /CLI。Windows窗体项目模板被删除，但设计器仍然工作。VS2012中的新调试引擎不支持c++ /CLI，您必须在Tools + Options、debug、General中打开“托管兼容性模式”选项。
#2
16
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'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.
c++ /CLI的有用之处在于，您希望在一些遗留代码中使用. net，我已经将它用于创建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，会有很多语言，就像任何平台都有很多语言一样。这些原因有很多，包括商业优势、应用适合度、政治、支持现有开发人员、选择等等。
#3
15
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.
微软在这方面已经改变了几次立场。它最初的目的是作为一种成熟的语言，本质上是他们希望所有的本地开发人员迁移到，尽可能地放弃本地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 keep their 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语言编写的托管代码之间的“桥梁”。它不再是一种推荐您切换整个代码基的语言。
#4
12
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的主流语言，但并不是所有人都喜欢它的风格和范例。。
#5
8
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。传递和编组参数需要一些习惯(取决于使用的类型)，但是一旦您掌握了它的用法，这确实是一种很好的方式来弥合托管和非托管世界之间的差距。
#6
5
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++.
我没有研究过c++ /CLI，但它利用了。net世界——可以把它看作是c++和c#之间的中间部分，在这两个世界中您都是最好的。在您希望使用c++的情况下，它可能很有用，因为c++可以轻松访问。net对象，而且它是核心的BCL。请看这篇讨论c++ /CLI引物的文章。不幸的是，我还没有听说过托管c++应用程序，因为它在语法方面惹恼了很多c++的朋友，也失去了回到c++这个非托管世界的追随者。
Hope this helps, Best regards, Tom.
祝你好运，汤姆。
#7
0
for me, i have to use it when there is no other way to reuse c++ class
对于我来说，当没有其他方法重用c++类时，我必须使用它
#8
-5
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++)。