我已经与C＃广泛合作，但是，我正在开始一个项目，我们的客户希望所有代码都用C ++而不是C＃编写。该项目将是托管（.NET 4.0）和本机C ++之间的混合。因为我一直喜欢C＃到C ++以满足我的.NET需求，我想知道在使用C＃和托管C ++之间是否存在任何重要的差异？
非常感谢对此的任何见解。
编辑查看维基百科的托管C ++代码表明新规范是C ++ / CLI，并且不推荐使用“托管C ++”。更新了标题以反映这一点。
答案 0 :(得分：9)
C ++ / CLI是一种完整的.NET语言，就像其他.NET语言一样，它在托管上下文中运行良好。就像在C＃中使用本机调用一样，在本机C ++和托管C ++中交错可能会导致一些问题。话虽如此，如果您正在使用大量本机C ++代码，我宁愿使用C ++ / CLI而不是C＃。有很多问题可以通过编写C ++ / CLI来解决，就像你编写C＃一样，也不像编写本机C ++那样编写它。这是它自己的事情。
我参与了几个C ++ / CLI项目，我采取的方法实际上取决于应用程序的不同级别对本机C ++代码的暴露程度。如果应用程序的大多数核心是本机的，并且本机代码和托管代码之间的集成点有点模糊，那么我将始终使用C ++ / CLI。 C ++ / CLI中控件的好处将超过其问题。如果你确实有明确的交互点可以调整或抽象，那么我强烈建议创建一个C ++ / CLI桥接层，上面有C＃和C ++。这样做的主要原因是C＃工具比C ++ / CLI的相应工具更成熟，更普遍。话虽如此，我一直在努力的项目取得了成功，并不是另一个指向的噩梦。
我还要确保您了解客户为何朝着这个方向前进。如果他们的想法是他们有一堆C ++开发人员并且他们希望让他们更容易编写托管代码，我会向客户提出，学习C＃可能比学习C ++ / CLI更具挑战性。
如果客户端认为C ++ / CLI更快，那就是错误，因为它们都编译成IL。但是，如果客户端具有大量现有或正在进行的本机C ++开发，那么当前路径实际上可能是最佳的。
答案 1 :(得分：3)
我用C ++ / CLI完成了一个项目，我不得不说这是一个令人厌恶的。基本上它是一个WinForms应用程序来管理员工，曲棍球游戏，团队之间的交易，日历等等......
因此，您可以想象我在表单上拥有的托管控件的数量：日历/日期时间选择器，组合框，网格等。
最糟糕的部分是我的后端只使用C ++类型，并使用托管类型作为前端。首先，您无法将std字符串分配给托管字符串。你需要转换一切。显然你必须把它转换回来......
每当我需要填充网格时，我将我的C ++集合序列化为类似vector<std::string>的东西，在我的UI库中检索它，然后通过它循环并创建新的DataGridRow将它们添加到网格中。显然可以使用C＃和一些Linq to SQL在3分钟内完成。
我最终得到了该应用程序的A +，但说实话它绝对是糟透了。我无法想象其他应用程序对我来说是多么可怜。
我认为如果我在我的C ++中使用List<Customer>^（某个对象的托管列表）而不是总是在字符串向量之间转换所有内容会更容易。但我需要保持C ++清理托管的东西。
/ pissedof
答案 2 :(得分：2)
从使用所有这三个方面（.NET，C ++ / CLI和C ++）我可以说，无论如何我更喜欢使用.NET（通过C＃或VB.NET）。对于应用程序，您可以使用WinForms或WPF（我发现后者更好 - 特别是对于看起来更加用户友好的应用程序）。
C ++ / CLI的一个主要问题是，您没有在.NET中获得的所有优秀语言功能。例如，C＃中的yield关键字和lambda的使用（我不认为C ++ / CLI支持这种关键字 - 不要让我这样做。）
然而，C ++ / CLI有一个很大的优势。也就是说，您可以创建一个桥接以允许C＃和C ++进行通信。我目前正在开发一个项目，其中许多数学计算和算法已经在C ++中编写（多年），但该公司希望转向基于.NET的用户界面。在研究了各种解决方案之后，我得出的结论是C ++ / CLI对此更好。一个好处是它允许我构建一个API，对于.NET开发人员来说，它看起来像.NET类型一样工作。
但是，对于开发应用程序的前端，我真的不推荐使用C ++ / CLI。从可用性的角度来看（就使用它时的开发人员时间而言）它是不值得的。一个大问题是VS2010 dropped support for IntelliSense for C++/CLI以便改善通用智能感知系统。 （我特意认为是C ++）。如果您还没有尝试过，我肯定会建议您查看WPF的应用程序。