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
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
