[Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

[Ondrej Pokorny]

On 05.05.2017 12:01, Michael Van Canneyt via Lazarus wrote:
> On Fri, 5 May 2017, Ondrej Pokorny via Lazarus wrote:
>> Believe me, I use it in production without any problems: I have 
>> unicode-aware TStrings, I can read files with unicode names, I can do 
>> everything with plain FPC trunk.
>
> I am aware of this, I do it myself. But I work on Linux, where UTF8 is 
> the norm.
>
> So I cannot vouch for other platforms...

For now I am only on Windows and I have to say loadly: IT WORKS GREAT :)

>> I don't need a 100% UTF-16 Delphi-Compatible RTL for that at all.
>
> This is the crux of the problem. Is this wanted/needed or do we stick 
> to UTF8 ?
>
> We claim Delphi compatibility. So IMHO we must provide a UTF-16 Delphi 
> compatible RTL.

I write code that is compatible with FPC and Delphi 5 - 10.2 and it 
works fine. So you already have a Delphi-compatible RTL. The only (well 
documented) difference is that FPC uses single-byte string and Delphi 
uses 2-byte string.

The only place where you need to handle the difference is where you need 
the size of char (when you access string as buffer) - which is 
particularly low-level code:

MyStream.WriteBuffer(MyString[1], Length(MyString) * SizeOf(Char));

-> you need the extra SizeOf(Char) and not a constant (1 for fpc, 2 for 
unicode Delphi).

That's all. All high-level code is compatible already. Good job. I 
really do think it's not worth it to pollute FPC RTL with UnicodeString 
overloads of every function, class etc.

Better to keep 1 clean approach (UTF-8 RTL) and not confuse people with 
2 approaches (UTF-8 vs UTF-16). E.g. how do you want to call the new 
UnicodeString-TStrings class? You have 2 options:
1.) Break compatibility to legacy FPC. (New TStrings will use 
UnicodeString.)
2.) Break compatibility to Delphi. (TStrings will stay with 8-byte string.)

There is no obvious solution for the problem :/

And then if you will introduce a compiler switch to change String from 
1-byte to 2-bytes... Oh no, so much mess and so many variants to care 
about. Really, sometimes it's better to give people no options :) (Or 
have you already introduced the switch?)

Just stick with current utf8 approach that proved well :)

Ondrej