4 ms·
I was under the assumption, that Linux and Mac OS (size of(wchar_t)==4, ergo UCS-4, because it was clear from the beginning, that 16bit won't do it. A compromis
by yokaze 7y ago
I was under the assumption, that Linux and Mac OS (size of(wchar_t)==4, ergo UCS-4, because it was clear from the beginning, that 16bit won't do it. A compromise "only" windows and java was willing to make. But they went out all the way through the stack.
Linux goes for byte stream encoding (e.g utf-8), because it isn't (/wasn't) doing any string processing. So, encoding efficiency beats algorithmic complexity of string operations. If you need an algorithmic more efficient encoding, that's up to your application, and ucs-4 was the way to do it.
- justincormack 7y agoThats not really a Linux assumption. It is a gcc one, but you can use 16 bit wchar with as flag too. Almost no one uses wchar on Unix anyway.
- Someone 7y agoCertainly on Mac OS, sizeof(wchar_t) had nothing to do with the way text strings got stored. The Mac had an elaborate system for handling international text that used either bytes or 16-bit quantities for text storage, where the interpretation of what a byte or byte pair meant was stored separately from those bytes. https://developer.apple.com/library/archive/documentation/mac/pdf/Text.pdf https://developer.apple.com/library/archive/documentation/ma...: ”The character codes may be 1-byte or 2-byte codes, but there is nothing else in the text stream except for those codes. Using font information that your program stores separately, Script Manager routines can help you determine whether a character is 1 or 2 bytes, and other managers allow you to work with either character size.” More cumbersome to use than modern Unicode API’s? Definitely, but it was superior to what Windows provided for years.