FROM : Brady Duga
DATE : Tue Mar 04 19:32:28 2008
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
DATE : Tue Mar 04 19:32:28 2008
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 mail archive

