第8章可移植性.PDFVIP

下载 第8章 可 移 植 性 最后，标准化与常规相仿，能成为强有力秩序的另一种具体化形式。但是它又 与常规不同，它已经被现代建筑学公认为是我们技术的浓缩产物，因此以其潜在的 支配地位和蛮横特征而令人恐惧。 Robert Ve n t u r i ，《建筑学中的复杂和矛盾》 写出能够正确而有效地运行的软件是很困难的。因此，如果某个程序能在一个环境里工 作，当你需要把它移到另一个编译系统，或者处理器，或者操作系统上时，不会希望再重复 做太多原来已经做过的工作。最理想的情况是什么都不用改。 这种理想就是程序的可移植性。实际上，“可移植性”常被用来指一个更弱的概念，其意 思是说，与凭空写出这个程序相比，对它做些修改挪到另一个地方将更容易一些。这种修改 越容易做，我们就说这个程序的可移植性越强。 你可能会奇怪，为什么我们还要为可移植性费心呢？如果软件都是准备在某些特定条件 下，在一个特定环境里运行的，为什么还要在使它具有更广泛的可接受性方面白费精力呢？ 首先，任何成功的程序，几乎总是注定要被以原来不曾预料的方式，用到从未想到的地方去。 把一个软件构造得比它的规范更一般些，结果就会是以后的更少维护和更好使用。第二，环 境总是在变。当编译系统、操作系统或者硬件升级的时候，其特性可能就不同了。程序对特 殊特征的依赖越少，它也就越少可能崩溃，也越容易适应改变以后的环境。最后，也是最重 要的，可移植的程序总是更优秀的程序。为把程序构造得更具有可移植性的努力也会使它具 有更好的设计，更好的结构，经过更彻底的测试。一般地说，可移植程序设计的技术与优良 程序设计的技术是密切相关的。 当然，可移植性的程度也应当根据现实来考虑。不存在什么绝对的可移植程序，只有那种 已经在足够多的环境里试验过的程序。但是，我们仍然可以把可移植性作为一个目标，力图 去开发那种几乎不用修改就能够运行在任何环境上的软件。甚至当这个目的不能完全达到时， 在程序构造过程中花在可移植性上的功夫也将会得到回报，例如在这个软件需要升级的时候。 我们的看法是：应该设法写这样的软件，它能工作在它必须活动于其中的各种标准、界 面和环境的交集里。不要为纠正每个移植性问题写一段特殊代码，正相反，应该修改这个软 件本身，使它能够在新增加的限制下工作。利用抽象和封装机制限制和控制那些无法避免的 不可移植代码。通过将软件维持在各种限制的交集里面，局部化它的系统依赖性，这样你的 代码在被移植后仍将更加清晰、更具通用性。 8.1 语言 盯紧标准。得到可移植代码的第一步当然是使用某种高级语言，应该按照语言标准 (如果有的 话)去写程序。二进制不可能很容易地移植，但是源代码可以。当然，即使这样做也还会有问 150计计程序设计实践 下载 题，在编译系统如何将源程序翻译到机器指令的方式方面，也可能有些东西没有精确定义， 对标准语言也是如此。广泛使用的语言只存在一个实现的情况是罕见的，通常都有多个编译 系统提供商，对于不同操作系统，又有不同的版本，还有随着年月更替而不断出现的不同发 行版本。它们对你的源代码可能做出不同解释。 为什么语言标准不是一个严格定义呢？有时标准是不完全的，对某些特性之间的相互作 用没有给出定义。有时标准会有意地不对某些东西做出定义，例如， C和C++ 语言里的 c h a r 类型可以是有符号的或是无符号的，而且不必正好是 8位。把这些事项留给写编译系统的人去 解决，有可能产生出更有效的实现，或者避免语言对它能在其上运行的硬件提出太多限制。 当然，这种做法可能给程序员带来困难。政治上和技术上的相容性问题也可能导致某种妥协， 使标准对某些细节不做具体定义。最后，语言都是极端复杂的，编译系统也很复杂，理解中 可能出错，实现里面也可能有毛病。 有时语言根本没有经过标准化。 C语言正式的A N S I / I S O标准在 1 9 8 8年颁布，而I S O 的C + + 的标准直到 1 9 9 8年才被批准，在我们写这些的时候，还没有一个在用的编译系统支持这个正 式标准。J a v a 是更新一些的语言，与标准化的距离还有许多年。一个语言标准的开发通常总 是要等到这个语言已经有了许多不同的、互相冲