Re: Xcode-users Digest, Vol 7, Issue 153
Re: Xcode-users Digest, Vol 7, Issue 153
- Subject: Re: Xcode-users Digest, Vol 7, Issue 153
- From: "Clark S. Cox III" <email@hidden>
- Date: Tue, 13 Apr 2010 08:51:34 -0700
> I'm still baffled by the need for a locale. I thought the whole point of UTF-32 (which is what wchar_t strings boil down to) was to get rid of locale issues. I think I'll raise a bug on this one.
I agree about the locale thing; I was seriously put out when I tripped over it, but if you google the *Linux* swprintf man page it does state that wide characters will be interpreted by locale, although this is clearly 100% undesirable for 99.99% of developers.
That is required by the Standard. There is nothing in the C standard that guarantees that wchar_t uses UTF-32, it could use any other encoding. As such, it *must* be interpreted by locale.
OS X seems to have inherited this behaviour (via the GNU C library, presumably) but the OS X man page is a direct copy of the corresponding POSIX page, and says nothing on the matter.
It seems to me that someone at glibc HQ messed up here but I doubt if it will get fixed now as there are no doubt programs out there that rely on the existing behaviour. Yuk, sloppy work.
As specified by the C and C++ standards, wchar_t is largely useless. I would recommend avoiding it at all costs.
Just for completeness, mapping between UTF-16 strings and Unicode, although, sadly, no longer a 1:1 affair,
FYI, the conversion between UTF-16 and UTF-32 has never been a 1:1 mapping. You're thinking of UCS-2 (which is identical to UTF-16 except for the surrogate pairs, and is often mistakenly called UTF-16).
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden