FPC Unicode support

[mschnell]

Auf jeden Fall ist dies alles der Performance und der Einfachheit des Compilers und der Laufzeitumgebung nicht zuträglich.

Sag ich doch. Wenn es außerdem Verwirrung stiftet, anstatt sich wenigstens aus Anwender-Sicht "ordentlich" und "verständlich" zu verhalten, ist offensichtlich bei der Definition der Funktionalität, also vor der Implementierung nicht genügend nachgedacht bzw. diskutiert worden.

Noch hat FPC die Chance, es besser / sauberer / verständlicher / zu altem Code kompatibler zu machen als Delphi. Was aber zu schlechtere "Default" Performance führen muss und man demzufolge dem Programmierer mit höchsten Ansprüchen entsprechende Möglichkeiten zum Performance-Tunig an die Hand geben müsste (just dreaming).

-Michael

[marcov]

Vier.
Du hast "Anzahl der 16bit Speicher Einheiten" vergessen, falls du mit "Unicode-Code-Elemente" "code points" meinst.
Falls "Unicode-Code-Elemente" "Anzahl der 16bit Speicher Einheiten" meint, hast du "code points" vergessen.

http://en.wikipedia.org/wiki/Code_point

Martin

Und nicht vergessen das Codepoints<>glyphen. Also ein Codepoint ist nicht notwendig 1:1 mit ein printbares Character.

[marcov]

Für cpstrnew und UnicodeString wird der gleiche Record verwendet.
Eine UnicodeString Variable hat aber immer die "2: array[0..0] of WideChar;" Form. AFAIK...

Ja, das gemeinsames Record ist fuer RawByteString.

[marcov]

Bei Delphi: "UnicodeString kann Unicode- und ANSI-Strings enthalten."

Ich habe zwar beides nicht, aber meine Kollegen haben mir erzählt dass sich das zwischen "Delphi 2009" und "Delphi XE 2" in diversen Aspekten geändert hat und erheblich verbessert worden ist (in welcher Hinsicht auch immer).

In XE ist es wie in D2009, und ich bin auf mehrere Embarcadero XE2 Vorstellungen gewesen, und da (und alles ander das ich ueber XE2 gelesen habe) gab es keine unterscheiden darin zwischen 2009..XE und XE2.

Du musst also die Delphi-Version beachten, mit der Du FPC vergleichen willst

Bitte zuerst ein solider Referenz

[mse]

Falls da nicht "3 Stück" rauskommt, bleibt's bei 3 verschiedenen Längen

Verstehe ich nicht.

1, 2 und 4 habe ich schon erwäht, weniger als 1 oder mehr als 4 kommt sicher nicht raus, bleibt die "3" als einzige weiter Variante.

Ein "Alt-Ägyptisches Zeichen in UTF-16-Codierung" hat die Länge in glyphs von 1.
Es kann "fully composed" sein, dann hat es die Länge in codepoints von 1.
Es kann aber auch "decomposed" sein, dann hat es eine Länge in codepoints > 1.
Nehmen wir an, ein "fully composed" "Alt-Ägyptisches Zeichen" kann in maximal 3 codepoints in der Form "fully decomposed" zerlegt werden (vielleicht sind es mehr, vielleicht sind es weniger).
Dann ist die Länge in codepoints 1,2 oder 3. Jeder dieser Codepoints wird mit entweder einer oder zwei 16bit "codeunits" codiert. Dann ist die Länge in codeunits:

Code: Alles auswählen

Codepoints Codeunits
1:         1,2 
2:         1+1,1+2,2+2 -> 2,3,4
3:         1+1+1,1+1+2,1+2+2,2+2+2 -> 3,4,5,6

Es gibt also 1,2,3,4,5 oder 6 codeunits welche eine Bytelänge von 2,4,6,8,10 oder 12 haben.
Mögliche Längenzahlen sind also 1,2,3,4,5,6,8,10 oder 12.

Martin

[mschnell]

Igitt !!!

Wenn ich nun in Pascal Schreibe:
if StringA = StringB ....
Möchte ich im allgemeinen nicht die Codierung,sondern die druckbaren Zeichen vergleichen.

Wenn ich Length(StringA) sage, möchte ich im allgemeinen die Anzahl der druckbaren Zeichen wissen (Altägyptisch oder nicht). (Falls der Zeichensatz überhaupt aus einzelnen Zeichen zusammengesetzt ist, ansonsten macht der Ausdruck keinen Sinn).

Wenn ich
StringA[Length(StringA)]
schreibe, möchte ich das letzte Druckbare Zeichen sehen.

Wenn ich die Codierung vergleichen will oder die Anzahl der Codebytes oder Codeworte oder Code-Doubleworte oder die Byte-Länge des Speicherbereichs eines in Worten Codierten Strings wissen will, habe ich nichts dagegen, einen speziellen Funktionsaufruf einzubauen.

Leider funktioniert Delphi aber so nicht. (und FPC auch nicht).

Das kann man keine erklären, der mit Pascal anfangen will....

-Michael

[mse]

Das kann man keine erklären, der mit Pascal anfangen will....

Muss man ja nicht.

Hinweis: dies ist das Forum "Programmierung < Freepascal", darum ist das folgende Wort vielleicht erlaubt. Falls nicht, bitte ich um Vergebung und schonende Mitteilung.

MSEgui z.B. verwendet als string Typen den 16bit UnicodeString in "fully composed" form, daher stimmen für alle lebende westlichen Sprachen die Länge in Glyphs und das Resultat von lenght() überein.

Martin

[mschnell]

