[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

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.



> -----Original Message-----
> From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx]
> Behalf Of Gerry Iles
> Sent: 03 April 2006 18:58
> To: dev@xxxxxxxxxxxxxx
> Subject: RE: [XaraXtreme-dev] Discussion of string portablility
> > - Generally I prefer the option of using the standard printf
> > 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
> > 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
> 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
> 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
> 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
> 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
> 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
> 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