写可移植的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/