[Lazarus] cwstring in arm-linux
DrDiettrich1 at aol.com
Thu Oct 20 13:55:37 CEST 2011
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
> 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
More information about the Lazarus