在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
void MyFunc(const wxString& filename)
{
std::ifstream ifs(filename.c_str());
...
}