基于MFC的DLL开发的一些个人经验

          工作关系，接触Windows下基于MFC的DLL（dynamic link library）的开发比较多一些，用过VS2002的开发环境，也用过VS2010的开发环境，对于C／C++开发而言，VS2002用的是VC7.0 IDE，VS2010用的是VC10.0 IDE. 两个编译环境同时在工作中使用，就免不了有一些移植代码的工作，不同VC版本代码之间的移植网上百度一下，应该比较好找到，有几点想总结一下：

• CString ，string， char ＊之间的转换：

              新建一个VS2010的基于MFC的DLL的工程，默认的编码方式就是Multi-Byte，与之对应的还有unicode编码方式，举个例子简单区别一下，在Multi-Byte下定义一个CString szContent = _T("1234"); 对于字符‘1’，‘2’，‘3’，‘4’而言，它们各占一个byte的内存空间，而同样的定义，在unicode编码方式下占两个byte的内存空间。那么自然而然的，CString 转 string 或者char ＊就分两种情况了，一种是CString 在 Multi-Byte 编码下定义，另一种就是CString 在 unicode 下定义，这两种编码方式下的转换方式是完全不同的，至于为什么会出现这两种编码方式，之前百度过，就不多说了，有兴趣的话自己百度一下就OK了！在项目开发过程中一般用Multi-Byte就可以了，遇到CString， string和 char ＊的转换就会简单很多，之前用了unicode编码，我的转换过程是这样的，CString->std::w_string->std::string,   CString->w_char *-> char *,网上有很多方法啦，大多基于Win32 API 搞定的，也有大神自己写代码转换的，但是网上大多没有提出基于哪一中编码方式，所以用的时候要先搞清楚。

• Win32 API 和标准C／C++库：

         既然是Library的开发，那肯定是要提供header file, 我在做第一个项目的时候遇到这样一个问题，我开发的是Library，在给机器软件组提供的header file中用了一个 CString类型的变量作为函数的入参，我自己当时倒是没觉得有什么不对的，可是机器软件组的同事用的是C#写的界面，在调用我的Library的时候始终没办法搞定这个CString的参数，后来没办法，只能让我给改成string 类型的参数，原因是这样的，CString是MFC 特有的类，属于Win32 API，是微软为了方便windows下的开发自己开发的库，而string 属于标准C／C++库，与平台无关，所以，Header file 中最好不要用到Win32 API ，至于函数的实体或着函数的实现部分是可以使用Win32 API的。另外，MFC 的开发是可以同时使用这两个库的。

• 编译器环境的设置：

        开发Library的同时，一般会写测试程序来验证Library的，这时候我们可以将两个工程放到一个Solution下进行关联，设置编译顺序，启动项，可以在library的工程下设置编译完成后Copy 相关header file，DLL和Lib文件到测试程序相关目录，从而保证测试程序每次都是使用最新的Library，另外，除了相关文件的Copy外，两个工程尽量不要有路径上的关联，以便两个工程可以分开编译运行，因为很多时候我们给出去的只是header file，DLL和Library, 或者相应的EXE，而不是整个源代码。

• 代码的移植问题：

         之前只是从VS2002移植到VS2010成功过，但是从VS2010移植到VS2002可能就要重新建立工程，复制相应＊.c 和＊.h文件了,另外VS2002开发的library链接在VS2010下使用出过问题，据同事说，不能直接链接，经常会出现问题，我这没有机会验证，只能等待进一步学习了。

• 版本管理问题：

        作为新手的我刚开始工作的时候总是对这个问题没有足够的关注，导致之后时常会出现一些问题，比如相应的firmware，library 和测试程序对不上，很多时间都花在这个上面，作为开发者，在开发的过程中我们当然比较清楚我们开发的东西的特点，但是时间一长真的会忘记的，有时候需要修改一个模块一个不注意就影响到了其它模块或是其他版本，尤其是版本比较多的时候，所以版本的管理很重要，虽然没有什么技术上的挑战，但是这个问题一定要注意。