1- 注意文件名的大小寫, 這個在移植到 LINUX 這種文件系統區分名字大小寫的系統上尤其重要.
2- 同樣的,注意文件名大小寫的同時,也應該注意避免在區分大小寫的系統上創建大小寫不同,但名字相同的代碼文件.
3- 保證每個代碼文件(CPP,H)的結尾都有單獨的沒有任何內容的一行, 這在CC/GCC/G++編譯器下能減少很多警告.
4- 同1 和2 項所說, #include 包含頭文件的時候一定要注意文件名的大小寫, VC++總是把大小寫搞亂, 不得不猜想微軟是不是想要阻撓跨平臺的軟件開發...
5- 接第4項, 頭文件的路徑分隔推薦使用 " / ", 而不是WINDOWS下常用的 " \ ", 前者基本可以在所有系統上使用, 后者似乎是WINDOWS獨家支持的.
6- 盡量使用標準C++的原子數據類型, 避免使用被重新定義過的類型. 或者自己重新重定義一套.
7- 避免使用編譯器相關的一些特性, 比如VC++的_descspec() 這個擴展出來的各種語言特性. 盡量所有代碼都按照C++標準來編寫.
8- 注意不同平臺編譯器的非C++標準的地方, 比如返回對象實例的生存空間.
9- 盡量把操作系統相關的東西都封裝成統一的調用接口, 這樣在你移植代碼的時候,可以做到重新編譯即可運行.
10- 調試環境最好選擇WINDOWS平臺, 因為那里的調試是最友好, 特別是WINDOWS的結構化異常非常的好用, 可以簡單的DUMP出異常產生處的CALLSTACK和變量值...我說的可是發行版本.
11- 盡量不要使用內嵌匯編, 先不說GCC的內嵌匯編多么的難寫, 光是不同平臺CPU的指令集的差別就足以讓人頭疼. 不過說起來, 似乎GCC的內嵌匯編的寫法是可以跨CPU硬件平臺的.
12- 如果你的程序要在多平臺下進行數據交換或者是網絡通信, 請一定要注意LITTLE_ENDIAN和BIG_ENDIAN的區別, 仔細處理這個問題, 往往會解決讓你撓頭不止也無法解決的問題.
<未完待續>