[fpc-devel] Unicode resource strings
Mattias Gaertner
nc-gaertnma at netcologne.de
Tue Aug 21 16:37:40 CEST 2012
On Tue, 21 Aug 2012 10:23:10 -0300
Marcos Douglas <md at delfire.net> wrote:
>[...]
> >> I guess there is no good solution for TStrings. Whatever string type is
> >> chosen, some programs will suffer.
> >
> > Why will some suffer? Simply default UnicodeString to the correct
> > encoding on each platform, and no performance issues and no
> > unnecessary conversions will occur.
>
> Make much sense and AFAIK so far no one has said why this approach
> would not work.
First of all: How do you define the "native encoding"?
The encoding of the file system? Ext4 does not have one, HFS+ knows
only normalized UTF-8.
The encoding of readln/writeln? That depends on environment options
rather than OS.
The Unicode functions of the system libraries? Most applications
rarely use them, but rather use frameworks like fpGui, MSEGui or the
LCL. Linux does not have such functions.
Make a poll? Then you should not call it "native encoding".
Second: Why is it bad to have a platform dependent string type?
- More test work. It's not sufficient any more to test a string
function on one platform, you have to test it on all platforms. That's
especially hard for projects where some developers have only access
to a few OS.
- Harder to optimize. It's easy to write a few optimized functions for
one encoding. With multiple encodings you have to write multiple
versions.
- Loss of simplification. Some things are easy in one encoding, some
are not. Because you have to support all encodings, you have to
always implement the difficult encoding too.
Mattias
More information about the fpc-devel
mailing list