[fpc-devel] Unicode support (yet again)

[Luiz Americo Pereira Camara]

On 13/9/2011 22:56, Luiz Americo Pereira Camara wrote:
> On 13/9/2011 17:14, Graeme Geldenhuys wrote:
>>> 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

This approach has the advantage of leading to minimum conversion between 
user string type and native string type

Scenario - RTL with a fixed string type (UTF16/UnicodeString) both in 
windows and unix:

A) User code with UnicodeString
0 conversions  - Under windows: no conversion between user code and rtl 
and between rtl and native api
1 conversion  - Under unix: no conversion between user code and rtl but 
conversion between rtl and native api

B) User code with UTF-8
1 conversion  - Under windows: conversion between user code and rtl but 
no conversion between rtl and native api
2 conversions  - Under unix: conversion between user code and rtl and 
between rtl and native api

The same applies for a RTL that compiles a fixed string parameter type 
like UTF8 or ansi

Using RTLString the max number of conversions is 01 (user code and rtl) 
since always rtl and native string will have the same encoding

Luiz