背景介绍：
我想在C++/CLI （属.net）程序中使用一些原有的ANSI/ISO C++(以下将称作 Native C++ )代码，以免以前的C++代码浪费。
Native C++代码中，有些是用模板的形式实现的。
我的编程理念、具体实现步骤以及对这种编程方式的几点思考：
编程理念：在C++/CLI 程序中，透过混合编程（C++/CLI和Native C++）方式生成的DLL，去调用Native C++ 中的代码。 混合编程生成的DLL，只是做简单的函数调用，而不做函数实现（即不重写函数方法体，如果那样的话，那就不用使用Native C++代码了）。
具体实现步骤：
1、将Native C++ 代码放入 CLR 的类库中编译生成 Lib 文件(静态库文件)<请注意：此时的代码是纯 ANSI/ISO C++>；
2、新建一个C++/CLI 类库，引入上述Lib文件，编写调用代码，生成DLL文件（动态库文件）.<请注意：此时的代码既有C++/CLI,又有ANSI/ISO C++，属混合编程，对于生成的DLL文件，姑且让我们现在叫他.net 引导包，以下也都这么称呼>；
3、新建C++/CLI 窗体程序，引入DLL文件以供使用<请注意：此时的代码是纯C++/CLI >
这个思路应该木有问题吧？ANSI/ISO C++ 可以不用修改就可以在CLR 的类库中编译、生成成功。
我留意到现在很多的硬件都支持C#和VB.net开发，他们都是提供.sys 和一个DLL文件，这种实现应该与我的思维有相似之处吧。
对这种编程方式的几点思考：
1、分这么多文件来处理，一个目的就是方便对代码的管理，知道那部分是纯Native C++,哪部分是混合模式等等，到时候修改也方便；
2、这样也有助于程序效率的提升，尽量减少系统在托管于非托管切换工作中的资源消耗；
3、这里虽然做得是混合编程，但也尽量保障局部地区血统的纯正性，只是非混合不可了我们才混合。当然，更多的考虑是程序效率中切换工程中资源消耗问题。
我的问题：
1、以上的构架思路，哪些地方需要修改一下，以使其更加合理？
2、托管与非托管的相互调用的时候，肯定会因为资源的切换而导致效率损耗的问题，能不能给我一点这方面的概念？
3、在封装.net 包的时候，封装模板经常出问题，具体见下面代码，我该如何解决？
------解决方案--------------------
非托管的模版，托管就不要去想调用了