FROM : John Stiles
DATE : Tue Mar 04 19:13:23 2008
Brady Duga wrote:
> On Mar 4, 2008, at 8:25 AM, Dave Camp wrote:
>>
>> You actually have two problems here:
>>
>> 1) wchar_t on the Mac is a 4 byte per character container (32 bits).
>
> Not quite correct. wchar_t, may, at this time, default to 4 bytes in
> an Xcode project, but it is *not* defined to be 4 bytes on the Mac. In
> fact, it is quite easy to make wchar_t be 2 bytes. Assumptions about
> the actual size of a wchar_t are probably a bug.
Yes and no.
You can tell the compiler to treat wchar_t as 16-bit and it will happily
comply.
However, don't expect to be able to use any standard library calls in
this mode. wcslen, wcscpy, wcscat? Roll your own. swprintf?
Just forget about it.
The limitations here make it difficult to leverage 16-bit wchar_t
effectively, IMO.
DATE : Tue Mar 04 19:13:23 2008
Brady Duga wrote:
> On Mar 4, 2008, at 8:25 AM, Dave Camp wrote:
>>
>> You actually have two problems here:
>>
>> 1) wchar_t on the Mac is a 4 byte per character container (32 bits).
>
> Not quite correct. wchar_t, may, at this time, default to 4 bytes in
> an Xcode project, but it is *not* defined to be 4 bytes on the Mac. In
> fact, it is quite easy to make wchar_t be 2 bytes. Assumptions about
> the actual size of a wchar_t are probably a bug.
Yes and no.
You can tell the compiler to treat wchar_t as 16-bit and it will happily
comply.
However, don't expect to be able to use any standard library calls in
this mode. wcslen, wcscpy, wcscat? Roll your own. swprintf?
Just forget about it.
The limitations here make it difficult to leverage 16-bit wchar_t
effectively, IMO.






Cocoa mail archive

