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

[Mattias Gaertner]

On Fri, 5 May 2017 10:01:24 +0100
Graeme Geldenhuys via Lazarus <lazarus at lists.lazarus-ide.org> wrote:

>[...]
> > AFAIK you are using UTF-8 in AnsiString in FPC 2.6.4. That works in
> > many cases, because of double fooling the compiler. This trick does not
> > work on Windows with RTL file functions though.  
> 
> Yes and true, but fpGUI supplies its own "wrapper" RTL file functions, thus
> it works 100% on all platforms for years. I believe LCL used to do the same.

Yes, and with FPC 3.0 many of them are no longer needed.

 
> RawByteString type (yet another string type in FPC & Delphi's arsenal) did
> not exist at the time, otherwise I would probably have defined...
> 
>   TfpgString = RawByteString;
> 
> and used that everywhere.

How would that help?

  
> > Of course it would be nicer, if we don't need tricks to get Unicode.  
> 
> Indeed, and that is why I love solutions implemented by Java and Qt
> Framework. They are simple, it works and not confusing.

IMO you are comparing apples and oranges.
The FP compiler provides a very easy Unicode solution - or even two
(UTF-8 and UTF-16). The problem are the old RTL and libs, which are
written for system encoding, not for Unicode.
You can design in FPC an Unicode RTL just like Java and QT. fpgui and
LazUtils are kind of a start of that.
Or you can help FPC finishing the Unicode RTL. So stop complaining and
help them.


> Even Embarcadero
> is doing some string type clean-up. Their new Linux compiler completely
> removed AnsiString support. After all, why do you need any other
> string types when you support the Unicode standard.

That's true for most cases.
I wonder what they do when you need to access the raw 8-bit file names,
or work with large amount of 8-bit strings.

Mattias