[fpc-devel] Unicode support (yet again)

[Luiz Americo Pereira Camara]

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