这里根据自己在实际开发过程中遇到的问题，写一下C++代码的移植问题，希望对大家有一点点帮助。这里假设这些代码可能要在不同的目标平台上编译运行。

这里所说的系统，是指某个特定的操作系统，系统API，也就是操作系统相关的API。

谈到C++代码的移植，最先想到的问题就是用了哪些系统相关的API。 一般的思路是，找出系统中用了哪些系统的API，然后评估这些API实现的功能在新系统中能否找到替代的API，如果没有，则要看看能否在新系统中实现这些API。

 看到这里，你也许在想，以后我还是尽量少用点系统API的好。你说的对，的确是这样的，为了让你的C++代码比较容易的移植，请尽量少用点系统API。尽量只用一些各种操作系统都会实现的最基础的系统API。个别系统扩展后的貌似功能很强大的系统API，还是尽量少用为妙。很难想象如何把Windows中的目录服务或者ActiveX有关函数移植到一个linux系统上。最基础的系统API，本人理解的，应该是在操作系统课本中写的那些东西，比如进程/线程管理，如创建线程等，同步与通讯，如mutex, semaphore,MQ等，文件管理，一般的有文件读写，可能还会有目录扫描等。图形系统可能还会有GDI方面的，比如几何图形绘制，文本绘制，画笔，画刷等。网络系统可能还会有SOCKET上的操作。

 标准库是指标准C库和C++库。有人也许会问，难道标准的C库也不同用吗？这样问是有道理的。大多数桌面系统，或者服务器系统，都支持标准库。有不支持的吗？回答是肯定的。嵌入式设备上的系统开发多了，就可能会碰到这样的问题。对于某些嵌入式设备来讲，存储空间是极其有限的，以致于难以承受在这些设备看来近乎“庞然大物”的标准库。假如你的系统的C++代码中到处可见fopen/fclose/fread/fwrite和string 等等这些经过“标准”的函数，某一天你的老板突然要求你把这个系统移植到一个新的嵌入式设备上时，当因系统跑不起来而不得不向老板的嵌入式设备提供商寻求帮助时，但愿他不会很无奈的告诉你，他的设备上根本没有标准C库。标准库也有不标准的时候，设备不支持，再标准也没用。

 

 其实STL也是标准C++库的一部分，这里单独提出来，可能有人忍不住要说，STL很熟啊，不就一大堆源代码吗，不就一堆模板吗？不用什么系统支持，也不用设备支持，只要编译器支持模板，编译一下不就完了，有什么值得提的。STL问题的关键就在这个编译上。其实除了这两个支持，还有个编译环境支持不支持的问题。STL使用了许多模版方面的特性，对编译器还是有一定的要求的，更何况，有一些编译环境中，根本就没有STL的这些源码,让人更不敢随便使用STL了。一句话，STL并不是编译器支持模板就能用的。

模板本身没有错，见过一些高手写的恰到好处的模板的应用，的确值得称道，但是，过于复杂的模板还是可能降低代码的可读性。

编译器之间的差别还是不容忽视的。

同样一段代码，在VC下编译能通过，在GCC/G++下可能不一定能过，更不用说ARMCC/ARM-LINUX-C++这些了。就算同羊是Microsoft的编译器，随着版本的升级换代，特性也有较大的不同。在VC6下能编译过的，不一定能在VC2003/VS2005下能过，也不一定能在EVC3/4下能过。

FOR循环就是一个最简单的例子。

Void test_for_loop()

{

 For(int i=0; i<10;i++)

 {

}

Int j = i+100;

}