Marco van de Voort schreef:
Marco van de Voort schreef:
It looks simple to me, there are just 2 ways to go, either utf-8 or
utf-16.
There are more possibilities:
- native encoding (utf-8 on *nix, utf-16 on windows)
- have two types.
How can one write portable code with these options?
How can you consider yourself portable by picking one systems encoding, and
emulating it on others?
At the borders of my I convert all strings to the 'internal type' and encoding and
use it like that. Kind of like we are doing nowadays to convert the line-endings in
text files.
I see what you are trying to say, but having a string type that is UTF8 encoded on
one system and UTF16 encoded on another system, doesn't seem easy to work with to
me, even if you name it for example RTLString. Even widestring is an example of bad
portability, because they are refcounted everywhere except on windows.
Note also that reliance on encoding is way less important, since fewer
people will be parsing through strings manually (simply because it is more
difficult)
Right, but they rely on not having to convert it all the time.
ATM, all the client libs above the RTL have chosen one encoding, string type: LCL en
fpGUI: UTF8, MseGui: widestring
So for those libs to interface with a platform dependent string type in the LCL,
they would have to write platform dependent code. I don't feel much like writing a
LCLSysutils.FileExists, like Graham already has done, to hide these conversions.
Vincent
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
