Unicode und FPC/Lazarus

[mischi]

Die Sprache nicht, die endlose TP/shortstring und Unicode Posts hier wiegende, bin ich mir weniger Sicher von die Anwender :_)

Die ganzen Codier Sachen sind immer ein Problem. Ich weiß auch nicht warum. Jedesmal wenn es um Umlaute geht, muss ich auch erst mal schauen, wie die Lösung war. Früher hat das besser geklappt....

Aber auch nur, wenn man auf seinem System und in seinem Land blieb. Es ist doch genau die Ursache für den ganzen Kuddelmuddel, dass man den ganzen Ballast aus alten Tagen mit schleppen muss, weil es zum Beispiel noch eine Tonne von alten Daten in der alten Codierung gibt.

[mschnell]

Man hätte das Unicode-Problem wesentlich besser (flexible und kompatibler, ohne schlechtere Performance in Kauf nehmen zu müssen) angehen können. Ich habe darüber auch einen Artikel im Wiki verfasst. Aber Embarcadero hat es komplett verbaselt und die FPC Crew hat sich nicht getraut das neu zu gestalten, statt den Mist nachzubauen.

-Michael

[Michl]

@mschnell:
Die Stringgeschichte ist doch nun schon lange durch. Die Welt dreht sich weiter, mit oder ohne die perfekte Implementierung von Strings. Irgendwelche Kompromisse wird es immer geben müssen, wenn man nativ und gleichzeitig plattformübergreifend entwickeln will. Nicht nur das, man muss auch gute Konzepte haben, um externe Bibliotheken oder Datenformate zu unterstützen, die öfters ihre eigenen Strings unabhängig vom OS mitbringen.

Ich selber mag die derzeitige Implementierung, nachdem ich sie erstmal verstanden hatte. Auch finde ich UTF-8 kodierte Strings gemütlicher, als UTF-16, da dort noch auf LE und BE aufgepasst werden muss.

Wie gesagt, diese Diskussionen wurden schon vor einer ganzen Weile geführt. Der/die Eine oder Andere findet sicherlich Kritikpunkte an der aktuellen Implementierung. Daß Lazarus seinen eigenen Weg gegangen ist, war auch nicht immer auf Verständnis von Seiten FPC gestoßen. Doch das Kriegsbeil ist mit Verlusten begraben, bitte begrab es doch auch!

Danke

Michael


PS: schön zu sehen, an diesem Beispiel, daß Pascal nicht tot ist, sondern ständig weiterentwickelt wird

[mschnell]

um externe Bibliotheken oder Datenformate zu unterstützen, die öfters ihre eigenen Strings unabhängig vom OS mitbringen.

Genau darum geht es ja.

Das was eigentlich schiefgelaufen ist, ist, dass TStrings nach außen einen Stringtyp verwendet, der eine feste Codierung hat und sich nicht je nach Anwendung flexibel anpassen kann. Dadurch kommen diverse Inkompatibilitäten zustande. Und nötig ist das nicht, aber von Embarcadero so vorgegeben.

(Und dass das Thema "durch" ist, heißt nicht, dass der Status quo zufriedenstellend ist.)

-Michael

[pluto]

Und nötig ist das nicht, aber von Embarcadero so vorgegeben.

na und? Wozu gibt es den Delphi Modus? Im normalen Modus kann das ja anders gehandhabt werden. Oder spricht was dagegen?

[Mathias]

Am besten haben es die Amis, die haben keine Umlaute in ihrer Sprache.
Die Umlaute im deutschen sind eigentlich auch noch gnädig, "öäüÖÄÜ" mit diesen 6 Stück kann man leben.
Aber nehmen wir mal die Franzosen mit ihren "^çéàèÉÀÈÇ" oder sonstige Sprachen "Ïï".

Ich habe mir angewöhnt möglichst wenig Umlaute für System-Sachen zu verwenden, ZB. Dateinamen, Ini-Files, etc.
Bei Dialogen oder Menus, welcher der Benutzer sieht, ist es was anderes.

Aber immerhin, ist Pascal nicht alleine mit diesem Problem, C++, etc. kämpfen auch damit.

[mschnell]

na und? Wozu gibt es den Delphi Modus? Im normalen Modus kann das ja anders gehandhabt werden. Oder spricht was dagegen?

Der Vorschlag wurde auch gemacht, vom den fpc-Team aber abgelehnt.

