写可移植的C++代码
写可移植的C/C++代码
这里根据自己在实际开发过程中遇到的问题，写一下C++代码的移植问题，希望对大家有一点点帮助。这里假设这些代码可能要在不同的目标平台上编译运行。
系统API
这里所说的系统，是指某个特定的操作系统，系统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等等这些经过“标准”的函数，某一天你的老板突然要求你把 这个系统移植到一个新的嵌入式设备上时，当因系统跑不起来而不得不向老板的嵌入式设备提供商寻求帮助时，但愿他不会很无奈的告诉你，他的设备上根本没有标 准C库。标准库也有不标准的时候，设备不支持，再标准也没用。
STL与模板
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++)
{
//here is some code.
}
Int j = i+100;
}
其实，不同的编译器，差别最大的地方，恐怕还在于对模板的各种特性的支持。
更多移植问题，可参考下面这个博客。
http://blog.csdn.net/robotom/
