CLR对我们的项目是很有吸引力。我将在下面作简要说明：

一：它是可以支持所有原生C++代码编译的，这保证如果出现了CLR实在无法解决的问题，我们还有退路。

二：CLR语法和C++很类似，你可以在c++中看到诸如这样的代码

Ref class A

{

              Int                 m_Index;

};

A^ pA = gcnew A;

       怎么样？是不是觉得很熟悉？

三：CLR支持垃圾回收机制

像上面出现的A^ pA = gcnew A;用户根本不用考虑pA的释放问题，这很大程度上能降低开发的压力。（然而gc所带来的效率压力，以及对象析构时序的问题也很让人头痛）

四：运行时异常处理

       开发C++程序的时候，恐怕所有程序员在诸如写越界，指针错误等上面都或多或少的犯过错，导致程序异常而崩溃吧。这样的错误，一旦出现，很多时候都很不好找到和调试，因为C++的出错现场，很可能根本就不代表出错的原因了。比如数组写越界。在一些如内存缓冲区技术下，根本当时不会发生任何错误，那后面运行结果会怎么样呢？这个恐怕只有上帝才知道。但是CLR在这方面做得就很不错，因为一切数据都是object，而不是原生内存对象，编译器在后台作了很多工作，用户的错误数据读写访问，或者句柄的错误使用，都会在案发现场立即显现。

五：成熟丰富的支持库

       在CLR下面写程序，当你using了一些常用的名字空间后，你会发现当你为某个变量或者函数或者类取代有很强功能特征的名字的时候，编译器就开始抱怨了。应为这些名字已经使用过了！你要写得某个功能，大多数在库中已经被人实现了。

这说明什么？CLR的支持库阵容只能用豪华来形容。在它的标准库中，dotnet框架各种运行库都得到了支持，而且还有大量的CLR特有支持。CLR甚至带有大量的模版库。

六：不需要暴露过多的头文件

通常的C++引擎在release的时候，它会需要提供大量的h文件，来让用户知道接口设计和类型原形。缺少这些，哪怕下游用户根本没有使用某些功能，也会可能因为h文件的包含关系，让编译器不知所措，无法工作。而在CLR编译的库文件，这个问题迎刃而解了。在它的释放dll中，可以包含各种函数，类型等的声明。最终用户只需要#using xxx.dll就可以访问xxx.dll中被许可使用的所有接口和功能。如果你愿意，还可以附上用户手册，在Object Explorer中让用户查阅，这听起来简直太美妙了！

       当然，天下没有免费的午餐，这个好用的功能，也会带来重复编译的问题。下面会更具体的说明，但相对来说，它的优点更加显而易见。