[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