Quote:Original post by Instigator
I keep hearing about this UNICODE stuff. I'm actually using Win XP Pro SP2. What effect would it have on me turning this off through the project settings?
Generally what does this mean, and why would anyone want it "turned on" if all it does is cause compiler issues?
The simple explanation is this:
in C++, a regular char is only 1 byte wide. That's not enough to represent international characters. Hence the need for bigger characters.
Enter the unicode character set. This is an absolutely huge list of pretty much any character you can imagine. And to fit this into C++, you have two options. Either use variable-length characters using UTF8 (Windows will do this if you disable Unicode), which means that ASCII characters are represented as single bytes, but everything else are made up of multiple bytes. This works, but makes manipulating strings much more complicated (you need to scan through a string to determine the number of characters in it, instead of simply being able to look at its length in bytes. And you can't just split a string at arbitrary positions because you might chop a character into two.
Alternatively, you can use bigger fixed-width characters. That's what you get when you enable unicode in your Win32 project.
To use unicode, you need to use:
- wchar_t instead of char (wchar_t is a wide char, under Windows this is 16 bit)
- L"foo" instead of "foo" (the L tells the compiler to make a LONG character literal, that is, a wchar_t* instead of a char*)
- std::wstring instead of std::string (and the same for std::wcout, std::wstringstream and so on)
And no, it doesn't cause compiler issues.
But consider an API containing functions that take or returns characters or strings. If a function expects a string, do you give it a wchar_t* or a char*?
The answer is, it depends on the API, of course.
In the case of the Win32 API, it can use both. The entire API is implemented twice, once using Unicode, and once without. And which one gets used depends on your compiler settings.
If you have Unicode enabled, then *all* Win32 functions will expect wchar_t where they otherwise would have expected char. if you give them a char, you get an error.
The solution is fairly simple. Either disable unicode, or just give the functions the correct arguments. Or explicitly call the version you want. To give an example, CreateWindow is actually just a macro. One that maps to either CreateWindowA (for ASCII) or CreateWindowW (for Wide), depending on whether Unicode is enabled. The *A functions use char's, the *W functions use wchar_t. So if you have unicode enabled, but want to, say, show a message box with a non-unicode string, you just call MessageBoxA instead of MessageBox.