[Lazarus] cwstring in arm-linux

[Hans-Peter Diettrich]

Michael Schnell schrieb:
> On 10/20/2011 09:18 AM, Martin Schreiber wrote:
>> Now the FPC team destroyed a stable product in favor of
>> Delphi string compatibility.
> I don't consider the current state of Lazarus "stable", as IMHO the 
> "UTF8 in type ANSIString" paradigm (seemingly forced by the underlying 
> FPC version) is too "special" to stay.

It's sufficient to agree that all (displayed) strings in the LCL contain 
UTF-8 text, regardless of their type name (string types currently are 
alias).

> As I don't have a Delphi > 2009, I have no idea if the "new" Delphi way 
> to handle Unicode is desirable or even better at all. So this is not 
> meant as a criticism whatsoever.

Delphi allows for an UTF8String type, but this one is (or has to be) 
converted into UnicodeString all the time. The Delphi RTL only supports 
UnicodeString (UTF-16) and native AnsiStrings (of CP_ACP), all other 
encodings are not really supported, except for UTF-16 conversion. MBCS 
are supported only as far eastern DBCS, not for UTF-8 (I wonder what a 
Linux version will bring).

Functions with more than one (Ansi)String argument deserve special care, 
the *user* is responsible to only supply strings of the same encoding, 
or has to force the use of the UnicodeString versions by e.g. typecasts.

I.e. it's highly discouraged to use any but CP_ACP or UTF-16 strings, 
except for corner cases (file I/O...).


When FPC follows the new Delphi model, the LCL has to be ported to all 
strings containing UTF-16 - everything else will not work properly or 
causes many implicit conversions. This may require some work, and 
results in two incompatible versions (legacy Ansi/UTF-8 and new 
Unicode/UTF-16), and will not please all Linux (POSIX) users. IMO Linux 
is not a problem with the LCL, since the currently required UTF-8/16 
conversions with external function calls are neglectable (on my Windows 
system).

DoDi