C/C++ 程序的可移植编写要点

　　以前做过两年 C++ 程序移植工作，从 Win32 平台移植到 Linux 平台。大约有上百万行 C/C++代码，历时一年多。

　　在开发 Win32 版本时，已经强调了程序的可植性，无奈 Win32 团队里对 Linux 精通的人比较少，很多问题没有想到，直到后来移植工作开始时，才发现移植并非像想的那样简单。

　　后来，我发现大家对移植工程师都比较轻视，不管是从工资待遇还是管理层的态度来看都是这样。他们往往认为，你们不过是把别人实现好的东西移植过去罢了，你老老实实，按步就班去做就行了，根本不需要丝毫创意。

　　事实并非如此，特别是对于大项目，其中遇到的问题和困难可谓一言难尽。比如前面提到的那个项目，虽然过去好几年了，很多问题我仍然记忆犹新。

　　这里总结一些经验吧，这些经验，无一不是经过大量汗水换来的，有的引起的 BUG 甚至耗费数周时间才查出来。写出来，供类似的项目参考，不用再走这些弯路。

　　1、分层设计，隔离平台相关的代码。

　　就像可测试性一样，可移植性也要从设计抓起。一般来说，最上层和最下层都不具有良好的可移植性。

　　最上层是 GUI，大多数 GUI 都不是跨平台的，如Win32 SDK 和 MFC。最下层是操作系统API，大多部分操作系统API都是专用的。

　　如果这两层的代码散布在整个软件中，那么这个软件的可植性将非常的差，这是不言自明的。

　　那么如何避免这种情况呢？当然是分层设计了：最底层采用 Adapter 模式，把不同操作系统的 API 封装成一套统一的接口。至于封装成类还是封装成函数，要看你采用的 C 还是 C++ 写的程序了。

　　这看起来很简单，其实不尽然（看完整篇文章后你会明白的），它将耗去你大量的时间去编写代码，去测试它们。

　　采用现存的程序库，是明智的做法，有很多这样的库，比如，C 库有 glib（GNOME 的基础类），C++ 库有 ACE（ADAPTIVE Communication Environment）等等，在开发第一个平台时就采用这些库，可以大大减少移植的工作量。

　　最上层采用 MVC 模型，分离界面表现与内部逻辑代码。把大部分代码放到内部逻辑里面，界面仅仅是显示和接收输入，即使要换一套 GUI，工作量也不大。这同时也是提高可测试性的手段之一，当然还有其它一些附加好处。

　　所以即使你采用 QT 或者 GTK+ 等跨平台的 GUI 设计软件界面，分离界面表现与内部逻辑也是非常有用的。若做到了以上两点，程序的可移植性基本上有保障了，其它的只是技术细节问题。

　　2、事先熟悉各目标平台，合理抽象底层功能。

　　这一点是建立在分层设计之上的，大多数底层函数，像线程、同步机制和 IPC 机制等等，不同平台提供的函数，几乎是一一对应的，封装这些函数很简单，实现 Adapter 的工作几乎只是体力活。

　　然而，对于一些比较特殊的应用，如图形组件本身，就拿 GTK+ 来说吧，基于 X Window 的功能和基于Win32的功能，两者差巨大，除了窗口、事件等基本概念外，几乎没有什么相同的，如果不事先了解各个平台的特性，在设计时就精心考虑的话，抽象出来的抽口在另外一个平台几乎无法实现。

　　3、尽量使用标准 C/C++ 函数。

　　大多数平台都会实现 POSIX（Portable Operating System Interface）规定的函数，但这些函数较原生（Native） 函数来说，性能上的表现可能较次一些，用起来也不如原生函数方便。

　　但是，最好不要贪图这种便宜而使用原生函数函数，否则搬起的石头最终会轧到自己的脚。比如，文件操作就用 fopen 之类的函数，而不要用 CreateFile 之类的函数等。

　　4、尽量不要使用 C/C++ 新标准里出现的特性。

　　并不是所有的编译器都支持这些特性，像 VC 就不支持 C99 里面要求的可变参数的宏，VC 对一些模板特性的支持也不全面。为了安全起见，这方面不要太激进了。

　　5、尽量不要使用 C/C++ 标准里没有明确规定的特性。

　　比如你有多个动态库，每个动态库都有全局对象，而且这些全局对象的构造还有依赖关系，那你迟早会遇到麻烦的，这些全局对象构造的先后顺序在标准里是没有规定的。在一个平台上运行正确，在另外一个平台上可能莫明其妙的死机，最终还是要对程序作大量修改。

