如何编写易于移植的C++ 程序.docVIP

如何编写易于移植的C++ 程序 由于操作系统的差异，同一种操作系统本身版本的差异，目前C++标准库提供的功能仍然有限以及C++编译器产品不是完全兼容等问题，使得我们在移植大型应用程序的时 候往往会出现很多难以解决的问题，如何合理的避免他们提高C++程序的移植性，本文作者从源代码的组织安排等方面提出了一些实用的 建议。 ? 当我们编写服务器端的软件产品时，我们往往需要为同一个软件产品 推出多种不同平台版本。这是因为目前还没有哪个服务器操作系统可以一统天下。有不少服务器运行Windows 操作系统，但运行Linux 和各种UNIX操作系统的服务器也很多，而且各种UNIX操作系统之间又有细微的差别。另外，在一些大企业（特别是大银 行）中，运行关键业务的服务器往往是IBM 的大型机，它们的操作系统又会和一般的UNIX 有一些不同。 此外，软件依赖的中间件，调用的函数库，要求的编译器，都可看作 平台的一部分。上述内容的任意组合会造成大量的可能性。如果平台移植性做得不好，那么很可能软件在你的开发环境能正常运行，但拿到客户的环境中会出现各种 奇奇怪怪的问题。 或许你会说，这些都不是问题，用Java来写程序不就一切OK了？不幸的是，有时候一些遗产代码是用C写的，或者你必须依赖的某个关键函数库只提供了C API，经过评估又发现用Java重写，或者通过JNI以及其他可能的跨语言调用机制去封装这些遗产代码或者C API的工作量太大。那么这时候C++往往是更合适的选择。 用Java写程序可以跨平台的一大原因是Java有一个无所不包的标准库，而C++的标准库只提供了最基本的一些功能。要用C++写比较大的程序几乎一定会调用到标准库之外的API，而这些API未必可以跨平台。所以，编写易于移植的C++程序要注意的第一点是：如果能有选择，那么尽可能地使用跨平台的API。 比如，同样是对文件操作，Win 32 API 和UNIX 操作系统提供的文件操作函数各不相同，选哪个呢？都不合适，最好 还是依赖标准库，fstream或者fopen/fclose都可以。要创建线程并进行线程间同步，Win 32 API 和UNIX 的做法又不一样。有没有跨平台的解决方案呢？有的，pthreads是跨平台的。如果你的系统需要有对字符串进行操作，是用MFC提供的CString还是标准库中的string呢？显然应该选后者，因为MFC 不是跨平台的。 那么，如果你不得不用到的某些API 没有跨平台的实现，只有各个平台自己的实现，怎么办呢？举个例 子，在Windows 平台，加载动态库是调用LoadLibrary；在UNIX平台，加载动态库是调用dlopen。似乎没有什么跨平台的实现。那么我们怎么办？可不可以在每处要 加载动态库的地方都这么写？ #ifdef WIN32 HMODULE h = LoadLibrary(“libraryname”); #elif defined(UNIX) int h = dlopen(“libraryname”, RTLD_LAZY); #endif ? 不少软件就 是这么做的。但这样做很糟糕，因为把平台相关代码同其他的平台独立代码混在了一起，而且代码中会散布很多的#ifdef，影响阅读；而且如果稍后需要把代码移植到另一个平台，那么可能 需要修改每一处加载动态库的地方，增加一个#elif defined(?)，工作量会比较大。 推荐的做法是：自己封装一个跨平台的实现，在平台独立代码中只调 用这个跨平台的API，把平台相关性隔离出去。当然，这层封装应该是很薄的，应该只需要用一两行的inline 函数以及几个typedef 即可。这样做的指导思 想是，通过封装来增加间接层次，从而把平台独立代码和平台相关代码分离。 下面来看一下，这样做是不是可以了呢？ 在main.cpp 中（假设我们需要在这个文件中加载动态库）这样写： #include “platform_specific.hpp” int main() { handle_t h = MyLoadLibrary(libraryname); // 之后使用动态库，然后卸载 } 　 在platform_specific.hpp 中这样写： #ifdef WIN32 typedef HMODULE /* WIN32 handle type */ handle_t; inline handle_t MyLoadLibrary(const string libname) { return LoadLibrary(libname.c_str()); } #elif defined(UNIX) typedef int /* UNIX handle type */ handle_t; inline handle_t MyL