環境的移植是什么樣的感受?我的一位師哥說的很真切：這是一項體力活!說的一點沒錯。在我將項目的環境設置成Unicode時,編譯時竟出現500多了錯誤!而在多字節環境下卻可以正常運行。在MSDN、網上查找了相關移植的資料.發現所謂的移植主要是將一些多字節函數使用Unicode環境下的函數替換一下.
例如strcmp()函數原型為:
未設置任何環境下的函數
int strcmp(
const char *string1,
const char *string2
);
Unicode環境下的函數
int wcscmp(
const wchar_t *string1,
const wchar_t *string2
);
多字節環境下的函數
int _mbscmp(
const unsigned char *string1,
const unsigned char *string2
);
因此,我按照MSDN上的函數說明,使用查找替換的方法,將所有strcmp 替換為 wcscmp.重新編譯一下,結果錯誤不僅沒有減少,反而又多了起來.經過查看錯誤列表,發現新增的一些錯誤來自些帶多字節參數的函數,如 void Compress(const char *lpszInfile,const char *lpszOutfile).由于這些函數參數形式為多字節的,而在函數體內部卻使用Unicode環境下的比較函數,這當然是行不通的.再次查看MSDN,發現如下表格:
Generic-Text Routine Mappings
| TCHAR.H routine | _UNICODE & _MBCS not defined | _MBCS defined | _UNICODE defined |
| _tcscmp | strcmp | _mbscmp | wcscmp |
它的意思是說你可以使用宏定義函數來代替MBSC和Unicode函數. Routine:說明該宏定義函數只有在運行時才會動態的根據環境來決定使用MBSC函數還是Unicode函數.
現在我們分別在Unicode、MBSC、UnKnow環境下查看_tcscmp函數的提示信息：
Unicode環境
MBSC環境
UnKnow環境
一切都很明白。宏函數在各種環境下使用了不同的函數定義。現在我們可以放心的使用宏函數來替換原來的函數了。
于是我將需要的替換的函數都用宏函數做了替換。但是錯誤仍然很多，到底什么地方出錯了？我又仔細的查看了錯誤信息。原來許多類的函數帶有char類型參數,由于在Unicode環境下使用宏函數,所以函數的參數被解釋成了Unicode下的變量類型wchar_t,所以產生了類型不匹配的錯誤.但是我總不能都將所有的char類型都替換成wchar_t類型吧。這樣一來，就只能在Unicode環境下編譯使用了，如果需要轉換為MBCS環境又要修改變量類型，所以不具備通用性。經過思考,我決定采用兩種方法來解決此問題。
一是保留原有參數類型，在函數體內不使用宏函數，如果參數是MBCS類型的就使用MBSC類型的函數。如果使用Unicode參數類型就使用Unicode類型函數。
如：參數是const char* 就使用 strcpy,strcmp之類的函數。
參數是 const wchar_t* 就使用 wcscpy,wcscmp之類的函數。
二是使用宏變量類型TCHAR,該變量也會根據環境的不同，使用不同的變量類型。
如：在MBSC環境下，TCHAR 代表char。
在Unicode環境下，TCHAR代表 wchar_t。
經過如上的反復修改和調試，錯誤終于改完了。謝天謝地！
可惜，我高興的太早了。許多隱藏的錯誤弄得我焦頭爛額。在填充一個樹狀控件時，每一個樹項都成了亂碼。但編譯、運行為什么沒有出錯？帶著這個疑問，我使用調試器查看了運行時的變量值。結果發現，從文件中讀取的樹項被放入了char類型的緩沖區，而填充樹項卻在Unicode環境下進行的。我們知道：在MBSC環境下A=0x41，而在Unicode環境下A=0x41 00，所以多字節的字符串AB=0x4142，而在Unicdoe環境下則變成了AB=0x14 00 42 00，所以在Unicode環境下，0x4142被認為是一個字符，但編碼中并不存在這一字符，結果就變成了亂字符串。原因找到了，解決的辦法就是使用MultiByteToWideChar和WideCharToMultiByte兩個函數在MBCS和Unicode環境下來回的轉換。現在好了，終于完成了環境的移植。心里踏實多了。
希望我的這篇文章能對大家有所幫助。