However compiling the same code in $mode delphi using FPCThe correct mode is {$mode delphiunicode} which is the same as Delphi's 16 bit unicode.
FPCunit GUI crashes when I try to copy,Use the right mouse, and copy from the context menu.
The project options syntax mode default is ObjFPC, so that's not it, and Use AnsiStrings is on. I suppose that's wrong, but why is simple unicode working?I'm not sure if this is clear or not: Ansi-String doesn't mean the string is limited to the ANSI-characters, but also could contain Unicode in form of UTF-8. You shouldn't need any WideString/UnicodeString or anything else to use Unicode characters, only if it's for library reasons that use UTF-16.
umm, I'm having trouble understanding this. I think this means that in 2020 there's still no way to actually write source that is unicode capable and consistent between FPC and delphi?Why you expect 100% Delphi-compatibility?
there is some strange happenings when the two of those are side by side and its not json string doing it..As I understand it, its a composed character. The #$0338 is combined with #$2267 to one character on the display.
Actually using an alternate first Unicode char with the u0338 still produces the error.
This line of code in delphi:
dict.add('≧̸', #$2267#$0338);
This line of code in delphi:
dict.add('≧̸', #$2267#$0338);
Adds to dict, which is a TDictionary<String, String>, the string pair ≧̸ and '≧̸'.
However compiling the same code in $mode delphi using FPC results in adding the string pair ≧̸ and '??'. But this works for other unicode characters like:
dict.add('≠', #$2260);
which is '≠' in both delphi and FPC.
The difference is that in the case of #$2267#$0338 the compiler does a compile time conversion
For the single character FPC will do a runtime conversion
The difference is that in the case of #$2267#$0338 the compiler does a compile time conversionQuoteFor the single character FPC will do a runtime conversion
Why the different behaviour? Both are constant values? Both could be done at compile time?
Is this only because "What Delphi does"? How about mode ObjFpc?
// compiler has different codepage than a system running an application
// to prevent wrong codepage and data loss we are converting unicode char
// using a helper routine. This is not delphi compatible behavior.
// Delphi converts UniocodeChar to ansistring at the compile time
Moreover (concluding from compiler warnings), if a char-constant is part of a constant expression that results in a string, then it appears to be converted at runtime?or is the added string/char first converted to widechar/string, then added, and the result converted back?
If I remember correctly this is indeed how this behaves in newer versions of Delphi if the left side is indeed a AnsiString.
When HIGHCHARUNICODE is OFF:
All decimal #xxx n-digit literals are parsed as AnsiChar.
All hexadecimal #$xx 2-digit literals are parsed as AnsiChar.
All hexadecimal #$xxxx 4-digit literals are parsed as WideChar.
When HIGHCHARUNICODE is ON:
All literals are parsed as WideChar.
As for Delphi String = UnicodeString you won't notice this, cause there won't be any conversion necessary.
If I remember correctly this is indeed how this behaves in newer versions of Delphi if the left side is indeed a AnsiString.
The behavior has nothing to do with the type used on the left side of the assignment. The behavior is controlled by the {$HIGHCHARUNICODE} (http://docwiki.embarcadero.com/RADStudio/en/HIGHCHARUNICODE_directive_(Delphi)) directive instead:QuoteWhen HIGHCHARUNICODE is OFF:
All decimal #xxx n-digit literals are parsed as AnsiChar.
All hexadecimal #$xx 2-digit literals are parsed as AnsiChar.
All hexadecimal #$xxxx 4-digit literals are parsed as WideChar.
When HIGHCHARUNICODE is ON:
All literals are parsed as WideChar.
As for Delphi String = UnicodeString you won't notice this, cause there won't be any conversion necessary.
In FPC, String=AnsiString in {$mode Delphi}, and String=UnicodeString in {$mode DelphiUnicode} and {$modeswitch UnicodeStrings}.
> Why you expect 100% Delphi-compatibility?
Well, I don't. Clearly there's areas where there isn't. But when it comes to something as fundamental as unicode, and as uibiquituous as string handling, then I do expect a clearly documented way to write code that delivers source code compatibility, yes.