Ein weiteres Problem ist auch die dämliche Art wie die String-Library implementiert ist. Es gibt eine Library für 1-Byte Chrs (ANSI und UTF8) und eine weitere unabhängige für 2-Byte Chars (UTF-16) und gar keine für 4-Byte Chars (UTF-32). Um also etwas wirklich sinnvolles zu machen, mit Strings die statisch und/oder dynamisch alle sinnvollen String-Typen enthalten können, müsste man die Library komplett um bzw neu schreiben. Und man ist froh, dass man gerade geschafft hat alle Delphi Quirks ziemlich kompatibel einzubauen.

-Michael

[Patito]

Am besten haben es die Amis, die haben keine Umlaute in ihrer Sprache.
Die Umlaute im deutschen sind eigentlich auch noch gnädig, "öäüÖÄÜ" mit diesen 6 Stück kann man leben.
Aber nehmen wir mal die Franzosen mit ihren "^çéàèÉÀÈÇ" oder sonstige Sprachen "Ïï".

Solange die Amis nicht anfangen Tasten wie 'F12' zu drücken...
Sobald man Daten verarbeiten muss, die nicht im Unicode-Standard drin sind
(Barcodes, Tastaturcodes, zufällige Filenamen, ... ... .............), wird es mit aktuelleren
Versionen von FPC schwierig.

Praktisch gesehen muss man als fortgeschrittener Programmierer (falls man bei FPC bleiben will) jetzt
anfangen einen eigenen String-Typ zu bauen. Und die Unterstützung für Konstanten durch den Compiler
hat man dabei dann leider auch komplett verloren.

Vielleicht sollte man FPC mehr als, "Special Purpose" Lernsprache vermarkten - und das auch offen zugeben.
Bei den letzten paar Versionen von FPC hat sich immer irgendetwas subtil an den String-Typen geändert.
Für den Profi-Bereich könnte es langsam schwierig werden Leute zu finden, die bereit sind ein Vertrauensverhältnis zu FPC aufzubauen.

[marcov]

Und nötig ist das nicht, aber von Embarcadero so vorgegeben.

na und? Wozu gibt es den Delphi Modus? Im normalen Modus kann das ja anders gehandhabt werden. Oder spricht was dagegen?

DIalekt modi operieren nur auf Dialekt, nicht auf Units.

[pluto]

DIalekt modi operieren nur auf Dialekt, nicht auf Units.

und das ist der Grund, warum man es den Programmierer unnötig schwer machen muss?

Dann führt man eben ein zweiten String Typ ein: fString oder so ähnlich.

[Mathias]

Solange die Amis nicht anfangen Tasten wie 'F12' zu drücken...

Was hat dies mit Strings zu tun ?

Vielleicht sollte man FPC mehr als, "Special Purpose" Lernsprache vermarkten - und das auch offen zugeben.
Bei den letzten paar Versionen von FPC hat sich immer irgendetwas subtil an den String-Typen geändert.

Wieso sollte dies eine Lernsprache sein. Mit C++ muss man sich auch mit UTF8, Unicode, etc. rumschlagen, weil das ein OS-Problem ist.

[marcov]

DIalekt modi operieren nur auf Dialekt, nicht auf Units.

und das ist der Grund, warum man es den Programmierer unnötig schwer machen muss?

Natürlich! Wir tun nie etwas ohne die Absicht alles extra schwer zu machen, und es macht uns besonders Spaß wenn wir mit unser eigene Jahrelange Planung durchgehen, eben wenn User in 5 Minuten völlig aus gewirkte alternative Planen auf die Hinterseite eines Bierzettel gemacht haben. Wir denken dann, wir machen das extra schwer, und gehen mit unsere bewerte 6 Jahre alte Planung durch.

Speziell wenn sie von Michael Schnell kommen der nach 400 Unicode Mails im List noch immer nicht Wusste wie die Implementierung funktionierte. Nichtsdestotrotz war er klar der Experte.

[mschnell]

Wenn sich andauernd jede Menge frustrierte User beschweren - nicht über die Implementierung, sondern darüber wie man mit dem Produkt umgehen muss, und auch nicht über die Unterschiede zwischen fpc und Delphi, sondern sehr oft auch über das, was beiden gemeinsam ist oder das, was bei fpc/Lazarus auffällt, weil es Plattform-übergreifend arbeitet und Delphi nur auf Windows - ist doch klar, dass man mit dem Status Quo nicht zufrieden sein kann und versuchen sollte, bessere Ideen zu entwickeln. (Einen Vorschlag habe ich ja schriftlich im Wiki ausgeführt.) Ich habe immer nur mit Vorschlägen auf solche Beschwerden anderer User reagiert und nie selber Beschwerden vorgebracht, sondern mit Dank an das Team immer betont, dass natürlich das, was fpc/Latzarus zum jeweiligen Zeitpunkt bietet, meilenweit besser ist als wenn man ganz auf fpc/Lazarus (und da,mit portablen Object Pascal Code) verzichten müsste.

