我传统上是C ++编码器。在过去的12个月左右的时间里，我一直在进行许多C＃编码，并为C＃的务实方法感到惊讶（一旦我停止尝试对其进行编码，就好像它是“带有垃圾回收的C ++”一样）。
我们最近有一些毕业生，当帮助其中一名毕业生时，我意识到她正在C ++中使用.Net。在问了她为什么之后，她说她“被经理告知要使用C ++”。除了明显的通信问题外，我认为她正在使用.Net，因为这是她接触过的唯一框架。
然后，我遇到了一个高级开发人员的旧项目，该人员还使用C ++驱动Forms前端。现在，这应该是在.Net首次出现时写的，所以我认为这是他学习.Net的学习练习。这只是一个小型实用程序。
在这个应用程序中必须做一些小的修改，在我看来，使用C ++来驱动.Net会让您两全其美。没有垃圾收集或内存安全性，但是由于您正在管理托管框架，因此同样没有真正的速度/优化机会。
因此，我的问题是，人们是否确实将C ++ .Net用于任何大型独立（即非管道式）生产代码，如果是的话，您这样做的原因是什么？我自由地承认，我从未深入研究过C ++ .Net扩展，因此可能对我不利。
Answers:
C ++。NET（或者确切地说是C ++ / CLI）确实具有垃圾回收功能，就像在.NET上运行的所有其他功能一样。为了在保持与C ++适当兼容性的同时实现这一点，它使用了^语法和gcnew用于垃圾收集（'safe'）指针。
C ++ / CLI被许多人所憎恶，与C＃或C ++相比，使用C ++ / CLI更加不愉快，而且比任何一种都更复杂（这是因为它将C ++本身的复杂性带到了表中并增加了工作所需的功能）与.NET混合使用）。即使在单个中型项目的范围内，学习C＃通常也会有所回报。但是，它可以做C＃和本机C ++都做不到的一件事：针对.NET编译现有的C ++，并使它与其他.NET组件通信。
因此，对于从头开始的项目使用C ++ / CLI并没有多大意义-可以使用C ++ / CLI进行的任何与.NET相关的操作也可以在C＃中完成，语法更好，而且不会暴露原始内容也增加了安全性指针默认情况下。它最突出的理由是将现有代码库移植到.NET。一家决定开始使用.NET的公司，但不愿意（或由于资源和时间限制而无法重写）他们迄今为止生产的每个软件，都可以使用C ++ / CLI来保持现有代码库的使用，而只需进行很少的更改，然后用C＃一步一步地重写其系统组件。至少那是理论；我自己从未在实践中见过它，所以我无法说出它的效果如何。
还要注意，C＃本身可以与本机库交互，因此，即使必须使用现有的C ++代码库，也不必针对.NET重新编译它们：通常，通过COM或P / Invoke与它们进行接口是更好的解决方案。