Unicode support in wxWidgets

In wxWidgets, the code fragment from above should be written instead:

    wxChar ch = wxT('*');
    wxString s = wxT("Hello, world!");
    int len = s.Len();

What happens here? First of all, you see that there are no more #ifdefs at all. Instead, we define some types and macros which behave differently in the Unicode and ANSI builds and allow us to avoid using conditional compilation in the program itself.

We have a wxChar type which maps either on char or wchar_t depending on the mode in which program is being compiled. There is no need for a separate type for strings though, because the standard wxString supports Unicode, i.e. it stores either ANSI or Unicode strings depending on the compile mode.

Finally, there is a special wxT() macro which should enclose all literal strings in the program. As it is easy to see comparing the last fragment with the one above, this macro expands to nothing in the (usual) ANSI mode and prefixes 'L' to its argument in the Unicode mode.

The important conclusion is that if you use wxChar instead of char, avoid using C style strings and use wxString instead and don't forget to enclose all string literals inside wxT() macro, your program automatically becomes (almost) Unicode compliant!

Just let us state once again the rules:

• Always use wxChar instead of char
• Always enclose literal string constants in wxT() macro unless they're already converted to the right representation (another standard wxWidgets macro _() does it, for example, so there is no need for wxT() in this case) or you intend to pass the constant directly to an external function which doesn't accept wide-character strings.
• Use wxString instead of C style strings.