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


More information about the fpc-devel mailing list