On 14/9/2011 03:48, Felipe Monteiro de Carvalho wrote:
[..]
Of course one path is migrating everything, the LCL, the IDE, SynEdit,
all packages, etc, to UTF-16, but that's a huge, immense work with
zero advantages over what we are doing up to now, it's just migrate to
migrate, who will be motivated to do that? My point is that it is not
very reasonable to migrate so much working code for no advantage at
all, so the Unicode RTL could provide something to easy interfacing
with UTF-8, for example:
* overloaded versions of routines and methods for utf8string
* A TStrings and TStringList for utf8
Using the approach i described (RTLString) in other mail this (massive
LCL code change) is not required. Probably just "load from file"
functions like TStrings etc.
Lazarus/LCL could stay as is (UTF8) and would work as today:
Under unix: no conversion is done since the LCL and RTL encodings are
the same
Under Windows: conversion UTF8 -> RTLString (UTF16) is done once
These would need to be ifdefed so they are not present in the Ansi
RTL. Without even a TStrings for utf-8 one cannot really expect
Lazarus to be able to use the Unicode URL without doing a full
migration to UTF-16 ...
My final point is just: why not? If code in the RTL could fix things
for Lazarus why impose the need to migrate so much working code?
Because if someone for some reason, like porting Delphi code, stays with
a UTF16 string, under windows, when using RTL functions TWO conversions
will be made:
User Code (UTF16) > RTL (UTF8) > WINAPI (UTF16)
Always using the same encoding in RTL and Native API will keep the
maximum conversion number at 01
Luiz
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
