基本介紹
- 中文名：可移植性
- 含義：軟體質量之一
- 特點：良好的可移植性
- 特性：適應性、易安裝性等
特性
其質量子特性有：適應性、易安裝性、共存性、易替換性和依從性。
可移植性並不是指所寫的程式不作修改就可以在任何計算機上運行，而是指當條件有變化時，程式無需作很多修改就可運行。
你不要把“我不會碰到這種情況”這句話說得太早。直到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'/'
#endif
#ifdef __MSDOS__
define FILE SEP CHAR'\\'
#endif
你就可以通過把FILE_SEP_CHAR傳遞給strchr()或strtok()來找出檔案名稱中的路徑部分。儘管這一步還無法找出一個MS-DOS檔案的驅動器名，但它已經是一個正確的開頭了。
最後，找出潛在的可移植性問題的最好方法之一就是請別人來查找!假如可以的話，最好請別人來檢查一下你的程式。他或許知道一些你不知道的東西，或許能發現一些你從未想過的問題(有些名稱中含"lint"的工具和有些編譯程式選項可以幫助你找出一些問題，但你不要指望它們能找出大的問題)。
你不要把“我不會碰到這種情況”這句話說得太早。直到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'/'
#endif
#ifdef __MSDOS__
define FILE SEP CHAR'\\'
#endif
你就可以通過把FILE_SEP_CHAR傳遞給strchr()或strtok()來找出檔案名稱中的路徑部分。儘管這一步還無法找出一個MS-DOS檔案的驅動器名，但它已經是一個正確的開頭了。
最後，找出潛在的可移植性問題的最好方法之一就是請別人來查找!假如可以的話，最好請別人來檢查一下你的程式。他或許知道一些你不知道的東西，或許能發現一些你從未想過的問題(有些名稱中含"lint"的工具和有些編譯程式選項可以幫助你找出一些問題，但你不要指望它們能找出大的問題)。
