我对C++非常熟悉,所以我考虑学习.NET及其所有衍生物(尤其是C#).
一路上我遇到了C++/CLI,我想知道该语言是否有任何特定用途？它只是假设是从原生C++转换为C#的中间语言吗？
突然出现的另一个问题是为什么.NET框架中仍有这么多编程语言？(VB,C++/CLI,C#...)
Han*_*ant 56
是的,C++/CLI具有非常特定的目标用法,语言(及其编译器,最重要的是)使得编写需要与非托管代码互操作的代码变得非常容易.它内置支持托管和非托管类型之间的编组.它曾经被称为IJW(It Just Works),现在称为C++ Interop.其他语言需要使用P/Invoke marshaller,与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年左右被冻结,它不支持更新的内容,如lambdas或Linq语法.IDE也不支持C#和VB.NET IDE中的许多花哨功能.值得注意的是,VS2010最初将在没有支持C++/CLI的IntelliSense的情况下发布.那里有一点亲吻.
更新:在VS2012中恢复,智能感知支持又回来了.至少要归功于C++/CX,这是一种语言扩展,简化了用C++编写WinRT应用程序的过程.它的语法与C++/CLI非常相似.Windows Forms项目模板已删除,但设计师仍然可以使用.VS2012中的新调试引擎不支持C++/CLI,您必须在Tools + Options,Debugging,General中打开"托管兼容模式"选项.
Cli*_*ord 17
首先,C#不是.NET的"派生"..NET不是一种语言,它是一种基于CLR的应用程序框架和类库,存在许多语言.
也就是说,使用.NET最令人信服的理由是它是一个设计良好的类库,比Win32或MFC更容易开发Windows.但是我个人认为我宁愿学习一门新语言而不是学习旧语言的扩展,而且因为C#是从头开始设计的,所以我认为这是.NET的首选语言.
C++/CLI非常有用,您希望将.NET与一些遗留代码一起使用,并且我已经将它用于创建Windows窗体GUI并将它们粘合到现有的应用程序代码中.它的另一个存在理由是它是唯一一种在单个加载模块中支持混合托管和本机代码的.NET语言,因此它对遗留代码的性能和重用都有好处.
关于语言数量,Microsoft希望每个Windows应用程序都基于.NET,因为它更好地保证了操作系统的安全性和稳定性.唯一的方法是支持多种语言.将.NET视为应用程序平台或OS API,然后问题变得不那么有意义了; .NET会有很多种语言,原因与任何平台都有很多种语言一样.这些原因很多,包括商业优势,应用程序适应性,政治性,支持现有开发人员,选择,毫无疑问更多.
jal*_*alf 17
微软已多次改变立场.它原本打算成为一种成熟的语言,基本上是他们希望所有本地开发人员转移到的东西,尽可能地放弃原生C++.
几年前,他们意识到这根本不是客户想要的.无论如何,转向.NET的开发人员通常会跳到像C#这样的语言,其余的人有理由将他们的代码保留在本地世界中,所以他们仍然使用C++.
所以现在,Microsoft打算让C++/CLI成为本机C++代码和用某种.NET语言编写的托管代码之间的"桥梁".它不再是他们建议您将整个代码库切换到的语言.
Ale*_*ler 12
它确实主要用作中间语言,以便轻松地将.net代码与本机非托管C++链接起来.帮自己一个忙,如果你不需要,不要使用它.C++/CLI语法很乱.
关于你的第二个问题......我认为今天C#是.net中的主导语言,但不是每个人都喜欢它的风格和范例..net的架构使得添加新语言变得容易(参见F#,其目的在于函数式编程).
我使用C++/CLI为一些非托管C++库创建.NET API.传递和编组参数需要一些时间来习惯(取决于使用的类型),但是一旦掌握了它,它就是弥合托管和非托管世界之间差距的一种很好的方法.