Auch jetzt gilt natürlich immer noch, dass die aktuelle historisch gewachsene Implementierung und die der (meiner Ansicht nach schlecht konzeptionierten) Delphi-Arbeitsweise nachgebaute Arbeitsweise, es den Usern durchaus erlaubt, Platform-übergreifende Programme zu schreiben. Und darauf kommt es in erster Linie an! Ich würde nie dem Entwickler-Team vorwerfen, dass es Verbesserungs-Vorschläge nicht umsetzt, weil sie eine aufwändige Umstrukturierung erfordern. Die Zeit, die die Mitglieder dankenswerter Weise einbringen können ist eben begrenzt. (Dass Embarcadero mit wer weiß wie vielen bezahlten Mitarbeitern so einen unüberlegten Mist - also TStrings mit fester Codierung - hervorbringt, ist viel bedenklicher.)

Übrigens kann man dieselbe Diskussion über die innere Struktur der LCL "WidgetSet" (aka "Interface") Implementierung führen (haben wir auch schon). Dass jedes einzelne Interface eine komplett eigene (z.B. Queue-) Implementierung hat und nicht von einer gemeinsamen Objekt-orientierter Basis die verschiedenen Interfaces so abgeleitet werden, so dass möglichst viel Code gemeinsam verwendet wird, ist halt historisch bedingt und eine Änderung wäre sehr aufwändig und natürlich zu nächst einmal fehlerträchtig. Ich habe volles Verständnis dafür, dass niemand das angeht, auch wenn dadurch die zukünftige Implementierung neuer WidgetSets erheblich vereinfacht würde. Dass es aber geht, zeigt mse-GUI.

Man muss etwas gutes nicht verdammen, auch wenn man sich etwas besseres vorstellen kann. Es ist immer zu bedenken, dass eine Verbesserung / Alternative an den zur zur Verfügung stehenden Ressourcen scheitert. Trotzdem ist es sinnvoll gemeinsam darüber nachzudenken. Sonst ist kein Fortschritt möglich.

-Michael (hat sie auch nie für einen Experte für die existierende Unicode Implementierung gehalten )

[Michl]

Wenn sich andauernd jede Menge frustrierte User beschweren

Man man man, warum machst du sowas? In den Foren sind Fragen bzgl. der neuen Implementierung / Stringmagic schon lange bevor FPC 3.0.0 publiziert wurde diskutiert worden. Lange war bekannt, daß es eine Änderung geben wird. Alles ist auch dokumentiert:
FPC: http://wiki.freepascal.org/FPC_Unicode_support
Lazarus: http://wiki.freepascal.org/Better_Unico ... in_Lazarus

Beschwerden kommen mMn von Usern, die sich nicht mit dem Thema auseinandersetzen wollen oder können. Eine GUI-Anwendung unter Lazarus ist doch sehr komfortabel, da intern UTF-8 kodierte Strings verwendet werden. Man braucht sich also nur noch Gedanken machen, welche Kodierung bei der Kommunikation nach außen verwendet werden muss. Das ist so simple.

Beschwerden wie,

Sobald man Daten verarbeiten muss, die nicht im Unicode-Standard drin sind
(Barcodes, Tastaturcodes, zufällige Filenamen, ... ... .............), wird es mit aktuelleren
Versionen von FPC schwierig.

würde ich nicht überbewerten, da Patito ein sehr erfahrener Programmierer ist und sicher weiß, wofür man Strings einsetzen kann und wo ein Array of Byte oder ähnliches sinnvoller ist.

Bist du dennoch überzeugt, daß die Richtung, die FPC oder Lazarus eingeschlagen haben, eine Falsche ist, so kannst du gern versuchen einen Fork zu machen (vielleicht würden Gleichgesinnte dich sogar dabei unterstützen, die Suche nach solchen sollte dann aber nicht per Bashing in einem themafremden Thread erfolgen) und es den Uneinsichtigen zeigen, wie man es richtig macht. Beispiele dafür gibt es.

Ansonsten, versuche doch die aktuelle Implementierung zu verstehen und anderen Usern zu helfen, die ebenfalls Probleme damit haben. Und wenn du nur einem User hilfst, ist es doch mehr wert, als ihn davon zu überzeugen, daß wenn man das so oder so gemacht hätte, er das Problem nicht hätte. Oder?

[m.fuchs]

Ich frage mich, was ich die ganze Zeit falsch mache. Ich kann mich nicht erinnern, jemals mit FPC über ein Encoding-Problem gestolpert zu sein.