FPC Unicode support

[mschnell]

d.h.Kompatibilität und Performance spielen beim FPC Team eine grosse Rolle.

Da habe ich schon drauf geachtet.

Solange man nicht die rein zusätzlichen Möglichkeiten (voll dynamich codierter Typ und "PrintableCharachter"-Typ / case/ Iterator) benutzt ist das alles kompatibel mit Delphi (wenn der default String-Typ UTF16 ist), und mit dem aktuellen Stand von Lazarus (wenn der Default-String Type UTF8 ist). Die Performance wird durch ist auch nicht schlechter, es sei denn man aktiviert die Beachtung der (de-)composed Character beim Vergleich. Da alles auf der normalen (String-Verarbeitung (inclusive "nicht dynamischer" Umcodierung basiert, ist auch in der RTL nicht allzuviel zu ändern - hier fehlt "on top" nur noch die Behandlung der (de-)composed character (was natürlich ein ziemlicher Hammer ist, aber zunächst defaultmäßig abgeschaltet sein könnt)

-Michael

[theo]

Ich denke die decomposed Strings sollte man nicht überbewerten, die kann man an den Schnittstellen normalisieren.
Aber für den vollen Unicode Bereich gibt es noch diese netten Surrogate bei UTF-16. Was damit tun?

[marcov]

d.h.Kompatibilität und Performance spielen beim FPC Team eine grosse Rolle.

Da habe ich schon drauf geachtet.

Solange man nicht die rein zusätzlichen Möglichkeiten (voll dynamich codierter Typ und "PrintableCharachter"-Typ / case/ Iterator) benutzt ist das alles kompatibel mit Delphi (wenn der default String-Typ UTF16 ist), und mit dem aktuellen Stand von Lazarus (wenn der Default-String Type UTF8 ist).

Auch ohne das ist das kompatibel, weil Delphi da nichts garantiert.

Du sagst einfach "es funktioniert meistens für mich", aber ein Engländer würde das auch von UTF8 sagen.

[mschnell]

Du sagst einfach "es funktioniert meistens für mich", aber ein Engländer würde das auch von UTF8 sagen.

Reichlich unprofessionelle Haltung
-Michael

[mschnell]

"Was meinen denn die FPC-Entwickler zu deinen Vorschlägen?"

Für die bin ich ein unproduktiver meckernder Troll. Wer Visionen hat, sollte zum Augenarzt gehen.

-Michael

[theo]

Für die bin ich ein unproduktiver meckernder Troll. Wer Visionen hat, sollte zum Augenarzt gehen.

Da gibt's ein sicheres Gegenmittel: Branchen und denen das Gegenteil beweisen.
http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/" onclick="window.open(this.href);return false;

[mschnell]

Branchen und denen das Gegenteil beweisen.

Wenn man die Interna des Compilers nicht schon gut kennt, dürfte dem - eigentlich simplen - Einbau irgendwelcher neuen Features ein unüberschaubarer Einarbeitungs-Aufwand vorausgehen, während es wahrscheinlich leicht wäre, bei der Umstellung auf Unicode "mit der Linken Hand" noch ein paar (voll kompatible) Verbesserungen gegenüber Delphi zu berücksichtigen (sofern diese vorher ordentlich durchdacht und abgestimmt sind).

Wie bereits - auch von Marcov - erwähnt, sollte erst anständig überlegt und diskutiert werden und danach erst "gebrancht" werden, sonst kommt dabei das besagte "für mich funktioniert das meistens irgendwie" heraus, das (mit einigem Recht) die Methodik der Community-Projekt immer wieder in Verruf bringt: gute Features, guter Code, schlechte Doku, Probleme beim Einsatz auf Gebieten die nur zu 99% zum ursprünglich angedachten Zweck dienen.

-Michael

[mse]

Aber für den vollen Unicode Bereich gibt es noch diese netten Surrogate bei UTF-16. Was damit tun?

Nichts. Solange man die nicht trennt passiert nichts und man muss sich nicht darum kümmern, wenn man die Bedeutung der damit dargestellen Zeichen oder Symbole gar nicht kennt. Programme die mit Symbolen ausserhalb der BMP arbeiten und deren Bedeutung kennen, müssen mit denselben Methoden arbeiten, die auch für utf-8 bereits für 'ä' verwendetet werden müssen. Die Implementierung ist für utf-16 wesentlich einfacher, da die Anzahl code units pro codepoint entweder 1 oder 2 beträgt. Bei utf-8 gibt es mehr Versionen zu berücksichtigen.
Ich kann dir versichern, dass die wenigsten FPC Nutzer je in die Lage kommen werden, sich um surrogate pairs zu kümmern. Liuzg, ein sehr aktiver chinesischer Nutzer des FPC-GUI Systems das mit utf-16 arbeitet, der häufig auf unserer mailing list anzutreffen ist und kommerzielle chinesische Programme damit baut, hat sich noch nie über Probleme mit surrogate pairs beklagt.
Bitte unterlasst schnoddrige Kommentare, oder ich werde zum Thema Unicode auf lazarusforum.de für immer verstummen.

Martin

[mschnell]

Solange man die nicht trennt passiert nichts

IMHO: Doch. Es gibt dadurch "Zeichen", die für den Anwender gleich sind, aber unterschiedlich codiert werden können. Deshalb muss das bei Vergleichen berücksichtigt werden, wenn man nicht sicher ausschließen kann, dass die Dinger jemals auftreten können.

Das gleiche bescheuerte Problem wie bei nicht case-sensitiven Dateisystemen: Dieselbe Datei in diesem Directory ist gemeint, obwohl die Namen-Strings unterschiedlich sind. Da hilft nur "UPcase". (Dann funktiuoniert das Programm aber natürlich bei "ordentlichen" case sensitiven Dateisystemen nicht mehr.)

Soweit ich informiert bin, kommt das von Theo angesprochene Problem gerade bei Mac-Dateisystemen zum Tragen.

(Auch wenn Theos Tonfall nicht immer ganz passend ist, haben seine Kommentare doch meist einen sehr relevanten Hintergrund. )

-Michael

[mse]

Solange man die nicht trennt passiert nichts

IMHO: Doch. Es gibt dadurch "Zeichen", die für den Anwender gleich sind, aber unterschiedlich codiert werden können. Deshalb muss das bei Vergleichen berücksichtigt werden, wenn man nicht sicher ausschließen kann, dass die Dinger jemals auftreten können.

Decomposed characters kann man ausschliessen, wenn man keine produziert oder einliest. FPC liefert für character und string Konstanten die Form, die im Quellcode steht. Falls dein Editor keine decomposed character produziert, von denen du nichts weisst, stehen auch keine solchen im code. User-Eingaben werden von den mir bekannten Betriebssystemen in fully composed Form geliefert, für andere könnten sie durch das verwendete GUI-System normalisiert werden. Das scannen von einzelnen Zeichen oder auch Zeichenfolgen in Dateien geschieht ja in der Regel auf Daten die man selbst erzeugt hat, da kann man die gemischte Verwendung von composed und decomposed Form ebenfalls ausschliessen. Die dir vorschwebende Eindeutigkeit "sichtbarer Zeichen" und deren Anzahl und Index in strings ist im gesamten Unicode Bereich ist meiner Meinung nach sowieso eine Illusion und für den "Normalprogrammierer" irrelevant. Ich glaube nicht, das die Definition der Programmiersprache damit belastet werden sollte.
Bitte finde dich damit ab, vollkommene Unicode Behandlung ist eine schwierige Sache und lässt sich mit vernünftigem Aufwand und performance nicht vollautomatisch sicherstellen.
Bitte lies z.B. einmal nach, was zur korrekten Unicode Stringsortierung alles notwendig ist.
Beispielsweise hat praktisch jedes Land wieder eigene Sortierregeln, so dass richtigerweise auch die Sprache und Region in den dir vorschwebenden universell korrekten Unicode string Typen codiert gehört.
Auch die Notwendigkeit, verschiedene Codierungen ausser utf-16 und der aktuellen 8-bit Systemcodierung innerhalb eines Programmes zur Laufzeit von Compiler und RTL automatisch und dynamisch umzucodieren sehe ich nicht. Falls so etwas von einem Programm benötigt wird, soll eine entsprechende Bibliothek wie theos Unicode tools verwendet werden, in den Sprachgrundumfang gehört das nicht.
Ich möchte nochmals erwähnen, dass FPC die automatische Konversion von/zu utf-16 und aktueller 8 Bit Systemcodierung schon seit Jahren kennt. Meiner Meinung nach ist auch der cpstrnew zur compile time Bestimmung der notwendigen Konversionen eine unnötige Komplizierung und Ballast.

Martin

Edit:
Mir scheint du verwechselst immer noch "surrogate pairs" und "decomposed characters"?

[mschnell]

für den "Normalprogrammierer" irrelevant.

Marcov hat das Thema aufgebracht. Ich wäre von mir aus nie auf die Idee gekommen, das berücksichtigen zu wollen.

Aber wenn immer wieder der Einwand kommt, dass alles keinen Zweck hat, wenn man die (de-)composed Zeichen nicht berücksichtigt, kann man das bei der Diskussion doch nicht einfach fallen lassen.

Sortierung: Da hast Du natürlich vollkommen recht. Ich hatte in meinem Vorschlag das Thema "Vergleich" angesprochen, aber bin nur auf gleich und ungleich eingegangen. Es gibt in Pascal natürlich auch noch den String-Vergleich auf "größer". Das ist sicher noch ein heißes Thema. In den String-Typ gehört das m.A. aber nicht, wie soll man dann Strings mit verschiedenen Typen vergleichen ? Die Sortierfolge ist eher eine Einstellung der der RTL, die man dynamisch ändern können sollte.

Ich finde schon, dass man die Sprache mit solchen Sachen "belasten" sollte. Sie sollten nur irgendwie "abschaltbar" sein, wenn man sie nicht braucht. (Per Default abgeschaltet, solange die Implementierung noch nicht genügend ausgereift ist.)

Notwendigkeit zur automatischen Umcodierung:
Wenn die Programmnier-Umgebung die Verwendung von Unicode erzwingt und verschiedene Codierungen in Strings zulässt, ist die automatischen Umcodierung offensichtlich notwendig.

Bestimmung der Umcodierung zur Compile-Zeit:
Ich vermute, als Embarcadero den Unicode-Support definiert und eingebaut hat, war zunächst ein vollständig dynamischer String-Typ angedacht, keine verschiedenen String-Typen mit (halbwegs) fester Codierung.

Dann haben die gemerkt, dass das ständige überprüfen der aktuellen Codierung die Performance reduziert und haben die festen Typen in einem Schnellschuss obendraufgepackt.

-Michael

[mse]

Bestimmung der Umcodierung zur Compile-Zeit:
Ich vermute, als Embarcadero den Unicode-Support definiert und eingebaut hat, war zunächst ein vollständig dynamischer String-Typ angedacht, keine verschiedenen String-Typen mit (halbwegs) fester Codierung.

Dann haben die gemerkt, dass das ständige überprüfen der aktuellen Codierung die Performance reduziert und haben die festen Typen in einem Schnellschuss obendraufgepackt.

Das sehe ich auch so. "Marketing" ist ein weiteres wichtiges Stichwort.

Martin

[theo]

Bitte unterlasst schnoddrige Kommentare, oder ich werde zum Thema Unicode auf lazarusforum.de für immer verstummen.

Ich auch.

[marcov]

Du sagst einfach "es funktioniert meistens für mich", aber ein Engländer würde das auch von UTF8 sagen.

Reichlich unprofessionelle Haltung

Das Problem mit Sarkasmus ist das es oft nicht bemerkt wird:

Also EXAKT das ja, unprofessionel. Das ist GENAU auch weshalb ich gemeckern wie "eingeschränkt funktioniert "es"(*) für Deutsch doch" nicht interessiert bin, und nur für die voller Unicode Spezifikation gehe. Und welcher Implementation hängt vom Platform ab

[mschnell]

Solange man die nicht trennt...

Genau darum geht es aber bei dem besagten Enumerator. wenn er sie erkennt, könnte er sie zusammenlassen und es "passiert nichts". Ob er sie erkennen kann, ist die andere Frage. Wenn er sie nicht berücksichtigt, erkennt er sie auch nicht und "es passiert".

-Michael