>> theoretische vs praktische Probleme
Die Unterscheidung zwischen "theoretischen Problemen" (gemeint sind wohl Fehler, die sich mit einem bisschen Wissen und Geschick umgehen lassen) und "praktischen Problemen" (gemeint sind wohl Fehler, die sich gar nicht oder nur mit erheblichem Aufwand umgehen lassen und damit die Produktivität auch desjenigen, der die Probleme schon kennt, erheblich einschränken), ist für ein inhouse-Produkt sinnvoll, nicht aber für ein von vielen Usern unterschiedlichen Typs benutzten Tools.
Jede praktisches Problem beruht auf einem theoretischen Problem.
Jedes theoretische Problem wird sich irgendwann, bei irgendeinem User, unter irgendwelchen Umständen in einem praktischen Problem manifestieren.
Man braucht nur zu versuchen, ein von 20 Leuten erstelltes eine-Million-Zeilen Programm mit einem Nachfolger-Programmiersystem an's Laufen zu bringen, das eine Menge solcher "theoretischen Probleme" aufweist. (Genau das versuchen meine Kollegen gerade beim Umstieg auf das Unicode-fähige Delphi: Furcht, Angst und Schrecken!)
Und wenn beim aktuellen Lazarus eine einfache, klare und Zulässige Anweisung wie "MYWIDESTRING := '1ä2ö'; " zu einem völlig sinnlosen Ergebnis führt, ist das m.E. nach ein
echtes Problem (wenn auch nach obiger Definition ein theoretisches, weil es sich ja theoretisch vermeiden lässt indem man keine Widestrings benutzt). Dasselbe gilt für alle weiteren bisher angeführten Unicode-Beispiel-Probleme.
Leider ist (sprach-spezifischer) ANSI-Code und Unicode (gleich welcher internen Codierung) in keiner nativen Weise kompatibel.
ANSI ist eine 8-Bit-Zeichen-Codierung. Unicode ist eine 32-Bit Zeichen-Codierung.
Ein String ist aus Sicht des Anwenders eine Folge von Zeichen
Ein ANSI-String ist demzufolge eine Folge von (8-Bit) ANSI Zeichen.
Ein Unicode-String ist demzufolge eine Folge von (32-Bit) Unicode-Zeichen. Egal wie die interne Codierung technisch gelöst wird.
Das kann nicht ohne Kompatibilitätsprobleme abgehen. (Ganz zu schweigen von "Surrogate Pairs" und ähnlichem <s.o.>.)
Eine Zuweisung "MYANSICHAR := MYUNICODECHAR; " führt zwingend zu Informationsverlust (wenn der betreffende Unicode-Character in der aktuell eingestellten ANSI-Variante nicht existiert). Für Strings gilt natürlich dasselbe entsprechend.
Der Versuch der aktuellen Lazarus-Version, ANSIStrings uns spezielle Unicode-Strings (UTF-8 codierte) einfach als identisch zu definieren ist demzufolge zum Scheitern verurteilt, auch wenn in 90% der betroffenen Programmzeilen (z.B. a := b + c;) problemlos derselbe Prozessorcode für die Operation verwendet werden kann, wenn alle beteiligten Operatoren in derselben Art (entweder ANSI oder UTF-8) codiert sind.
Wenn die Typen einfach eigenständig und inkompatibel deklariert wären und, wenn notwendig, entweder eine implizite Konvertierung erfolgen würde, oder eine Fehlermeldung erzeugt würde, hätten wir das Problem nicht. (Das ist vermutlich ein FPC-"Problem" und von Lazarus nicht korrigierbar.) Eine Portierung eines Programmes würde zu massenweise Fehlermeldungen führen, aber nicht zu einem Programm, das stillschweigend Unsinn produziert.
Um die Portierung existierender Programme auf ein Unicode-System zu erleichtern, führt Delphi Strings mit dynamischer expliziter Codierung ein. (FPC und damit Lazarus werden dem folgen müssen <dass wir D2009 Strings in FPC demnächst haben werden, wurden hier schon erwähnt>.)
Ob das der Stein der Weisen ist, wird in den Delphi Foren lebhaft diskutiert. Wir werden es hier demnächst erleben.
Die aktuelle Lazarus/FPC-Version ist jedenfalls nicht dafür geeignet, größere bestehende Programme zu übersetzen. Man müsste sich jede einzelne Zeile anschauen, ob da nicht ein "Problem" angetriggert wird. Deshalb hoffe ich auf eine zukünftige.
-Michael
, und hat kein echtes Problem.
. Das würde ich aber gerne, um es zu ermöglichen ihr System auf Linux laufen zu lassen.
Verein
Links
Suche
