[fpc-pascal] Unicode chars losing information

[Sven Barth]

Graeme Geldenhuys via fpc-pascal <fpc-pascal at lists.freepascal.org> schrieb
am Di., 9. März 2021, 00:56:

>
> On 07/03/2021 5:48 pm, Nikolay Nikolov via fpc-pascal wrote:
> > It depends on what you mean by "just working".
>
> No, "just worked" is exactly what it says on the tin. It is FPC that
> overcomplicating matters.
>
>
> As an example, here is Java that also uses UTF-16 encoding, just like
> FPC's UnicodeString type.
>
> ====================================
> $ cat UnicodeTest.java
> class UnicodeTest {
>
>     public static void main(String[] args) {
>         String s = "⌘⌥⌫⇧^";
>         System.out.println(s);
>         System.out.println(s.charAt(0));
>         System.out.println(String.format("%x",s.codePointAt(0)));
>     }
> }
> ====================================
>
> Now lets compile and run that.
>
> $> javac UnicodeTest.java
> $> java UnicodeTest
> Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on
> ⌘⌥⌫⇧^
> ⌘
> 2318
>
> Yes, it just worked.
>

That is because the Java runtime contains all the conversion code
necessary. In FPC we simply don't do that, cause it either requires linking
to the C library (especially for simple utilities that can be easily
avoided) or requires a huge amount of conversion tables. Thus developers
need to explicitly opt in for using Unicode conversions by including a
WideString manager.

FPC is not Java. In FPC you have more fine-grained control over the
resulting binary than "install big, fat runtime". Not to mention that FPC
can target resource constrained systems as well.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20210309/ca143c22/attachment.htm>