C++的可移植性和跨平台开发
博客专区 > kelly 的博客 > 博客详情
C++的可移植性和跨平台开发
kelly 发表于4年前
C++的可移植性和跨平台开发
  • 发表于 4年前
  • 阅读 1547
  • 收藏 12
  • 点赞 2
  • 评论 0
摘要: 记录一些C++的移植性问题。包括:编译器相关、异常处理、硬件体系相关、操作系统还有多线程。

概述

  今天聊聊C++的可移植性问题。如果你平时使用C++进行开发,并且你对C++的可移植性问题不是非常清楚,那么我建议你看看这个系列。即使你目前没有跨平台开发的需要,了解可移植性方面的知识对你还是很有帮助的。

  C++的可移植性这个话题很大,包括了编译器、操作系统、硬件体系等很多方面,每一个方面都有很多内容。鉴于本人能力、精力都有限,只能介绍每一个方面最容易碰到的问题,供大伙儿参考。

  后面我会分别从编译器、C++语法、操作系统、第三方库、辅助工具、开发流程等方面进行介绍。

编译器

  在跨平台的开发过程中,很多问题都和编译器有关。因此我们先来聊聊编译器相关的问题。

编译器的选择

  首先,GCC是优先要考虑支持的,因为几乎所有操作系统平台都有GCC可用。它基本上成了一个通用的编译器了。如果你的代码在A平台的GCC能够编译通过,之后拿到B平台用类似版本的GCC编译,一般也不会有太大问题。因此GCC是肯定要考虑支持的。

  其次,要考虑是否支持本地编译器。所谓本地编译器就是操作系统厂商自产的编译器。例如:相对于Windows的本地编译器就是Visual C++。相对于Solaris的本地编译器就是SUNCC。如果你对性能比较敏感或者想用到某些本地编译器的高级功能,可能就得考虑在支持GCC的同时也支持本地编译器。

编译警告

编译器是程序员的朋友,很多潜在的问题(包括可移植性),编译器都是可以发现并给出警告的,如果你平时注意这些警告信息,可以减少很多麻烦。因此我强烈建议:

1把编译器的警告级别调高;

2不要轻易忽略编译器的警告信息。

交叉编译器

  交叉编译器的定义参见“维基百科”。通俗地说,就是在A平台上编译出运行在B平台上的二进制程序。假设你要开发的应用是运行在Solaris上,但是你手头没有能够运行SolarisSPARC机器,这时候交叉编译器就可以派上用场了。一般情况下都使用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(...)的行为。

硬件体系相关

  这次聊的话题主要是和硬件体系有关的。比如你的程序需要支持不同类型的CPUx86SPARCPowerPC),或者是同种类型不同字长的CPU(比如x86x86-64),这时候你就需要关心一下硬件体系的问题。

基本类型的大小

  C++中基本类型的大小(占用的字节数)会随着CPU字长的变化而变化。所以,假如你要表示一个int占用的字节数,千万不要直接写“4”(顺便说一下,直接写“4”还犯了Magic Number的大忌,详见这里),而应该写“sizeof(int)”;反过来,如果你要定义一个大小必须为4字节的有符号整数,也不要直接用int,要用预先typedef好的定长类型(比如boost库的int32_tACE库的ACE_INT32、等)。

  差点忘了,指针的大小也有上述的问题,也要小心。

字节序

  如果你没听说过“字节序”这玩意儿,请看“维基百科”。通俗地打个比方,在一个大尾序的机器上有一个4字节的整数0x01020304,通过网络或者文件传到一台小尾序的机器上就会变成0x04030201;据说还有一种中尾序的机器(不过我没接触过),上述整数会变成0x02010403

  如果你编写的应用程序中涉及网络通讯,一定要在记得进行主机序和网络序的翻译;如果涉及跨机器传输二进制文件,也要记得进行类似的转换。

内存对齐

  如果你不晓得“内存对齐”是什么东东,请看“维基百科”。简单来说,出于CPU处理上的性能考虑,结构体中的数据不是紧挨着的,而是要空开一些间隔。这样的话,结构体中每个数据的地址正好都是某个字长的整数倍。

  由于C++标准中没有定义内存对齐的细节,因此,你的代码也不能依赖对齐的细节。凡是计算结构体大小的地方,都老老实实写上sizeof()

  有些编译器支持#pragma pack预处理语句(可以用来修改对齐字长),不过这种语法不是所有编译器都支持,要慎用。

