This question already has an answer here:
这个问题在这里已有答案:
- Is there any advantage to using C++/CLI over either standard C++ or C#? 4 answers
在标准C ++或C#上使用C ++ / CLI有什么好处? 4个答案
I have been working as a native C++ programmer for last few years. Now we are starting a new project from the scratch. So what is your thoughts on shifting to C++\CLI at the cost of losing platform independent code. Are there are any special advantages that one can gain by shifting to C++\CLI?
在过去的几年里,我一直是一名本地C ++程序员。现在我们从头开始一个新项目。那么您对以C ++ \ CLI转移而牺牲平台无关代码的想法是什么?通过转换到C ++ \ CLI可以获得任何特殊优势吗?
8 个解决方案
#1
31
I would recommend the following, based on my experience with C++, C# and .NET:
根据我对C ++,C#和.NET的经验,我建议如下:
- If you want to go the .NET way, use C#.
- If you do not want .NET, use traditional C++.
- If you have to bridge traditional C++ with .NET code, use C++/CLI. Works both with .NET calling C++ classes and C++ calling .NET classes.
如果你想使用.NET方式,请使用C#。
如果您不想使用.NET,请使用传统的C ++。
如果必须将传统C ++与.NET代码桥接,请使用C ++ / CLI。适用于.NET调用C ++类和C ++调用.NET类。
I see no sense in just going to C++/CLI if you don't need it.
如果你不需要它,我认为没有意义去C ++ / CLI。
#2
6
Some questions to consider before switching:
切换前需要考虑的一些问题:
[1] Are you fine with sticking to Windows? There are .NET clones for other OS's, but your app is not going to just run transparently. A complexity you might not need.
[1]你坚持使用Windows吗?有其他操作系统的.NET克隆,但你的应用程序不会只是透明地运行。您可能不需要的复杂性。
[2] Are you considering switching just for the garbage collection support? If so, you can just use some C++ garbage collector libraries. And if you figure out how to leverage std::shared_ptr, you might not feel the need for garbage collectors. An overhead you might not need.
[2]您是否正在考虑转换垃圾收集支持?如果是这样,您可以使用一些C ++垃圾收集器库。如果你弄清楚如何利用std :: shared_ptr,你可能不会觉得需要垃圾收集器。您可能不需要的开销。
[3] Are you considering C++/CLI because of the garbage collection & all the useful .NET classes that you can leverage? If so, why not just switch to c#. C++/CLI is a transitional technology, and it is best not to invest resources in such things. c# is getting pretty mature and usable.
[3]您是否正在考虑C ++ / CLI,因为垃圾收集和您可以利用的所有有用的.NET类?如果是这样,为什么不切换到c#。 C ++ / CLI是一种过渡技术,最好不要在这些事情上投入资源。 c#变得非常成熟和可用。
Personally, I would just stick with C++ ;).
就个人而言,我只会坚持使用C ++;)。
#3
3
Is there any benefit to you? You will likely lose the ablity to switch to another OS.
你有什么好处吗?您可能会失去切换到另一个操作系统的能力。
#4
2
don't bother unless you're integrating with .NET apps. Certainly do not use STL/CLR as its performance is truly awful.
除非您与.NET应用程序集成,否则不要打扰。当然不要使用STL / CLR,因为它的性能确实非常糟糕。
Its tempting to flip that switch to use the .NET class libraries, but there are alternatives. If you do this, you will not be able to port your code so easily.
它倾向于将该开关转换为使用.NET类库,但还有其他选择。如果这样做,您将无法轻松移植代码。
It also seems that the rise of OSS is increasing, so now might be the time to investigate using cross-platform libraries and tools. You can deploy a linux app much more easily than a windows one (by shipping a fully-configured OS!), and you get much better ROI if you deploy linux clients (as they're free).
似乎OSS的兴起正在增加,因此现在可能是调查使用跨平台库和工具的时候了。您可以比Windows一样轻松部署Linux应用程序(通过发布完全配置的操作系统!),如果部署Linux客户端(因为它们是免费的),您可以获得更好的ROI。
If I were a businessman, I would be looking to at least have the capability to deploy on linux or mac than just windows-only. Strategically, I would not want to bet that the world stayed with Microsoft in 5 years time.
如果我是一名商人,我希望至少能够在Linux或Mac上部署,而不仅仅是Windows。从战略上讲,我不想打赌,这个世界在5年后一直与微软保持联系。
#5
2
The main advantage you would get moving to C++/CLI is to get access to the .NET libraries and the framework itself (garbage collection etc.). However, as far as I can tell the main reason C++/CLI exists is to ease the porting of existing C++ code to run in the .NET framework. New projects are encouraged to use C#.
迁移到C ++ / CLI的主要优点是可以访问.NET库和框架本身(垃圾收集等)。但是,据我所知,C ++ / CLI存在的主要原因是为了简化现有C ++代码的移植以便在.NET框架中运行。鼓励新项目使用C#。
If you need to use existing C++ code mixed in with the .NET framework, then it would make sense to use C++/CLI, but in general you should just begin with C#.
如果您需要使用与.NET框架混合的现有C ++代码,那么使用C ++ / CLI是有意义的,但通常您应该从C#开始。
If there is something in .NET that the new project needs to use extensively (maybe simpler GUI design or something), then use C#. if not, then stick with native C++. I don't think you will lose anything by doing that.
如果.NET中存在新项目需要广泛使用的东西(可能是更简单的GUI设计或其他东西),那么使用C#。如果没有,那么坚持使用原生C ++。这样做我认为你不会失去任何东西。
#6
1
I dislike C++/CLI so much that I'd recommend steering clear, as I describe here. Some suggest using C++/CLI as a bridge between standard C++ and C#, but thanks to the way C++/CLI is designed, it is very tedious to use that way (you have to manually create wrappers of normal C++ code that can be called from C#). Therefore, I would recommend SWIG instead for interfacing standard C++ with C# (although admittedly, SWIG has a substantial learning curve).
我不喜欢C ++ / CLI,所以我建议转向清晰,正如我在这里所描述的那样。有人建议使用C ++ / CLI作为标准C ++和C#之间的桥梁,但是由于C ++ / CLI的设计方式,使用这种方式非常繁琐(您必须手动创建可以从中调用的普通C ++代码的包装器) C#)。因此,我建议使用SWIG将标准C ++与C#接口(尽管可以肯定的是,SWIG具有实质性的学习曲线)。
#7
1
Take a look at those two articles:
看看这两篇文章:
A Critical Overview of C++/CLI, Part I
C ++ / CLI的重要概述,第一部分
A Critical Overview of C++/CLI, Part II
C ++ / CLI的重要概述,第二部分
I believe that by now you are convinced as I am that C++/CLI is neither a "set of extensions to C++" (in many aspects it’s actually a subset of C++), nor is it related to C++ more than any other language with semicolons and curly braces. Furthermore, C++/CLI is definitely a Windows-oriented programming language; it’s definitely not a language that a Solaris 10 server or a Nokia mobile phone will be happy to run. What does it have anything to do with C++?
我相信,到现在为止,我确信C ++ / CLI既不是“C ++的一组扩展”(在许多方面它实际上是C ++的一个子集),也不比任何其他带分号的语言更能与C ++相关。和花括号。此外,C ++ / CLI绝对是一种面向Windows的编程语言;它绝对不是Solaris 10服务器或诺基亚手机很乐意运行的语言。它与C ++有什么关系?
#8
0
One main disadvantage of using C++/CLR is the possibility of losing your IP (intellectual Property) if the code is not obscured suficently. In general I agree with the statements made by other members here. If you want portable code independant of the MS .net vm then native C/C++ is the way to go.
使用C ++ / CLR的一个主要缺点是,如果代码没有被严重遮挡,则可能会丢失您的IP(知识产权)。总的来说,我同意其他成员在这里所作的发言。如果您想要与MS .net vm无关的可移植代码,那么本机C / C ++就是您的选择。
#1
31
I would recommend the following, based on my experience with C++, C# and .NET:
根据我对C ++,C#和.NET的经验,我建议如下:
- If you want to go the .NET way, use C#.
- If you do not want .NET, use traditional C++.
- If you have to bridge traditional C++ with .NET code, use C++/CLI. Works both with .NET calling C++ classes and C++ calling .NET classes.
如果你想使用.NET方式,请使用C#。
如果您不想使用.NET,请使用传统的C ++。
如果必须将传统C ++与.NET代码桥接,请使用C ++ / CLI。适用于.NET调用C ++类和C ++调用.NET类。
I see no sense in just going to C++/CLI if you don't need it.
如果你不需要它,我认为没有意义去C ++ / CLI。
#2
6
Some questions to consider before switching:
切换前需要考虑的一些问题:
[1] Are you fine with sticking to Windows? There are .NET clones for other OS's, but your app is not going to just run transparently. A complexity you might not need.
[1]你坚持使用Windows吗?有其他操作系统的.NET克隆,但你的应用程序不会只是透明地运行。您可能不需要的复杂性。
[2] Are you considering switching just for the garbage collection support? If so, you can just use some C++ garbage collector libraries. And if you figure out how to leverage std::shared_ptr, you might not feel the need for garbage collectors. An overhead you might not need.
[2]您是否正在考虑转换垃圾收集支持?如果是这样,您可以使用一些C ++垃圾收集器库。如果你弄清楚如何利用std :: shared_ptr,你可能不会觉得需要垃圾收集器。您可能不需要的开销。
[3] Are you considering C++/CLI because of the garbage collection & all the useful .NET classes that you can leverage? If so, why not just switch to c#. C++/CLI is a transitional technology, and it is best not to invest resources in such things. c# is getting pretty mature and usable.
[3]您是否正在考虑C ++ / CLI,因为垃圾收集和您可以利用的所有有用的.NET类?如果是这样,为什么不切换到c#。 C ++ / CLI是一种过渡技术,最好不要在这些事情上投入资源。 c#变得非常成熟和可用。
Personally, I would just stick with C++ ;).
就个人而言,我只会坚持使用C ++;)。
#3
3
Is there any benefit to you? You will likely lose the ablity to switch to another OS.
你有什么好处吗?您可能会失去切换到另一个操作系统的能力。
#4
2
don't bother unless you're integrating with .NET apps. Certainly do not use STL/CLR as its performance is truly awful.
除非您与.NET应用程序集成,否则不要打扰。当然不要使用STL / CLR,因为它的性能确实非常糟糕。
Its tempting to flip that switch to use the .NET class libraries, but there are alternatives. If you do this, you will not be able to port your code so easily.
它倾向于将该开关转换为使用.NET类库,但还有其他选择。如果这样做,您将无法轻松移植代码。
It also seems that the rise of OSS is increasing, so now might be the time to investigate using cross-platform libraries and tools. You can deploy a linux app much more easily than a windows one (by shipping a fully-configured OS!), and you get much better ROI if you deploy linux clients (as they're free).
似乎OSS的兴起正在增加,因此现在可能是调查使用跨平台库和工具的时候了。您可以比Windows一样轻松部署Linux应用程序(通过发布完全配置的操作系统!),如果部署Linux客户端(因为它们是免费的),您可以获得更好的ROI。
If I were a businessman, I would be looking to at least have the capability to deploy on linux or mac than just windows-only. Strategically, I would not want to bet that the world stayed with Microsoft in 5 years time.
如果我是一名商人,我希望至少能够在Linux或Mac上部署,而不仅仅是Windows。从战略上讲,我不想打赌,这个世界在5年后一直与微软保持联系。
#5
2
The main advantage you would get moving to C++/CLI is to get access to the .NET libraries and the framework itself (garbage collection etc.). However, as far as I can tell the main reason C++/CLI exists is to ease the porting of existing C++ code to run in the .NET framework. New projects are encouraged to use C#.
迁移到C ++ / CLI的主要优点是可以访问.NET库和框架本身(垃圾收集等)。但是,据我所知,C ++ / CLI存在的主要原因是为了简化现有C ++代码的移植以便在.NET框架中运行。鼓励新项目使用C#。
If you need to use existing C++ code mixed in with the .NET framework, then it would make sense to use C++/CLI, but in general you should just begin with C#.
如果您需要使用与.NET框架混合的现有C ++代码,那么使用C ++ / CLI是有意义的,但通常您应该从C#开始。
If there is something in .NET that the new project needs to use extensively (maybe simpler GUI design or something), then use C#. if not, then stick with native C++. I don't think you will lose anything by doing that.
如果.NET中存在新项目需要广泛使用的东西(可能是更简单的GUI设计或其他东西),那么使用C#。如果没有,那么坚持使用原生C ++。这样做我认为你不会失去任何东西。
#6
1
I dislike C++/CLI so much that I'd recommend steering clear, as I describe here. Some suggest using C++/CLI as a bridge between standard C++ and C#, but thanks to the way C++/CLI is designed, it is very tedious to use that way (you have to manually create wrappers of normal C++ code that can be called from C#). Therefore, I would recommend SWIG instead for interfacing standard C++ with C# (although admittedly, SWIG has a substantial learning curve).
我不喜欢C ++ / CLI,所以我建议转向清晰,正如我在这里所描述的那样。有人建议使用C ++ / CLI作为标准C ++和C#之间的桥梁,但是由于C ++ / CLI的设计方式,使用这种方式非常繁琐(您必须手动创建可以从中调用的普通C ++代码的包装器) C#)。因此,我建议使用SWIG将标准C ++与C#接口(尽管可以肯定的是,SWIG具有实质性的学习曲线)。
#7
1
Take a look at those two articles:
看看这两篇文章:
A Critical Overview of C++/CLI, Part I
C ++ / CLI的重要概述,第一部分
A Critical Overview of C++/CLI, Part II
C ++ / CLI的重要概述,第二部分
I believe that by now you are convinced as I am that C++/CLI is neither a "set of extensions to C++" (in many aspects it’s actually a subset of C++), nor is it related to C++ more than any other language with semicolons and curly braces. Furthermore, C++/CLI is definitely a Windows-oriented programming language; it’s definitely not a language that a Solaris 10 server or a Nokia mobile phone will be happy to run. What does it have anything to do with C++?
我相信,到现在为止,我确信C ++ / CLI既不是“C ++的一组扩展”(在许多方面它实际上是C ++的一个子集),也不比任何其他带分号的语言更能与C ++相关。和花括号。此外,C ++ / CLI绝对是一种面向Windows的编程语言;它绝对不是Solaris 10服务器或诺基亚手机很乐意运行的语言。它与C ++有什么关系?
#8
0
One main disadvantage of using C++/CLR is the possibility of losing your IP (intellectual Property) if the code is not obscured suficently. In general I agree with the statements made by other members here. If you want portable code independant of the MS .net vm then native C/C++ is the way to go.
使用C ++ / CLR的一个主要缺点是,如果代码没有被严重遮挡,则可能会丢失您的IP(知识产权)。总的来说,我同意其他成员在这里所作的发言。如果您想要与MS .net vm无关的可移植代码,那么本机C / C ++就是您的选择。