[fpc-devel] Unicode and UTF8String

Mattias Gaertner nc-gaertnma at netcologne.de
Tue Dec 2 00:18:30 CET 2008

On Mon, 1 Dec 2008 21:23:34 +0100 (CET)
marcov at stack.nl (Marco van de Voort) wrote:

> In our previous episode, Mattias Gaertner said:
> > > In our previous episode, Mattias Gaertner said:
> > > > > 
> > > > > I see this as a theoretic consideration. Please give a real
> > > > > world (!) code example when this causes a problem.
> > > > 
> > > > Can you give a real world example where a different RTLString
> > > > for each platform solves a problem?
> > > 
> > > It avoids pingpong repeated conversions between OS encoding and
> > > whatever encoding is default.
> > 
> > A real world example please.
> I don't have to. If you guaranteedly have two encodings into place and
> combine code out multiple sources this will happen for sure.

If RTLString is several encodings this will happen for sure. And worse:
It will happen more often depending on library and platform.

> Keeping as much as possible in the system encoding, will limit this
> only to legacy packages that haven't been properly ported yet, and at
> least a hope staying away from converison hell.

This depends on the apps.
You can optimize for one encoding or optimize for one per platform. I
know how to optimize for widestrings, for ansistring and for UTF-8
strings, but I have no experience in optimizing for multiple
encodings. Maybe someone who did that can give some advice.
The real world problem is (as Florian wrote): Some platforms have no
choice, because they only support 'ansi'.

I welcome the RTLString type. And I don't care what encoding is used
for slow RTL functions and I trust that you have more experience than
me to find a good solution here.
But for TStrings I think multiple fixed encodings will make more
trouble than Jonas' (dynamic encoding) and Lazarus' (one encoding for
all platforms) ideas.


More information about the fpc-devel mailing list