C++的可移植性和跨平台开发（长文）

c++lass="markdown_views">概述 

　　今天聊聊c++的可移植性问题。如果你平时使用c++进行开发，并且你对c++的可移植性问题不是非常清楚，那么我建议你看看这个系列。即使你目前没有跨平台开发的需要，了解可移植性方面的知识对你还是很有帮助的。
　　c++的可移植性这个话题很大，包括了编译器、操作系统、硬件体系等很多方面，每一个方面都有很多内容。鉴于本人能力、精力都有限，只能介绍每一个方面最容易碰到的问题，供大伙儿参考。
　　后面我会分别从编译器、c++语法、操作系统、第三方库、辅助工具、开发流程等方面进行介绍。
编译器
　　在跨平台的开发过程中，很多问题都和编译器有关。因此我们先来聊聊编译器相关的问题。
编译器的选择
　　首先，gcc是优先要考虑支持的，因为几乎所有操作系统平台都有gcc可用。它基本上成了一个通用的编译器了。如果你的代码在a平台的gcc能够编译通过，之后拿到b平台用类似版本的gcc编译，一般也不会有太大问题。因此gcc是肯定要考虑支持的。
　　其次，要考虑是否支持本地编译器。所谓本地编译器就是操作系统厂商自产的编译器。例如：相对于windows的本地编译器就是visual c++。相对于solaris的本地编译器就是sun的cc。如果你对性能比较敏感或者想用到某些本地编译器的高级功能，可能就得考虑在支持gcc的同时也支持本地编译器。
编译警告
编译器是程序员的朋友，很多潜在的问题（包括可移植性），编译器都是可以发现并给出警告的，如果你平时注意这些警告信息，可以减少很多麻烦。因此我强烈建议：
1把编译器的警告级别调高；
2不要轻易忽略编译器的警告信息。
交叉编译器
　　交叉编译器的定义参见“维基百科”。通俗地说，就是在a平台上编译出运行在b平台上的二进制程序。假设你要开发的应用是运行在solaris上，但是你手头没有能够运行solaris的sparc机器，这时候交叉编译器就可以派上用场了。一般情况下都使用gcc来制作一个交叉编译器，限于篇幅，这里就不深入聊了。有兴趣的同学可以参见“这里”。
异常处理
　　上一个帖子“语法”由于篇幅有限，没来得及聊异常，现在把和异常相关的部分单独拿出来说一下。
小心new分配内存失败
　　早期的老式编译器生成的代码，如果new失败会返回空指针。我当年用的borland c++ 3.1似乎就是这样的，现在这种编译器应该不多见了。如果你目前用的编译器还有这种行为，那你就惨了。你可以考虑重载new操作符来抛出 bad_alloc异常，便于进行异常处理。
稍微新式一点的编译器，就不是仅仅返回空指针了。当new操作符发现内存告急，按照标准的规定（参见c++ 03标准18.4.2章节），它应该去调用new_handler函数（原型为typedef void (*new_handler)();）。标准建议new_handler函数干如下三件事：
1、设法去多搞点内存来；
2、抛出bad_alloc异常；
3、调用abort()或者exit()退出进程。
由于new_handler函数是可以被重新设置的（通过调用set_new_handler），所以上述的行为它都可能有。
综上所述，new分配内存失败，有可能三种可能：
1、返回空指针；
2、抛出异常；
3、进程立即终止。
如果你希望你的代码具有较好的移植性，你就得把这三种情况都考虑到。
慎用异常规格
　　异常规格在我看来不是一个好东西，不信可以去看看《c++ coding standards - 101 rules, guidelines & best practices》的第75条。（具体有哪些坏处以后专门开一个c++异常和错误处理的帖子来聊）言归正传，按照标准（参见03标准18.6.2章节），如果一个函数抛到外面的异常没有包含在该函数的异常规范中，那么应该调用unexcepted()。但是并非所有编译器生成的代码都遵守标准（比如某些版本的vc编译器）。如果你的需要支持的编译器在异常规范上的行为不一致，那就得考虑去掉异常规范声明。
不要跨模块抛出异常
　　此处说的模块是指动态库。如果你的程序包含有多个动态库，不要把异常抛到模块的导出函数之外。毕竟现在c++还没有abi标准（估计将来也未必会有），跨模块抛出异常会有很多不可预料的行为。
不要使用结构化异常处理（seh）
　　如果你从来没有听说过seh，那就当我没说，跳过这段。如果你以前习惯于用seh，在你打算写跨平台代码之前，要改掉这个习惯。包含有seh的代码只能在windows平台上编译通过，肯定无法跨平台的。
关于catch(…)
照理说，catch(…)语句只能够捕获c++的异常类型，对于访问违例、除零错等非c++异常是无能为力的。但是某些情况下（比如某些vc编译器），诸如访问违例、除零错也可以被catch(…)捕获。所以，你如果希望代码移植性好，就不能在程序逻辑中依赖上述catch(…)的行为。
硬件体系相关
　　这次聊的话题主要是和硬件体系有关的。比如你的程序需要支持不同类型的cpu（x86、sparc、powerpc），或者是同种类型不同字长的cpu（比如x86和x86-64），这时候你就需要关心一下硬件体系的问题。
基本类型的大小
　　c++中基本类型的大小（占用的字节数）会随着cpu字长的变化而变化。所以，假如你要表示一个int占用的字节数，千万不要直接写“4”（顺便说一下，直接写“4”还犯了magic number的大忌，详见这里），而应该写“sizeof(int)”；反过来，如果你要定义一个大小必须为4字节的有符号整数，也不要直接用int，要用预先typedef好的定长类型（比如boost库的int32_t、ace库的ace_int32、等）。
　　差点忘了，指针的大小也有上述的问题，也要小心。
字节序
　　如果你没听说过“字节序”这玩意儿，请看“维基百科”。通俗地打个比方，在一个大尾序的机器上有一个4字节的整数0x01020304，通过网络或者文件传到一台小尾序的机器上就会变成0x04030201；据说还有一种中尾序的机器（不过我没接触过），上述整数会变成0x02010403。
　　如果你编写的应用程序中涉及网络通讯，一定要在记得进行主机序和网络序的翻译；如果涉及跨机器传输二进制文件，也要记得进行类似的转换。
内存对齐
　　如果你不晓得“内存对齐”是什么东东，请看“维基百科”。简单来说，出于cpu处理上的性能考虑，结构体中的数据不是紧挨着的，而是要空开一些间隔。这样的话，结构体中每个数据的地址正好都是某个字长的整数倍。
　　由于c++标准中没有定义内存对齐的细节，因此，你的代码也不能依赖对齐的细节。凡是计算结构体大小的地方，都老老实实写上sizeof()。
　　有些编译器支持#pragma pack预处理语句（可以用来修改对齐字长），不过这种语法不是所有编译器都支持，要慎用。
移位操作
　　对于有符号整数的右移操作，有些系统默认使用算数右移（最高的符号位不变），有些默认使用逻辑右移（最高的符号位补0）。所以，不要对有符号整数进行右移操作。顺便说一下，即使没有移植性问题，代码中也尽量少用移位运算符。那些企图用移位运算来提高性能的同学更要注意了，这么干不但可读性很差，而且吃力不讨好。只要不太弱智的编译器，都会自动帮你搞定这种优化，无须程序员操心。
操作系统
　　上一个帖子提到了“硬件体系”相关的话题，今天来说说和操作系统相关的话题。c++跨平台开发中和os相关的琐事挺多，所以今天会啰嗦比较长的篇幅，请列位看官见谅 :-)
　　为了不绕口，以下把linux和各种unix统称为posix系统。
文件系统（filesystem以下简称fs）
　　刚开始搞跨平台开发的新手，多半都会碰上和fs相关的问题。所以先来聊一下fs。归纳下来，开发中容易碰上的fs差异主要有如下几个：目录分隔符的差异；大小写敏感的差异；路径中禁用字符的差异。
　　为了应对上述差异，你要注意如下几点：
1、文件和目录命名要规范
　　在给文件和目录命名时，尽量只使用字母和数字。不要在同一个目录下放两个名称相似（名称中只有大小写不同，例如foo.cpp与foo.cpp）的文件。不要使用某些os的保留字（例如aux、con、nul、prn）作文件名或目录名。
　　补充一下，刚才说的命名，包括了源代码文件、二进制文件和运行时创建的其它文件。
2、#include语句要规范
　　当你写#include语句时，要注意使用正斜线“/”（比较通用）而不要使用反斜线“\”（仅在windows可用）。#include语句中的文件和目录名要和实际名称保持大小写完全一致。
3、代码中涉及fs操作，尽量使用现成的库
　　已经有很多成熟的、用于fs的第三方库（比如boost::filesystem）。如果你的代码涉及到fs的操作（比如目录遍历），尽量使用这些第三方库，可以帮你省不少事情。
★文本文件的回车cr/换行lf
　　由于几个知名的操作系统对回车/换行的处理不一致，导致了这个烦人的问题。目前的局面是：windows同时使用cr和lf；linux和大部分的unix使用lf；苹果的mac系列使用cr。
　　对于源代码管理，好在很多版本管理软件（比如cvs、svn）都会智能地处理这个问题，让你从代码库取回本地的源码能适应本地的格式。
　　如果你的程序需要在运行时处理文本文件，要留意本文方式打开和二进制方式打开的区别。另外，如果涉及跨不同系统传输文本文件，要考虑进行适当的处理。
　　★文件搜索路径（包括搜索可执行文件和动态库）
　　在windows下，如果要执行文件或者加载动态库，一般会搜索当前目录；而posix系统则不尽然。所以如果你的应用涉及到启动进程或加载动态库，就要小心这个差异。
　　★环境变量
　　对于上述提到的搜索路径问题，有些同学想通过修改path和ld_library_path来引入当前路径。假如使用这种方法，建议你只修改进程级的环境变量，不要修改系统级的环境变量（修改系统级有可能影响到同机的其它软件，产生副作用）。
　　★动态库
　　如果你的应用程序使用动态库，强烈建议动态库导出标准c风格的函数（尽量不要导出类）。如果在posix系统中加载动态库，切记慎用rtld_global标志位。这个标志位会enable全局符号表，有可能会导致多个动态库之间的符号名冲突（一旦碰到这种事，会出现匪夷所思的运行时错误，极难调试）。
　　★服务/看守进程
　　如果你不清楚服务和看守进程的概念，请看维基百科（这里和这里）。为了叙述方便，以下统称服务。
　　由于c++开发的模块大部分是后台模块，经常会碰到服务的问题。编写服务需要调用好几个系统相关的api，导致了与操作系统的紧密耦合，很难用一套代码搞定。因此比较好的办法是抽象出一个通用的服务外壳，然后把业务逻辑代码作为动态库挂载到它下面。这样的话，至少保证了业务逻辑的代码只需要一套；服务外壳的代码虽然需要两套（一个用于windows、一个用于posix），但他们是业务无关的，可以很方便地重用。
　　★默认栈大小
　　不同的操作系统，栈的默认大小差别很大，从几十kb（据说symbian只有12k，真抠门）到几mb不等。因此你事先要打听一下目标系统的默认栈大小，如果碰上像symbian这样抠门的，可以考虑用编译器选项调大。当然，养成“不在栈上定义大数组/大对象”的好习惯也很重要，否则再大的栈也会被撑爆的。
多线程
　　最近一个多月写的帖子比较杂，导致本系列又好久没更新了。结果又有网友在评论中催我了，搞得我有点囧。今天赶紧把多线程篇补上。上次聊操作系统 的时候，由于和os有关的话题比较琐碎，杂七杂八说了一大堆。当时一看篇幅有点长，就把多进程和多线程的部分给留到后面了。
　　★编译器
◇关于c运行库选项
　　先来说一个很基本的问题：关于c运行库（后面简称crt：c run-time）的设置。本来不想聊这么低级的问题，但周围有好几个人都在这个地方吃过亏，所以还是讲一下。
　　大部分c++编译器都会自带有crt（可能还不止一个）。某些编译器自带的crt可能会根据线程的支持分为单线程crt和多线程crt两类。当你要进行多线程开发的时候，别忘了确保相关的c++工程项目使用的是多线程的crt。否则会死得很难看。
　　尤其当你使用visual c++创建工程项目，更加要小心。如果新建的工程项目是不含mfc的（包括console工程和win32工程），那工程的默认设置会是使用“单线程crt”，如下图所示：
◇关于优化选项
　　“优化选项”是另一个很关键的编译器相关话题。有些编译器提供号称很牛x的优化选项，但是某些优化选项可能会有潜在的风险。编译器可能自作主张打乱执行指令的顺序，从而导致出乎意料的线程竞态问题（race condition，详细解释看“这里 ”）。刘未鹏同学在“c++多线程内存模型 ”里举了几个典型的例子，大伙儿可以去瞧一瞧。
　　建议只使用编译器常规的速度优化选项即可。其它那些花哨的优化选项，增加的效果未必明显，但是潜在的风险不小。实在不值得冒险。
　　以gcc为例：建议用-o2 选项即可（其实-o2 是一堆选项的集合），没必要冒险用-o3 （除非你有很充足的理由）。除了-o2 和-o3 之外，gcc还有一大坨（估计有上百个）其它的优化选项。如果你企图用当中的某个选项，一定要先把它的特性、可能的副作用都摸清楚，否则将来死都不知道怎么死的。
　　★线程库的选择
　　由于当前的c++ 03标准几乎没有涉及线程相关的内容（即使将来c++ 0x包含了线程的标准库，编译器厂商的支持在短期内也未必全面），所以在未来很长的一段时间，跨平台的多线程支持还是要依赖第三方库。所以线程库的选择是大大滴重要。下面大致介绍一下几个知名的跨平台线程库。
　　◇ace
　　先说一下ace这个历史悠久的库。如果你之前从未接触过它，先看“这里 ”扫盲。从ace的全称（adaptive communication environment）来看，它应该是以“通讯”为主业。不过ace对“多线程”这个副业的支持还是非常全面的，比如互斥锁（ace_mutex）、条件变量（ace_condition）、信号量（ace_semaphore）、栅栏（ace_barrier）、原子操作（ace_atomic_op）等等。对某些类型比如ace_mutex还细分为线程读写锁（ace_rw_thread_mutex）、线程递归锁（ace_recursive_thread_mutex）等等。
　　除了支持很全面，ace还有另一个很明显的优点，就是对各种操作系统平台及其自带的编译器支持很好。包括一些老式的编译器（比如vc6），它也能够支持（此处所说的支持 ，不光是能编译通过，而且要能稳定运行）。这个优点对于跨平台开发那是相当相当滴明显。
　　那缺点捏？由于ace开工的年头很早（大概是上世纪九十年代中期），那会儿很多c++的老特性都还没出来（更别提新特性了），所以感觉ace整个的风格比较老气，远不如boost那么时髦前卫。
　　◇boost::thread
　　boost::thread正好和ace形成鲜明对照。这玩意貌似从boost 1.32版本开始引入，年头比ace短。不过得益于boost里一帮大牛的支持，发展还是蛮快的。到目前的boost 1.38版本，也能够支持许多特性了（不过似乎没ace多）。鉴于很多c++标准委员会的成员云集在boost社区中，随着时间的推移，boost::thread终将成为c++线程的明日之星，前途无量啊！
　　boost::thread的缺点就是支持的编译器不够多，尤其是一些老式 编译器（很多boost的子库都有此问题，多半因为用了一些高级的模板语法）。这对于跨平台而言一个比较明显的问题。
　　◇wxwidgets 和qt
　　wxwidgets和qt都是gui界面库，但是它们也都内置和对线程的支持。wxwidgets线程的简介可以看“这里 ”，关于qt线程的简介可以看“这里 ”。这两个库对线程的支持差不多，都提供了诸如mutex、condition、semaphore等常用的机制。不过特性没有ace丰富。
　　◇如何权衡
　　对于开发gui软件并已经用上了wxwidgets或者qt，那你可以直接用它们内置的线程库（前提是你只用到基本的线程功能）。由于它们内置的线程库，特性稍嫌单薄。万一你需要某高级的线程功能，那得考虑替换成boost::thread或ace。
　　至于boost::thread和ace的取舍，主要得看软件的需求了。如果你要支持的平台挺多挺杂，那建议选用ace，以免碰上编译器不支持的问题。如果你只需要支持少数几个主流的平台（比如windows、linux、mac），那建议用boost::thread。毕竟主流操作系统上的编译器，对boost的支持还是蛮好的。
　　★编程上的注意事项
　　其实多线程开发，需要注意的地方挺多的，我只能大致列几个印象比较深的注意事项。
　　◇关于volatile
　　说到多线程编程可能碰到的陷阱，那就不得不提到volatile 关键字。如果你对它还不甚了解，先看“这里 ”扫盲一下。由于c++ 98和c++ 03标准都没有定义多线程的内存模型，而标准中也就volatile 和线程沾点儿边。结果导致c++社区中有相当多的口水都集中在volatile 身上（其中有不少c++大牛的口水）。有鉴于此，我这里就不再多啰嗦了。推荐几个大牛的文章：andrei alexandrescu 的文章“这里 ”、还有hans boehm的文章“这里 ”和“这里 ”。大伙儿自个儿去拜读一下。
　　◇关于原子操作
　　有些同学光知道多个线程的竞争写 需要加锁，却不知道多个读 单个写 也需要保护。比如有某个整数int ncount = 0x01020304；在并发状态下，一个写线程去修改它的值ncount = 0x05060708；另一个读线程去获取该值。那么读线程有没有可能读取到一个“坏”的（比如0x05060304）数据捏？
　　数据是否坏掉，取决于对ncount的读和写是否属于原子操作。而这就依赖于很多硬件相关的因素了（包括cpu的类型、cpu的字长、内存对齐的字节数等）。在某些情况下，确实可能出现数据坏掉。
　　由于我们讨论的是跨平台的开发，天晓得将来你的代码会在啥样的硬件环境下执行。所以在处理类似问题的时候，还是要用第三方库提供的原子操作类/函数（比如ace的atomic_op）来确保安全。
　　◇关于对象的析构
在之前的系列帖子“c++对象是怎么死的？ ”里面，已经分别介绍了win32平台和posix平台下线程的非自然死亡问题。
由于上述几个跨平台的线程库底层还是要调用操作系统自带的线程api，所以大伙儿还是要尽最大努力确保所有线程都能够自然死亡。

相关推荐：

Python和ruby之间的异同对比

Java语言简介（动力节点整理）

以上就是C++的可移植性和跨平台开发（长文）的详细内容，更多请关注php中文网其它相关文章！