Apple

Thanks, Paul. Yes, I understand and agree with you entirely. I have got my own compatibility library going now which does wrap wchar_t as you describe, and after solving the swprintf locale issue -- thanks to you and others on this list -- I think it works adequately. I'm sure there will be other traps lurking for me, but fundamentally the core engine compiles and handles Unicode characters successfully.

On 14 Apr 2010, at 14:15, email@hidden wrote:

Message: 10
From: "Paul Sanders" <email@hidden>
Subject: Re: swprintf fails with extended character codes

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.