On 10/10/2011 17:56, Jonas Maebe wrote:
On 10 Oct 2011, at 22:11, Luiz Americo Pereira Camara wrote:
1- Most of LCL must be code page agnostic, so not use UTF8String/AnsiString
directly (keep String)
There is no difference between ansistring and string in {$mode delphi} and
{$mode objfpc}
OK.
There's just one problem using $mode to define the string behavior: say
you have a component written in {$mode delphi}. Than code written in
{$mode delphiunicode} uses that library.
. In a future delphiunicode mode or something like that string will be
unicodestring
What about the Marco proposition of having separated versions of
RTL/Classes for UTF8 / UTF16? Or did i miss something?
, but that's not "code-page agnostic" either. The only somewhat code page
agnostic string type is RawByteString.
I dont mean string type unicode agnostic. I mean code unicode agnostic,
i.e., will work regardless of the code page
2- It should have (dont know if currently has) a compiler switch to change the
default code page to UTF8 or whatever, so all variables with type String will
map to UTF8String.
I doubt that such a feature will be added. If you want that, declare your own
string type with whatever default code page you want to use and use that type
everywhere.
Ok. This in practice will force Lazarus to go to UTF16 since renaming
all string types of LCL from String to UTF8String is a no-no, at least
for me.
Luiz
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