移位操作

  对于有符号整数的右移操作,有些系统默认使用算数右移(最高的符号位不变),有些默认使用逻辑右移(最高的符号位补0)。所以,不要对有符号整数进行右移操作。顺便说一下,即使没有移植性问题,代码中也尽量少用移位运算符。那些企图用移位运算来提高性能的同学更要注意了,这么干不但可读性很差,而且吃力不讨好。只要不太弱智的编译器,都会自动帮你搞定这种优化,无须程序员操心。

操作系统

  上一个帖子提到了“硬件体系”相关的话题,今天来说说和操作系统相关的话题。C++跨平台开发中和OS相关的琐事挺多,所以今天会啰嗦比较长的篇幅,请列位看官见谅 :-)

  为了不绕口,以下把Linux和各种Unix统称为Posix系统。

文件系统(FileSystem以下简称FS)

  刚开始搞跨平台开发的新手,多半都会碰上和FS相关的问题。所以先来聊一下FS。归纳下来,开发中容易碰上的FS差异主要有如下几个:目录分隔符的差异;大小写敏感的差异;路径中禁用字符的差异。

  为了应对上述差异,你要注意如下几点:

1、文件和目录命名要规范

  在给文件和目录命名时,尽量只使用字母和数字。不要在同一个目录下放两个名称相似(名称中只有大小写不同,例如foo.cppFoo.cpp)的文件。不要使用某些OS的保留字(例如auxconnulprn)作文件名或目录名。

  补充一下,刚才说的命名,包括了源代码文件、二进制文件和运行时创建的其它文件。

2#include语句要规范

  当你写#include语句时,要注意使用正斜线“/”(比较通用)而不要使用反斜线“\”(仅在Windows可用)。#include语句中的文件和目录名要和实际名称保持大小写完全一致。

3、代码中涉及FS操作,尽量使用现成的库

  已经有很多成熟的、用于FS的第三方库(比如boost::filesystem)。如果你的代码涉及到FS的操作(比如目录遍历),尽量使用这些第三方库,可以帮你省不少事情。

文本文件的回车CR/换行LF

  由于几个知名的操作系统对回车/换行的处理不一致,导致了这个烦人的问题。目前的局面是:Windows同时使用CRLFLinux和大部分的Unix使用LF;苹果的Mac系列使用CR

  对于源代码管理,好在很多版本管理软件(比如CVSSVN)都会智能地处理这个问题,让你从代码库取回本地的源码能适应本地的格式。

  如果你的程序需要在运行时处理文本文件,要留意本文方式打开和二进制方式打开的区别。另外,如果涉及跨不同系统传输文本文件,要考虑进行适当的处理。

  ★文件搜索路径(包括搜索可执行文件和动态库)

  在Windows下,如果要执行文件或者加载动态库,一般会搜索当前目录;而Posix系统则不尽然。所以如果你的应用涉及到启动进程或加载动态库,就要小心这个差异。

  ★环境变量

  对于上述提到的搜索路径问题,有些同学想通过修改PATHLD_LIBRARY_PATH来引入当前路径。假如使用这种方法,建议你只修改进程级的环境变量,不要修改系统级的环境变量(修改系统级有可能影响到同机的其它软件,产生副作用)。

  ★动态库

  如果你的应用程序使用动态库,强烈建议动态库导出标准C风格的函数(尽量不要导出类)。如果在Posix系统中加载动态库,切记慎用RTLD_GLOBAL标志位。这个标志位会Enable全局符号表,有可能会导致多个动态库之间的符号名冲突(一旦碰到这种事,会出现匪夷所思的运行时错误,极难调试)。

  ★服务/看守进程

  如果你不清楚服务和看守进程的概念,请看维基百科(这里和这里)。为了叙述方便,以下统称服务。

  由于C++开发的模块大部分是后台模块,经常会碰到服务的问题。编写服务需要调用好几个系统相关的API,导致了与操作系统的紧密耦合,很难用一套代码搞定。因此比较好的办法是抽象出一个通用的服务外壳,然后把业务逻辑代码作为动态库挂载到它下面。这样的话,至少保证了业务逻辑的代码只需要一套;服务外壳的代码虽然需要两套(一个用于Windows、一个用于Posix),但他们是业务无关的,可以很方便地重用。

  ★默认栈大小

  不同的操作系统,栈的默认大小差别很大,从几十KB(据说Symbian只有12K,真抠门)到几MB不等。因此你事先要打听一下目标系统的默认栈大小,如果碰上像Symbian这样抠门的,可以考虑用编译器选项调大。当然,养成“不在栈上定义大数组/大对象”的好习惯也很重要,否则再大的栈也会被撑爆的。

