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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