　　6、尽量不要使用准标准函数。

　　有些函数大多数平台上都有，它们使用得太广泛了，以至于大家都把它们当成标准了，比如 atoi（把字符串转换成整数）、strdup（克隆字符串）、alloca（在栈分配自动内存）等等。不怕一万，就怕万一，除非明白你在做什么，否则还是别碰它们为好。

　　7、注意标准函数的细节。

　　也许你不相信，即使是标准函数，抛开内部实现不论，就其外在表现的差异也有时令人惊讶。这里略举几个例子：

　　（1） int accept（int s， struct sockaddr *addr， socklen_t *addrlen）;addr/ addrlen本来是输出参数，如果是 C++ 程序员，不管怎么样，你已经习惯于初始化所有的变量，不会有问题。如果是 C 程序员，就难说了，若没有初始化它们，程序可能莫名其妙的 crash，而你做梦也怀疑不到它头它。这在 Win32 下没问题，在 Linux 下才会出现。

　　（2）int snprintf（char *str， size_t size， const char *format， 。..）;第二个参数size，在 Win32 下不包括空字符在内，在 Linux 下包括空字符，这一个字符的差异，也可能让你耗上几个小时。

　　（3） int stat（const char *file_name， struct stat *buf）;这个函数本身没有问题，问题出在结构 stat 上，st_ctime 在 Win32 下代表创建（create）时间，在 Linux 下代表最后修改（change）时间。

　　（4）FILE *fopen（const char *path， const char *mode）;在读取二进制文件，没有什么问题。在读取文本文件可要小心，Win32下 自动预处理，读出来的内容与文件实际都长度不一样，在 Linux 则没有问题。

　　8、小心数据标准数据类型。

　　不少人已经吃过 int 类型由 16 位转变成 32 位带来的苦头，这已经是陈年往事了，这里且不谈。

　　你可知道 char 在有的系统上是有符号的，在有的系统是无符号的吗？你可知道 wchar_t 在 Win32 下是 16 位的，在 Linux 下是 32 位的吗？你可知道有符号的 1bit 的位域，取值是 0 和 -1 而不是 0 和 1 吗？这些貌合神离的东东，端的是神出鬼没，一不小心着了它的道。

　　9、最好不要使用平台独有的特性。

　　比如 Win32 下 DLL 可以提供一个 DllMain 函数，在特定的时间，操作系统的 Loader 会自动调用这个函数。这类功能很好用，但最好不要用，目标平台可不能保证有这种功能。

　　10、最好不要使用编译器特有的特性。

　　现代的编译器都做很人性化，考虑得很周到，一些功能用起非常方便。像在 VC 里，你要实现线程局部存储，你都不调用 TlsGetValue /Tls TlsSetValue 之类的函数，在变量前加一个 __declspec（ thread ） 就行了，然而尽管在 pthread 里有类似的功能，却不能按这种方式实现，所以无法移植到 Linux 下。同样 gcc 也有很多扩展，是在 VC 或者其它编译器里所没有的。

　　11、注意平台的特性。

　　比如：在 Win32 下的 DLL 里面，除非明确指明为 export 的函数外，其它函数对外都是不可见的。而在 Linux 下，所有的非 static 的全局变量和函数，对外全部是可见的。这要特别小心，同名函数引起的问题，让你查上两天也不为过。 （1）目录分隔符，在 Win32 下用’//’，在 Linux 下用’/’。

　　（2）文本文件换行符，在 Win32 下用’/r/n’，在 Linux 下用’/n’，在 MacOS 下用’/r’。

　　（3）字节顺序（大端/小端），不同硬件平台的字节顺序可能不一样。

　　（4）字节对齐，在有的平台（如x86）上，字节不对齐，无非速度慢一点，而有的平台（如arm）上，它完全用错误的方式去读取数据，而且不会给你一点提示。若出问题，可能让你一点头绪都没有。

　　12、最好清楚不同平台的资源限制。

　　想必你还记得 DOS 下同时打开的文件个数限制在几十个的情形吧，如今操作系统的功能已经强大多了，但是并非没有限制。比如 Linux 下的共享内存默认的最大值是 4M。

　　若你对目标平台常见的资源限制了然于胸，可能有很大的帮助，一些问题很容易定位。

　　可移植性的问题决不限于以上几种，一方面，即使以前遇到过的问题，部份已经忘记了。

　　另外一方面，还有很多未知的问题，根本没有遇到过。这里算是抛砖引玉吧，请大家补充。

　　编辑：黄飞