Talk:Development: UTF-8 Support

From WxWiki

One of the problems with this approach is the confusion that will no doubt arise over the difference between wxChar and wxUniChar. Especially since wxUniChar is going to be treated as BOTH a char and a wchar_t, while in unicode mode wxChar is only to be treated as unicode :D:D:D. Also, about wxUSE_UNICODE - I think the point is that if it is NOT defined people will expect ANSI and if it is they expect something different from ANSI, so obviously you'll want it defined in this approach although code compatability is going to be difficult anyway... while windows is going to be a problem its a good idea though and hopefully turns into something :D -- RyanN

A suggestion on UTF-8 build under Windows, how about just supporting MinGW MSys configure builds. -- Tim S (stahta01)

Will it be possible to use the UTF-8 wxString class under windows as well? I have a lot of text in UTF-8 format in my applications, and currently I have to do a lot of conversion back and forth. It would be nice if I could keep it in a UTF-8 version of wxString (wxStringUTF8?), which would automatically convert if passed to functions needing wxString. -- Jim K

I think we're trying to make wxString too smart. String classes aren't supposed to be smart. In particular, CStrData implicitly convertible to const char* and const wchar_t* is just a Bad Idea. UTF-8 aware iterators that turn common O(N) jobs into O(N^2) are a Bad Idea. Generalizing, a developer who does not know or care what a wchar_t is is not going to write a correct Unicode application, and surprising behaviors like this from a string class aren't going to help. I think I'm going to keep using wxWidgets 2.6 at my place of employment for a long time. -- Jeremy S