多线程

  最近一个多月写的帖子比较杂,导致本系列又好久没更新了。结果又有网友在评论中催我了,搞得我有点囧。今天赶紧把多线程篇补上。上次聊操作系统 的时候,由于和OS有关的话题比较琐碎,杂七杂八说了一大堆。当时一看篇幅有点长,就把多进程和多线程的部分给留到后面了。

  ★编译器

关于C运行库选项

  先来说一个很基本的问题:关于C运行库(后面简称CRTC 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

  wxWidgetsQT都是GUI界面库,但是它们也都内置和对线程的支持。wxWidgets线程的简介可以看“这里 ”,关于QT线程的简介可以看“这里 ”。这两个库对线程的支持差不多,都提供了诸如mutexconditionsemaphore等常用的机制。不过特性没有ACE丰富。

  ◇如何权衡

  对于开发GUI软件并已经用上了wxWidgets或者QT,那你可以直接用它们内置的线程库(前提是你只用到基本的线程功能)。由于它们内置的线程库,特性稍嫌单薄。万一你需要某高级的线程功能,那得考虑替换成boost::threadACE

  至于boost::threadACE的取舍,主要得看软件的需求了。如果你要支持的平台挺多挺杂,那建议选用ACE,以免碰上编译器不支持的问题。如果你只需要支持少数几个主流的平台(比如WindowsLinuxMac),那建议用boost::thread。毕竟主流操作系统上的编译器,对boost的支持还是蛮好的。

  ★编程上的注意事项

  其实多线程开发,需要注意的地方挺多的,我只能大致列几个印象比较深的注意事项。

  ◇关于volatile

  说到多线程编程可能碰到的陷阱,那就不得不提到volatile 关键字。如果你对它还不甚了解,先看“这里 ”扫盲一下。由于C++ 98C++ 03标准都没有定义多线程的内存模型,而标准中也就volatile 和线程沾点儿边。结果导致C++社区中有相当多的口水都集中在volatile 身上(其中有不少C++大牛的口水)。有鉴于此,我这里就不再多啰嗦了。推荐几个大牛的文章:Andrei Alexandrescu 的文章“这里 ”、还有Hans Boehm的文章“这里 ”和“这里 ”。大伙儿自个儿去拜读一下。

  ◇关于原子操作

  有些同学光知道多个线程的竞争写 需要加锁,却不知道多个读 单个写 也需要保护。比如有某个整数int nCount = 0x01020304;在并发状态下,一个写线程去修改它的值nCount = 0x05060708;另一个读线程去获取该值。那么读线程有没有可能读取到一个“坏”的(比如0x05060304)数据捏?

  数据是否坏掉,取决于对nCount的读和写是否属于原子操作。而这就依赖于很多硬件相关的因素了(包括CPU的类型、CPU的字长、内存对齐的字节数等)。在某些情况下,确实可能出现数据坏掉。

  由于我们讨论的是跨平台的开发,天晓得将来你的代码会在啥样的硬件环境下执行。所以在处理类似问题的时候,还是要用第三方库提供的原子操作类/函数(比如ACEAtomic_Op)来确保安全。

  ◇关于对象的析构

在之前的系列帖子“C++对象是怎么死的? ”里面,已经分别介绍了Win32平台和Posix平台下线程的非自然死亡问题。

由于上述几个跨平台的线程库底层还是要调用操作系统自带的线程API,所以大伙儿还是要尽最大努力确保所有线程都能够自然死亡。



共有 人打赏支持
粉丝 2
博文 1
码字总数 0
×
kelly
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: