Graeme Geldenhuys via fpc-pascal <fpc-pascal@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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
