To be clear, I'm not trying to say that 16-bit wchar_t has no value.
Honestly, I think Apple should have much better support for it. If
you're porting an app from Windows, you probably have to deal with
WCHARs in some fashion. I'd like to say I have a radar for it but I'm
honestly not sure. It's been a few years since the last time I had to
deal with 16-bit wchar_ts. At the time I remember needing to borrow
large chunks of MSL from CodeWarrior, and getting it to compile on
Xcode… bleck.
Brady Duga wrote:
On Mar 4, 2008, at 10:13 AM, John Stiles wrote:
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.
If you need to.
The limitations here make it difficult to leverage 16-bit wchar_t
effectively, IMO.
I use a fairly large library that is integrated with a Cocoa app that
uses 16 bit wchar_t. It is an emulation environment, so having 16 bit
wchar_t is important for testing purposes. Works fine. Also, any
libraries that might be used across platforms needs to be wchar_t size
agnostic, though in that case you can probably get away with assuming
returned wchar_ts are 32 bit when on the Mac. In any case, it is
generally best not to assume you know the size of a wchar_t (and there
is rarely a need to assume it).
--Brady
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
