在wxWidgets 3.0中對Unicode的支持已經發生了根本的變化，很多與以前版本的庫相關的現有資料已經不再正確。
臭名昭著的宏wxT()和_T()不再需要了。基本上，您可以從任何使用它們的代碼中刪除它們。另一方面，保留它們也沒有什么特別的危害，因為代碼仍然可以正確地編譯和工作——您只需要在您認為沒有它們的代碼看起來更整潔時刪除它們。您也不再需要使用wxChar，但是可以直接使用標準的wchar_t類型，即使wxChar仍然可以工作。
c_str()方法的返回類型改變:它返回一個特殊的代理對象，而不是簡單的char或wchar_t。因此，您不能將其結果傳遞給任何標準的vararg函數(如printf())，正如unicode相關的編譯錯誤中所描述的那樣。所有wxWidgets函數，如wxPrintf()、wxLogMessage()和c仍然可以使用它，但是將它傳遞給printf()將導致崩潰。強烈建議使用編譯器重新編譯您的代碼，編譯器會警告將非pod對象傳遞給vararg函數，比如g++。
wxString::c_str()類型的改變也會導致編譯錯誤，因為它會將結果傳遞給一個重載的函數來同時獲取窄字符串和寬字符串，在這種情況下，你必須選擇你真正想要使用的版本，例如:

void OpenLogFile(const char *filename); void OpenLogFile(const wchar_t *filename); wxString s; OpenLogFile(s); // ERROR: ambiguity OpenLogFile(s.c_str()); // ERROR: ambiguity OpenLogFile(s.wx_str()); // OK: function called depends on the build OpenLogFile(s.mb_str()); // OK: always calls narrow string overload OpenLogFile(s.wc_str()); // OK: always calls wide string overload

在Microsoft Visual c++標準庫實現中的std::fstream類構造函數中出現了此類問題的一個常見示例。除了這個類必須具有的const char *構造函數之外，它還提供了一個采用寬字符文件名的構造函數。因此，代碼如下所示

#include <fstream> void MyFunc(const wxString& filename) {std::ifstream ifs(filename.c_str());... }

總結

以上是生活随笔為你收集整理的wxWidgets随笔(5)-utf8中文(1)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。