Re: swprintf fails with extended character codes
Re: swprintf fails with extended character codes
- Subject: Re: swprintf fails with extended character codes
- From: "Paul Sanders" <email@hidden>
- Date: Wed, 14 Apr 2010 13:29:37 +0100
On 04/14/2010 11:02 AM, Ben Staveley-Taylor wrote: > > Knowing
now how unportable and vaguely specified wchar_t is, I realise > that we
should have avoided it all those years ago when we did our > Unicode
Windows codebase. Things are always clearer in hindsight!
Ben, don't
throw the baby out with the bathwater. Having overcome the swprintf issue,
and with the benefit of a few utility routines to convert between TCHAR [],
UTF-8 [] and NSString, I am now happily using my existing TCHAR-based code
in my cross-platform app. I much prefer this approach to rewriting a
substantial, well-tested code base. As a matter of coding style, I find
the power of swprintf and the convenience of walking a pointer through a TCHAR *
hard to beat, but I think a lot of that is just habit.
Contact me off-list if you'd like a few code snippets. No charge
:) You will need to hack them around to suit your needs (they are
part of a larger 'Windows Compatibility' library) but it's all downhill once the
foundations are in place. Like you, I struggled with missing
or incompatible Windows runtime library functions on the Mac when I first
started bringing my code across.
Paul Sanders.
|
_______________________________________________
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