有多少人在使用C++/CLR?

在VS2005的时候，我在项目中使用了C++/CLI，我的程序主体是VC++的，我是个典型的C++爱好者，但是，为什么要增加个C++/CLI呢？我希望增加软件的二次开发功能，希望让C++程序支持脚本，想了很多办法，试了很多方案，最终确定了C++/CLI，因为这样，我们完全可以在一个MFC程序中，通过C#或VB的脚本进行扩张，通过标准的.NET开发工具开发插件，这个程序现在还在用，真正的具有二次开发功能。

楼主，我现在就在用C++/CLR做一个小转化，原因是什么呢，我的底层算法用的是C++ ，据说速度是比较快哈，是吧，But界面用的是C#，这就蛋疼了，使咱不得不想想可以托管的玩意，就选择了C++/CLR……

c++/cli是用来为native的c++做wrapper的。。虽然c#有了p/invoke，但是想与已有的c++库做交互还是有点麻烦的，尤其是一些大型的库，你要把封装好的类拆成一个个孤立的函数，这个时候c++/cli就是个很好的选择，直接做一个简单的封装，一个native的类就变成一个clr的类了，对外接口几乎保持不变，然后再用c#、vb.net去调就轻松多了

本人现在使用C++/CLI，主要是为了将以前的工程移植到.net体系下，在融汇贯通方面C++/CLI确实很强大，避免了以前写大量的
P/Invoke代码，能将以前的库很好的重用，基本上不需要什么改变。

至于在性能方面，与以前的纯C++的差别不是很大。不过，这个东西也不推荐大量使用，由于vs的智能提示在C++/CLI中特别弱智，托管和非托管代码混杂，代码量一大，维护问题非常突出。最好是将一些关键地方用C++/CLI封装出来，在C#中调用。

其实在vc中使用wpf也是同一个道理：想使用wpf，但不想用C#。

我也没用过C++/CLR~~~最近还在研究MFC呢，不过现在也开始对C#和.NET有些兴趣。我觉得未来windows程序高级的肯定会是用C#，低级的（是指相对更接近于底层的意思）还是会用winAPI和MFC，至于C++/CLR就是个连接过度的吧~~~很多东西只有需要用的时候再去用的吧