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

[Juha Manninen]

On Mon, May 1, 2017 at 12:30 PM, Tony Whyman via Lazarus
<lazarus at lists.lazarus-ide.org> wrote:
> When I originally created the Firebird Pascal API package, I wrote it with
> FPC as the only intended target ...

I guess you used the old Unicode support with explicit UTF-8
conversion functions.
Things have improved a lot since then. You should read this page:
 http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus


> 2. All strings declared explicitly as AnsiString expect where they are used
> with system calls (e.g. FileNames).

No no no!
AnsiString is not compatible with Delphi any more. It is an
unfortunate side-effect of the new Unicode support.
However using "String" type works like magic in a Delphi compatible
way at source level, despite their different encodings.
So, do NOT use AnsiString explicitly.

> However, as FPC defaults to AnsiString and Delphi to WideString

No, Delphi defaults to UnicodeString, not WideString.
Lazarus with its Unicode support defaults to AnsiString with encoding
changed to UTF-8. Thus it is NOT compatible with AnsiString in Delphi.

> it is usually a good idea to be explicit in your string types.

No! The good idea is to use "String".


> 3. PByte instead of PChar.
> Most uses of PChar in FPC/Lazarus aren't to character strings but are
> instead used to point to untyped buffers.

"Some uses", not "most uses". In both Delphi and FPC strings and PChar
have been misused for binary data but it was never recommended. Such
code must be fixed anyway.


> 5. Take care when using string literals.
> I added
> {$IFDEF FPC}
> {$codepage UTF8}
> {$ENDIF}

Yes, string literals are tricky but usually you should NOT use {$codepage UTF8}.
It is explained in the wiki page. I will not repeat it here.


> I added an explicit UTF8Encode to force the literal to UTF8 before assigning
> to the string.

You don't need UTF8Encode any more. That also means your code can be
100% Delphi compatible at source level despite their different
encodings.


> 7. Generics

For Delphi compatible generics you can use FPC trunk and the Generics
Collection lib made by Maciej.


> 8.TSystemCodePage does not exist in Delphi
> ...
> if you are using any Ansistring code page functions.

Windows system codepages are not supported by the new Unicode system.
You must convert such data explicitly by SetCodepage() or such.
This is the only thing not compatible with neither Delphi nor the old
Lazarus solution. :(
However the world is moving to Unicode and this is less and less of a problem.


> I hope you find this a useful checklist.

It contained so much false information that it only confuses people. :(

I want to repeat that it is possible to write code dealing with
Unicode that is fully compatible with Delphi at source level.
It will be compatible with a future UTF-16 solution in Lazarus as well.
Encoding agnostic (UTF-8 / UTF-16) code is possible even if you must
iterate individual codepoints. See the wiki page for details.

Remember these to keep your code compatible:
 1. Normally use type "String".
 1. Assign a constant always to a type String variable.
 2. Use type UnicodeString explicitly for API calls that need it.

Juha