從 VC 6.0移植程式碼到 VS C++ 2005得出的一些經驗

最近將一個系統的原始碼從VC 6.0移植到VS C++ 2005上，從而得出了一些經驗。不同編譯平臺的程式碼移植（這裡指從低版本的編譯器往高版本的編譯器之間的程式碼移植），其移植成本主要由兩方面組成，一是系統庫的變化產生的成本，如API函式的變化和類成員函式的變化；二是由於在低版本編譯器寫出的不規範的程式碼產生的成本（一般而言，高版本的編譯器對程式語法的檢查更加嚴格）。分析一下這兩方面的成本，前者是我們第三方開發者不可控制的，後者是我們可以控制的，而且後者產生的編譯錯誤更多，花費的時間更多。通過這次移植，我在想：假如我們在使用VC 6.0開發時遵循一些原則，那麼移植到VS C++2005上就會方便多了。下面是我總結的一些經驗：

 1） 儘可能使用標準的C++語法來寫C++程式碼。比如使用標準的C++型別轉換符如staic_cast進行型別轉換，使用標準C庫函式時明確實參型別，比如

long i = 0；

double j = sqrt(i);

上面的兩行程式碼在VC 6.0不會出現編譯錯誤（可能出現一個編譯警告），但在VS 2005中會出現使用sqrt函式不明確的錯誤，為了避免出現這個錯誤，你最好這樣寫：

long i = 0;

double j = sqrt(static_cast(i));

2）假如實現相同的功能，優先考慮使用成熟的開源庫。因為很多成熟開源庫本身有著跨平臺的設計，而且編碼規範，千錘百煉。之前我在VC 6.0上使用msxml4.dll來讀寫xml檔案，移植到VS 2005上，結果因為VS 2005內建了對xml的支援，所以出現很多型別不明確的錯誤（msxml,msxml3不同名稱空間的衝突）。假如我一開始使用tinyxml、libxml等開源庫讀寫xml檔案，到時只需要將這些開原始碼拿到VS 2005上編譯出新的庫檔案就可以了。

 

3）必須設定函式的返回值，沒有返回值就設為void型別。如果沒有定義函式返回值，VC 6.0會預設為返回int 型別，但VS 2005對此會報錯。

4）儘量使用unicode字符集進行編譯。這是一條推薦原則。眾所周知，VC 6.0預設以多位元組字符集進行編譯。但《Windows核心程式設計》告訴我們使用unicode字符集進行編譯是有諸多好處的：

a. 簡化應用程式本土化的程式碼轉換工作

b. 可以很容易地在不同語言之間進行資料交換

c. 使你能夠分配支援所有語言的單個二進位制.exe檔案和DLL檔案。

d. 提高應用程式的執行效率

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12639172/viewspace-586868/，如需轉載，請註明出處，否則將追究法律責任。