RE: [XaraXtreme-dev] Discussion of string portablility problems

["Gerry Iles" <GerryI@xxxxxxxx>]

Ok, I'll do the various search and replaces and make sure the build is
still working then I'll knock up a new documentation page describing the
available functions, the use of %s and what our various macros expect in
terms of _T() and concatenation...

Gerry

-----Original Message-----
From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On
Behalf Of Neil Howe
Sent: 04 April 2006 14:57
To: dev@xxxxxxxxxxxxxx
Subject: RE: [XaraXtreme-dev] Discussion of string portablility problems


Ok Gerry, given that we've seen no other comments about this I suggest
you go ahead with your suggestion of using the wx functions.

Thanks

Neil

> -----Original Message-----
> From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx]
On
> Behalf Of Gerry Iles
> Sent: 03 April 2006 18:58
> To: dev@xxxxxxxxxxxxxx
> Subject: RE: [XaraXtreme-dev] Discussion of string portablility
problems
> 
> > - Generally I prefer the option of using the standard printf
functions
> > rather than trying to replace them with our own or trying to build
> > layers on top, since this is presumably what most incoming Linux
> > developers will be used to working with. So they won't have to learn
> how
> > to call our own special functions. If they do have to learn
something
> > new that's another barrier to new developers becoming productive.
> 
> The word "standard" implies that everyone implements it the same and
> while this is pretty much the case when using non-unicode functions
> (e.g. printf) it isn't the case with the Unicode versions of the
> functions.  Lots of platforms implement Unicode support and TCHAR
> support in particular differently (as the complexity of wxchar.h
shows).
> 
> The wxWidgets standard is to name the function the same as the
> non-unicode version but with the first letter capitalised and prefixed
> with wx, e.g. strcpy becomes wxStrcpy.  How common is the use of
Unicode
> in linux apps?  How about TCHAR?  I would have thought that most apps
> designed to be portable would need to handle string handling
> inconsistencies in some sensible way.
> 
> > - I presume with the wx functions that Linux developers who are used
> to
> > specifying %ls for wide character strings can still do so and won't
> have
> > to remember to use %s all the time which they won't find natural.
> 
> Only developers that routinely build Unicode will be used to using
%ls.
> Using %ls will still work on unicode builds as long as it is a C lib
> function and not one of our own.
> 
> > - Gerry - is the reason you prefer the wx function route because it
> > requires the least code changes from where we are now? In other
words
> is
> > it the fastest way forward?
> 
> Sort of.  It might actually be a little bit faster to leave it as it
> currently is and for me to rebuild XarLib from the current XaraLX
code.
> 
> The more significant reason is that it allows us to get rid of the
> really horrible PERCENT_S macro and standardises the use of %s in all
> the functions.  Also, it means the API for string manipulation will be
> provided in one place by the Oil layer (where platform dependent
things
> are meant to be) which will make it easier to switch to a different
> framework in the future if that ever becomes necessary.
> 
> I should be able to go through the code and replace most of the string
> functions in a couple of hours (simply by searching for the various
> things defined in compatdef.h) and then a little bit more time will be
> needed to find any use of specifically non-unicode functions and deal
> with them appropriately.
> 
> Gerry