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

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.注意标准函数的细节。也许你不相信，即便是标准函数，抛开内部实现不论，就其外在表现的差别也有时使人惊讶。这里略举几个例子： 　　int accept(int s, struct sockaddr *addr, socklen_t *addrlen);addr/ addrlen原本是输出参数，若是是C++程序员，无论怎么样，你已经习惯于初始化全部的变量，不会有问题。若是是C程序员，就难说了，若没有初始化它们，程序可能莫名其妙的crash，而你作梦也怀疑不到它头它。这在Win32下没问题，在Linux下才会出现。 　　int snprintf(char *str, size_t size, const char *format, ……);第二个参数size，在Win32下不包括空字符在内，在Linux下包括空字符，这一个字符的差别，也可能让你耗上几个小时。 　　int stat(const char *file_name, struct stat *buf);这个函数自己没有问题，问题出在结构stat上，st_ctime在Win32下表明建立(create)时间，在Linux下表明最后修改 (change)时间。 　　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的全局变量和函数，对外所有是可见的。这要特别当心，同名函数引发的问题，让你查上两天也不为过。 　　目录分隔符，在Win32下用‘\\’，在Linux下用‘/’。 　　文本文件换行符，在Win32下用‘\r\n’，在Linux下用‘\n’，在MacOS下用‘\r’。 　　字节顺序（大端/小端），不一样硬件平台的字节顺序可能不同。 　　字节对齐，在有的平台(如x86）上，字节不对齐，无非速度慢一点，而有的平台（如arm）上，它彻底用错误的方式去读取数据，并且不会给你一点提示。若出问题，可能让你一点头绪都没有。 　　12.最好清楚不一样平台的资源限制。想必你还记得DOS下同时打开的文件个数限制在几十个的情形吧，现在操做系统的功能已经强大多了，可是并不是没有限制。好比Linux下的共享内存默认的最大值是4M。若你对目标平台常见的资源限制了然于胸，可能有很大的帮助，一些问题很容易定位。