Re:An update on GNU performance
by ploxiln on Sunday October 21, 2018 @07:46PM
(#18271051)
I honestly didn't know that ... I've never actually used the libc wchar_t functions :)
[ Parent
| on HN ]
Good, because nobody should use wchar_t at all. It's the API that was thought up by people who got drunk and asked themselves "how can we make this char situation even worse?" wchar_t is widely recognized as one of those huge mistakes from the 90s, along with UCS-2. Today you should store strings in as bytes using UTF-8 and if you need to handle them in a fixed-width format you would choose an explicit 32-bit-wide type.
Re:An update on GNU performance
by colejohnson66 on Monday October 22, 2018 @11:37AM
(#18275517)
Except when you’re on Windows and have to use WCHAR to handle Unicode characters because they use UCS-2, not UTF-8
On Windows WCHAR is defined to hold a 16-bit unicode character, and is defined to be unsigned. In standard C wchar_t can be any damn thing, and isn't even guaranteed to be wider than char. It can be signed or unsigned. It is useless.