[fpc-devel] Unicode support (yet again)

Luiz Americo Pereira Camara luizmed at oi.com.br
Wed Sep 14 03:56:44 CEST 2011


On 13/9/2011 17:14, Graeme Geldenhuys wrote:
> On 13 September 2011 21:25, Marcos Douglas wrote:
>> Graeme Geldenhuys, sometime, written that string type shoud be
>> depended of plataform. I agree with him, but I don't know if this is
> +1  ;-)
>
>
>> the easiest way... but this is be best way to codify our programs,
>> don't you think?
> UnicodeString should meant UTF-8 on Linux, *BSD, MacOSX etc
> Unicodestring should mean UTF-16 on Windows.
>


I propose that the above behavior be implemented as a type named RTLString

and

keep UnicodeString as UTF-16 for compatibility


The string parameters of the RTL functions should be declared with RTLString

So the RTL under unix will have functions compiled with UTF8 strings 
giving no overhead interacting with native API
The RTL under Windows will have compiled functions with UTF16 strings 
giving no overhead with native API

If a program is pass a UnicodeString to a RTL function under Windows no 
conversion is made
When this same program is compiled under unix the UnicodeString should 
be converted to UTF8 automatically using the encoding info of the string


Luiz


> That way you will have the best performance on each platform, because
> the string type is native to each platform.
>
> All string function in the RTL should be unicode aware, and not make
> stupid assumptions as is done so often with AnsiString (the whole 1
> byte being 1 char).
>
>
> PS:
> I still can't believe Delphi was that stupid making the assumption
> that Unicode (as in UnicodeString) = UTF-16. Especially now that they
> are starting to support other platforms too, the name "unicodestring"
> now doesn't always mean the native string type. :-(  FPC should make
> this mistake.
>




More information about the fpc-devel mailing list