最近将一个系统的源码从VC 6.0移植到VS C++ 2005上，从而得出了一些经验。不同编译平台的代码移植（这里指从低版本的编译器往高版本的编译器之间的代码移植），其移植成本主要由两方面组成，一是系统库的变化产生的成本，如API函数的变化和类成员函数的变化；二是由于在低版本编译器写出的不规范的代码产生的成本（一般而言，高版本的编译器对程序语法的检查更加严格）。分析一下这两方面的成本，前者是我们第三方开发者不可控制的，后者是我们可以控制的，而且后者产生的编译错误更多，花费的时间更多。通过这次移植，我在想：假如我们在使用VC 6.0开发时遵循一些原则，那么移植到VS C++2005上就会方便多了。下面是我总结的一些经验：
1） 尽可能使用标准的C++语法来写C++代码。比如使用标准的C++类型转换符如staic_cast进行类型转换，使用标准C库函数时明确实参类型，比如
long i = 0；
double j = sqrt(i);
上面的两行代码在VC 6.0不会出现编译错误（可能出现一个编译警告），但在VS 2005中会出现使用sqrt函数不明确的错误，为了避免出现这个错误，你最好这样写：
long i = 0;
double j = sqrt(static_cast<double>(i));
2）假如实现相同的功能，优先考虑使用成熟的开源库。因为很多成熟开源库本身有着跨平台的设计，而且编码规范，千锤百炼。之前我在VC 6.0上使用msxml4.dll来读写xml文件，移植到VS 2005上，结果因为VS 2005内置了对xml的支持，所以出现很多类型不明确的错误（msxml,msxml3不同命名空间的冲突）。假如我一开始使用tinyxml、libxml等开源库读写xml文件，到时只需要将这些开源代码拿到VS 2005上编译出新的库文件就可以了。
3）必须设定函数的返回值，没有返回值就设为void类型。如果没有定义函数返回值，VC 6.0会默认为返回int 类型，但VS 2005对此会报错。
4）尽量使用unicode字符集进行编译。这是一条推荐原则。众所周知，VC 6.0默认以多字节字符集进行编译。但《Windows核心编程》告诉我们使用unicode字符集进行编译是有诸多好处的：
a. 简化应用程序本土化的代码转换工作
b. 可以很容易地在不同语言之间进行数据交换
c. 使你能够分配支持所有语言的单个二进制.exe文件和DLL文件。
d. 提高应用程序的运行效率
