过去几年，我一直是本地C ++程序员。现在，我们从头开始一个新项目。因此，我们以丢失平台独立代码为代价，转向C ++ \ CLI的想法是什么。通过转换为C ++ \ CLI，可以获得什么特别的好处吗？

解决方案

我们有什么好处吗？我们可能会失去切换到另一个操作系统的能力。

根据我对C ++ Cand .NET的经验，我将推荐以下内容：

• 如果要使用.NET，请使用C＃。
• 如果我们不希望使用.NET，请使用传统的C ++。
• 如果必须使用.NET代码桥接传统C ++，请使用C ++ / CLI。与.NET调用C ++类和C ++调用.NET类一起使用。

如果我们不需要C ++ / CLI，我认为这没有任何意义。

除非我们要与.NET应用程序集成，否则请不要打扰。当然不要使用STL / CLR，因为它的性能确实很差。

它很想翻转该开关以使用.NET类库，但还有其他选择。如果这样做，我们将无法如此轻松地移植代码。

似乎OSS的兴起也在增加，因此现在可能是时候研究使用跨平台的库和工具了。与Windows相比，我们可以更轻松地部署linux应用程序(通过交付完全配置的OS！)，并且如果部署linux客户端(因为它们是免费的)，则可以获得更高的投资回报。

如果我是商人，那么我将至少希望能够在Linux或者Mac上进行部署，而不仅仅是Windows。从战略上讲，我不敢打赌，微软将在5年内与世界保持一致。

切换之前要考虑的一些问题：

[1]坚持使用Windows是否可以？有用于其他操作系统的.NET克隆，但应用程序将不会透明地运行。我们可能不需要的复杂性。

[2]我们是否正在考虑仅为了垃圾收集支持而切换？如果是这样，我们可以只使用一些C ++垃圾收集器库。而且，如果我们知道如何利用std :: shared_ptr，我们可能会觉得不需要垃圾收集器。我们可能不需要的开销。

[3]我们是否由于垃圾收集和可以利用的所有有用的.NET类而考虑使用C ++ / CLI吗？如果是这样，为什么不切换到c＃。 C ++ / CLI是一种过渡性技术，最好不要在此类事情上投入资源。 cis变得相当成熟和可用。

就个人而言，我只会坚持使用C ++;)。

使用C ++ / CLI的主要优点是可以访问.NET库和框架本身(垃圾收集等)。但是，据我所知，C ++ / CLI存在的主要原因是简化了现有C ++代码在.NET框架中运行的移植。鼓励新项目使用C＃。

如果需要使用与.NET框架混合的现有C ++代码，则使用C ++ / CLI是有意义的，但是通常，我们应该只从C＃开始。

如果.NET中有新项目需要广泛使用的内容(可能是更简单的GUI设计或者其他内容)，请使用C＃。如果不是，则坚持使用本机C ++。我认为这样做不会让我们损失任何东西。

我非常不喜欢C ++ / CLI，因此建议如我在这里描述的那样保持清晰。有人建议使用C ++ / CLI作为标准C ++和C＃之间的桥梁，但是由于C ++ / CLI的设计方式，使用这种方式非常繁琐(我们必须手动创建可以从以下位置调用的普通C ++代码的包装器) C＃)。因此，我建议使用SWIG代替标准C ++与C的接口(尽管公认的是，SWIG的学习曲线很长)。

看一下这两篇文章：

C ++ / CLI关键概述，第一部分

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 ++ / CLR的一个主要缺点是，如果代码没有被足够模糊，可能会丢失IP(知识产权)。总的来说，我同意其他成员在这里的发言。如果我们想要独立于MS .net vm的可移植代码，则本机C / C ++是可行的方法。