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

["Gerry Iles" <GerryI@xxxxxxxx>]

> - 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