A rant about cross-platform programming with wchar_t
losingfight.com
losingfight.com
Besides, the whole point of wchar_t is to not be variable width. UTF-16 in wchar_t is an abomination that dates back to the industry building APIs that take UCS-2 (which the author really ought to cover) before they realized UCS-2 was too narrow to do its job. So now we have a lot of code that appears to support Unicode but may not handle it correctly, depending on whether QA knew they should try surrogate pairs. Almost nobody realizes UTF-16 needs to be searched and spliced as carefully as UTF-8. Each is just a compression scheme for the million or so actual codepoints, and there aren't many reasons to favor one over the other (in memory, at least).
What's the actual problem here, the team made assumptions that ANSI warned against making? Apple failed to accept UCS-4 for their API?
It may be trivial to solve, but it's certainly not an issue anyone should have to solve, if the C++ standards committee would have dictated size and encoding information along with the datatype.
all of the C++ types have platform dependence - expecting a specific number of bits or encoding for wchar_t would make an exception of it, and one that would be impossible to implement in practice.