Das kann man keine erklären, der mit Pascal anfangen will....

Muss man ja nicht.

Wenn keiner einem Neuling erklärt, wie er mit Pascacl arbeiten soll, stirbt die Rasse der Pascal Programmierer logischerweise nach einer Generation aus.

Wenn das das Ziel der Entwicklung der Compiler ist: OK.

Als String-Codierung UTF-16 zu erzwingen ja wohl ist die Methode, für die sich auch Embarcadero auch entschieden hat. Das löst - solange man "westliche" Sprachen bearbeitet - einige Problem aber nicht alle.

Michael

[mse]

Wenn keiner einem Neuling erklärt, wie er mit Pascacl arbeiten soll, stirbt die Rasse der Pascal Programmierer logischerweise nach einer Generation aus.

Du hast mich falsch verstanden. Ich meine, wenn man zur Speicherung von Unicode Texten den dazu am besten geeigneten string Typen verwendet, gibt es dem Neuling auch nicht viel zu erklären.

[mschnell]

Wenn keiner einem Neuling erklärt, wie er mit Pascacl arbeiten soll, stirbt die Rasse der Pascal Programmierer logischerweise nach einer Generation aus.

Du hast mich falsch verstanden. Ich meine, wenn man zur Speicherung von Unicode Texten den dazu am besten geeigneten string Typen verwendet, gibt es dem Neuling auch nicht viel zu erklären.

Ein Typisches Neuling-Problem, ist es, einen Text Zeichenweise zu analysieren. Jeder Neueinsteiger wird sich in den ersten Wochen eine solche Aufgabe stellen.

Das geht aber mit der von Wirth für die "Lernsprache Pascal" vorgeschlagene intuitive Methode:

for i := 1 to length(s) do
case s of
'a': ....
'ä': ....

mit "Unicde aware" Pascal nicht mehr (außer man lebt im "Westen" und verwendet ein Pascal-System, das für Strings UTF-16 vorschreibt).

-Michael

[mse]

mit "Unicde aware" Pascal nicht mehr (außer man lebt im "Westen" und verwendet ein Pascal-System, das für Strings UTF-16 vorschreibt).

Und was ist da so schlimm daran? Was soll das einen Pascal Einsteiger kümmern, ob die character Speichereinheit 7,8,16,24 oder 32 Bit beträgt, wenn er mit der intuitiven Herangehensweise Erfolg hat?

[theo]

MSEgui z.B. verwendet als string Typen den 16bit UnicodeString in "fully composed" form,

Toll, das ist wie in der Werbung, wo drauf steht: Dieses Bonbon enthält 0% Fett!!!! Das haben Bonbons mehrheitlich nicht, dafür ist Zucker drin.
Das Problem kommt ja am ehesten durch Dateien rein. Normalisiert dein MSEgui denn jeden Text automatisch?

[mse]

MSEgui denn jeden Text automatisch?

Nein, lediglich die Tastatureingaben. Aber wir reden hier von Einsteigerproblemen. Ob die Probleme beim ersten 'ä' oder erst beim Entwickeln komplexer Programme zur Editierung und rendern von Unicode Textdateien auftreten, ist meiner Meinung nach ein Unterschied. Ich werde mich dazu nicht mehr äussern.

Martin

[theo]

Aber wir reden hier von Einsteigerproblemen.

Ich denke das ist eher ein Problem der Veteranen.
Ich verfolge dieses Forum seit langer Zeit, und die Frage, wie man durch Umlaute "cased" taucht von Neulingen doch so gut wie nie auf.

[marcov]

Wenn ich nun in Pascal Schreibe:
if StringA = StringB ....
Möchte ich im allgemeinen nicht die Codierung,sondern die druckbaren Zeichen vergleichen.

Wenn ich Length(StringA) sage, möchte ich im allgemeinen die Anzahl der druckbaren Zeichen wissen (Altägyptisch oder nicht). (Falls der Zeichensatz überhaupt aus einzelnen Zeichen zusammengesetzt ist, ansonsten macht der Ausdruck keinen Sinn).

Wenn ich
StringA[Length(StringA)]
schreibe, möchte ich das letzte Druckbare Zeichen sehen.

Aber über Glyphen das weisst nur das Output System. Zb stelle dich ein System vor, das
1. nur ein A..Z Font geladen hat, und keine umlaute und ringel-s kennt fuer nicht Proportionale Font Ausgaben, aber
2. ein Font mit Deutschen Akzenten für Proportionale Fonts.

Also für das A..Z font konnte es die übliche ae und ss Schreibstil nutzen, und für das "volle" Proportional Font könnte man einfach weg Umlaute und Ringel-S ausgeben

ABER das System kann nicht wissen ob ein String später Proportional oder nicht gedruckt wird. Also deshalb verzichtet Unicode ganz auf "Anzahl Glyphen" als nutzliche Metrik samt wenn es wirklich ausgegeben wird (und der "canvas handle" bekannt ist in Windows Jargon). Die Informationen gibst es einfach nicht.

Leider funktioniert Delphi aber so nicht. (und FPC auch nicht).

Unicode funktioniert nicht so. Der Haupt Grund habe ich oben angegeben . Den Beispiel zeigt auch das UTF16 nicht alles löst. (UTF8 oder UTF16 ist egal im diesen Fall, es geht um die Fonts!!!!)

P.s. nach 3 Jahre auf alles zu reagieren mit encoding oder Unicode darin, sollst du unbedingt einfach weg mal etwas darüber lesen. Zb das Introduktion Hauptstucks der Unicode Standard.