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 Cox <email@hidden>
- Date: Tue, 13 Apr 2010 15:19:49 -0700
On Tue, Apr 13, 2010 at 2:40 PM, Paul Sanders
<email@hidden> wrote:
>> 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.
>
> I don't agree with this comment. If swprintf can assume that a wchar_t is
> wider than 8 bits, it can safely ignore the current locale.
Just because it's wider than 8 bits doesn't mean that it can ignore
the locale. You are assuming that the UTF's and UCS's are the only
encodings that are wider than 8-bits. There is nothing stopping
wchar_t from representing GB18030.
>> As specified by the C and C++ standards, wchar_t is largely useless. I
>> would recommend avoiding it at all costs.
>
> If, as I have, you replace what I consider to be a broken swprintf
> implementation with something that treats wchar_t transparently, wchar_t
> works just fine, and gives me (and the OP) what we seek - the ability to
> re-use our existing TCHAR-based Windows code on the Mac.
If the goal is to re-use the TCHAR-based code on the Mac, just define
TCHAR as a no op, and use plain char. The compilers on the Mac support
UTF-8 string literals. That is, the following code is fine on the Mac
and works as expected:
[ccox@ccox-macpro:~]% cat test.m
#import <Foundation/Foundation.h>
int main() {
const char *cstring = "My name is Clark. 私の名前はクラークです。Ich heiße Clark.";
NSString *nsstring = @"My name is Clark. 私の名前はクラークです。Ich heiße Clark.";
printf("%s\n%s\n", cstring, [nsstring UTF8String]);
return 0;
}
[ccox@ccox-macpro:~]% cc test.m -framework Foundation -fobjc-gc && ./a.out
My name is Clark. 私の名前はクラークです。Ich heiße Clark.
My name is Clark. 私の名前はクラークです。Ich heiße Clark.
> This comment
> applies to the entire wide vprintf and fprintf family of course, but this is
> not hard to cobble together. wfprintf is of limited utility anyway - UTF-32
> encoded files are very rare.
>
> Another issue is bridging the gap between wchar_t strings and NSStrings, but
> I have a couple of utility routines to do that. Anyone who wants these is
> welcome to a copy.
>> 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).
>
> Once upon a time, there were no surrogate pairs. That's what I meant.
That time when there were no surrogate pairs was also a time where
there was no UTF-16. I just wanted to point out that no matter how
old, any software that claims to read/write UTF-16 *must* support
surrogate pairs.
> And
> I wanted to inform / remind any interested parties of their existence. For
> Windows programmers, where all the WIN32 APIs assume that wchar_t is 16
> bits, they are a regrettable but necessary hack.
I think we are in violent agreement on this point :)
> But I guess I was a little sloppy in my use of terminology there.
>
> Paul Sanders - 'focussing on the practical'.
>
--
Clark S. Cox III
email@hidden
_______________________________________________
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