可移植性

其質量子特性有：適應性、易安裝性、共存性、易替換性和依從性。

可移植性並不是指所寫的程序不作修改就可以在任何計算機上運行，而是指當條件有變化時，程序無需作很多修改就可運行。

你不要把“我不會碰到這種情況”這句話説得太早。直到MS—視頻教程'＞windows出現之前，許多MS—DOS程序員還不怎麼關心可移植性問題。然後，忽然之間，他們的程序不得不在一個看起來不同的操作系統上運行。當Power PC流行起來後，Mac機的程序員不得不去應付一個新的處理器。任何一個在同版本的UNIX下維護過程序的人所瞭解的可移植性的知識，恐怕都足以寫成一本書，更別説寫成一章了。

假設你用基本ALBATR—OS(Anti-lock Braking and Tire Rotation operating system)的Tucker C來編寫防抱死剎車軟件，這聽起來好象是一個最典型的不可移植軟件。即便如此，可移植性仍然很重要：你可能需要把它從Tucker C的7．55c版本升級到8．O版本，或者從ALBATR—OS的3．o版本升級到3．2a版本，以修改軟件中的某些錯誤；你也可能會出於仿真測試或宣傳的目的，而把它(或其中一部分)移植到MS-Windows或UNIX工作站上；更為可能的是，在它尚未最終完工之前，你會把它從一個程序員手中交到另一個程序員手中。

可移植性的本意是按照意料之中的方式做事情，其目的不在於簡化編譯程序的工作，而在於使改寫(重寫!)程序的工作變得輕易。假如你就是接過別人的程序的“倒黴蛋”，那麼原程序中的每一處出乎意料之外的地方都會花去你的時間，並且將來可能會引起微妙的錯誤。假如你是原程序的編寫者，你應該注重不要使你的程序中出現出乎接手者意料之外的代碼。你應該儘量使程序輕易理解，這樣就不會有人抱怨你的程序難懂了。此外，幾個月以後，下一個“倒黴蛋”

很可能就會是你自己了，而這時你可能已經忘記了當初為什麼用這樣複雜的一種方式來寫一個for循環。

使程序可移植的本質非常簡單：假如做某些事情有一種既簡單又標準的方法，就按這種方法做。

使程序可移植的第一步就是使用標準庫函數，並且把它們和ANSI/ISO C標準中定義的頭文件放在一起使用，詳見第11章“標準庫函數”。

第二步是儘可能使所寫的程序適用於所有的編譯程序，而不是僅僅適用於你所使用的編譯程序。假如你的手冊提醒你某種功能或某個函數是你的編譯程序或某些編譯程序所特有的。你就應該謹慎地使用它。有許多關於c語言編程的好書中都提出了一些關於如何保持良好的可移植性的建議。非凡地，當你不清楚某個東西是否會起作用時，不要馬上寫一個測試程序來看看你的編譯程序是否會接受它，因為即使這個版本的編譯程序接受它，也不能説明這個程序就有很好的可移植性(C++程序員比c程序員應該更重視這個問題)。此外，小的測試程序很可能會漏掉要測試的性能或問題的某些方面。

第三步是把不可移植的代碼分離出來。假如你無法確定某段程序是否可移植，你就應該儘快註釋出這一點。假如有一些大的程序段(整個函數或更多)依靠於它們的運行環境或編譯方式，你就應該把其中不可移植的代碼分離到一些獨立的“．c”文件中。假如只在一些小的程序段中存在可移植性問題，你可以使用#ifdef預處理指令。例如，在MS-DOS中文件名的形式為“\tools\readme”，而在UNIX中文件名的形式為“/tools/readme”。假如你的程序需要把這樣的

文件名分解為獨立的部分，你就需要查找正確的分隔符。假如有這樣一段代碼

#ifdef unix

#define FILE_SEP_CHAR'/'

#ifdef __MSDOS__

define FILE SEP CHAR'\\'

#endif

你就可以通過把FILE_SEP_CHAR傳遞給strchr()或strtok()來找出文件名中的路徑部分。儘管這一步還無法找出一個MS-DOS文件的驅動器名，但它已經是一個正確的開頭了。

最後，找出潛在的可移植性問題的最好方法之一就是請別人來查找!假如可以的話，最好請別人來檢查一下你的程序。他或許知道一些你不知道的東西，或許能發現一些你從未想過的問題(有些名稱中含"lint"的工具和有些編譯程序選項可以幫助你找出一些問題，但你不要指望它們能找出大的問題)。