FPC Unicode support

[theo]

Nachdem ich nun FPC 2.7.1 am laufen habe, wollte ich mal nachfragen, ob jemand noch den Durchblick bzgl. dem Stand der Dinge bei Freepascal-Unicode hat.
Dieses Dok. kenne ich http://wiki.freepascal.org/FPC_Unicode_support" onclick="window.open(this.href);return false; scheint mir aber weder besonders aktuell noch besonders aufschlussreich.

Was mir aufgefallen ist: UTF8String ist nun nicht mehr gleich String.

Es gibt jetzt auch Zeug wie:

Code: Alles auswählen

type
CyrillicString = type Ansistring(1251);
var cs:CyrillicString; 
Caption:=IntToStr(StringCodePage(Cs));

Und die TCharacter Klasse in der RTL.

Ist da jemand auf der Höhe, was nun geht und was nicht?
mse vielleicht?
Was ich lese, auch auf der Mailing-List, verwirrt mehr, als dass es klärt.

[mse]

Was ich lese, auch auf der Mailing-List, verwirrt mehr, als dass es klärt.

Vom FPC core Team will sich seit Monaten niemand festlegen. Die meistgelesen Antwort ist "not yet decided". Ich vermute, schlussendlich wird es wie immer genau gleich wie in Delphi gemacht werden.
Dumm ist nur, dass Delphi möglicherweise das Stringkonzept wieder ändert bevor codepage aware FPC-strings rund laufen.
https://forums.codegear.com/thread.jspa ... t=0#399861

z.B Allen Bauer:

Code: Alles auswählen

We have way, way too many different string types. It's confusing. For
 instance, C# & Java each have exactly one string type.

Martin

[mschnell]

Die meistgelesen Antwort ist "not yet decided".

Und eine Diskussion darüber, wie es am besten zu machen sei, ist nicht erwünscht.

Ich vermute, schlussendlich wird es wie immer genau gleich wie in Delphi gemacht werden..

Also leider Vermutlich nicht wirklich gut

Dumm ist nur, dass Delphi möglicherweise das Stringkonzept wieder ändert bevor codepage aware FPC-strings rund laufen.

Ist ja auch wirklich nicht zufriedenstellend. Weder wirklich kompatibel zu vor-Unicode Sourcen, noch ist die Funktionalität und System-API-Unabhängigkeit so, wie man es gerne hätte. (Begründung: wäre sonst zu langsam.) Ist das heute noch wirklich so ?
Kannst Du zusammenfassen was die (möglicherweise) vor haben, und was Du davon hältst ?
-Michael

[theo]

Danke Martin, so hatte ich das auch vermutet.
Dennoch ist zumindest ein Teil der Unicode-Implementation in Trunk gelandet.
Kann man den irgendwo nachlesen, was das nun kann, oder ist das komplette Baustelle?

[mse]

Kannst Du zusammenfassen was die (möglicherweise) vor haben, und was Du davon hältst ?

Ich kenne nur den zitierten thread im Embarcadero Forum, ob und was daraus entstehen wird weiss ich nicht. Klar ist lediglich, dass der Embarcadero Chefentwickler Allen Bauer mit der bestehenden Delphi Lösung nicht glücklich ist.
Für mich ist die bestehende Lösung in FPC 2.6.0 ideal.
Für 8-Bit Speicherung von Zeichenketten und kombinierte Zeichen und binären Daten wird "AnsiString" verwendet.
Für alle reinen Zeichenketten für GUI-Zwecke wird 16bit-UnicodeString verwendet, die Codierung ist utf-16.
Die Konversion AnsiString <-> UnicodeString wird auf Basis der 8bit-Systemcodierung von Compiler und RTL automatisch durchgeführt, alle weiteren Code-Wandlungen müssen vom Programm explizit vorgenommen werden.
Was fehlt sind lediglich Unicode ResourceStrings, deren Implementierung ich vom FPC Team seit Jahren erfolglos erbettle.
Ehm, nein ich kann das nicht selbst erledigen, da dazu intime Kenntnisse der FPC Interna und uferlose Diskussionen notwendig sind.

Martin

Edit:
Was ich mir auch noch wünschen würde wäre Null-basierte Zeichen-Indizierung. Ein sehr unrealistischer Wunsch...

[mse]

Kann man den irgendwo nachlesen, was das nun kann, oder ist das komplette Baustelle?

Ich würde die Delphi Dokumentation verwenden. Wenn irgend etwas nicht so funktioniert wie dort beschrieben, ist ein bugreport fällig.

[theo]

und uferlose Diskussionen notwendig sind.

Das scheint mir ein gemeinsames Merkmal zw. FPC und Embarcadero bezüglich Unicode zu sein.
Uferlose Diskussionen.
Verwirrend, entmutigend, zum sich-ausklinken.

[mschnell]

Was fehlt sind lediglich Unicode ResourceStrings, deren Implementierung ich vom FPC Team seit Jahren erfolglos erbettle.

Was für mich fehlt, ist eine genaue Definition der nicht-expliziten Codierungen (Code-Kennung 0 <Momentan = Default> und $FFFF < = keine Kodierung>), wenn diese zur Definition eines Types (z.B. "RawByteString" = $FFFF) oder einer Variable verwendet werden.

Aus Geschwindigkeitsgründen ist es (anscheinend) sinnvoll, nicht permanent mit dynamisch codierten Typen zu arbeiten, sondern, wenn immer möglich, dem Compiler die Möglichkeit zu geben, schon beim Übersetzen festzulegen, ob und welche Umcodierung benötigt wird. Dafür gibt es die Typen mit festen Codierungen.

Meiner Ansicht nach sollte es aber möglich sein, Unterprogramme zu schreiben, die Strings z.B. "Durchreichen" können, ohne sie umzucodieren. Dazu ist der Formal-Parameter mit $FFFF (RawByteString) angegeben.

Die als "RawByteString" definierte Variable enthält dann dynamisch eine explizit angegebene Codierung. Besser wäre ein Type "VarCodeString", während drei verschiedene "RAW" Typen existieren sollten, für die explizit keine Codierung in sichtbare Zeichen angegeben wird aber die Größer der Elemente festliegt. Die Größe der Elemente (8, 16 oder 32 Bit) ist bei "VarCode" natürlich auch dynamisch.

Eigentlich sollte Copy etc- (zumindest scheinbar aus Programmierer-Sicht) solche "dynamischen" Parameter haben, durch Compiler Magic kann ja eine passende Variante verwendet werden, wenn der Type der Aktual-Parameter fest codiert ist. "Pos", "Copy" etc. sollten natürlich in Varianten verfügbar sein die in Codes oder in Zeichen arbeiten. Für einfache Portierung sollte es möglich sein festzulegen, dass diese Keywords in sichtbaren Zeichen arbeiten, für performance-optimierte Portierung vielleicht auch das Gegenteil.

Dabei sind aber diverse weitere Punkte unklar.
- Behandlung der Elementgröße
- Was ist mit der Rückgabe als Result oder als Var- oder Out-Parameter ?
- Was passiert, wenn ein RawByteString mit einem explizt codierten Type zusammentrifft (Zuordnung, "+", Vergleich, ...). (Automatische Umcodierung falls möglich) ?
- Wie geht man mit Strings um, die tatsächlich als uncodierte Bytes, Worte oder Doppelworte (also wirklich "RAW") behandelt werden sollen ? (Fehlermeldung, wenn sie mit codierten Strings zusammentreffen.)
- ...


-Michael

[mschnell]

Ich würde die Delphi Dokumentation verwenden. Wenn irgend etwas nicht so funktioniert wie dort beschrieben, ist ein bugreport fällig.

Darf FPC wirklich nicht besser als Delphi sein ?

-Michael

[mschnell]

Das scheint mir ein gemeinsames Merkmal zw. FPC und Embarcadero bezüglich Unicode zu sein.
Uferlose Diskussionen.
Verwirrend, entmutigend, zum sich-ausklinken.

Das ist zwar faktisch richtig, sehe ich aber nicht als Kritik-Punkt.

Das Thema "Umstellung "8-Bit-ANSI nach Unicode" ist tatsächlich äußerst anspruchsvoll und ohne diverse "Fingerübungen" kaum sinnvoll lösbar. Meiner Ansicht nach wurde bei beiden Organisationen nicht zu viel, sondern zu wenig diskutiert, bevor eine Unicode-Version veröffentlicht wurde. Dabei hat sich Embarcadero zu sehr an Windows und FPC zu sehr an Linux orientiert, anstatt zunächst festzulegen, was für den Usercode-Programmier (inklusive blutigen Anfängern und Erzgeugern von Hochleistungs-Code) wirklich sinnvoll und für möglichst alle Anwendungen, neue und Portierungen, möglichst gut brauchbar ist.

-Michael

[mse]

Was fehlt sind lediglich Unicode ResourceStrings, deren Implementierung ich vom FPC Team seit Jahren erfolglos erbettle.

Was für mich fehlt, ist eine genaue Definition der nicht-expliziten Codierungen (Code-Kennung 0 <Momentan = Default> und $FFFF < = keine Kodierung>), wenn diese zur Definition eines Types (z.B. "RawByteString" = §FFFF) oder einer Variable verwendet werden.

Das fehlt für mich nicht, da es das in der Lösung nach FPC 2.6.0 gar nicht braucht. Unicode ResourceStrings sind jedoch notwendig.

[mse]

Das Thema "Umstellung "8-Bit-ANSI nach Unicode" ist tatsächlich äußerst anspruchsvoll und ohne diverse "Fingerübungen" kaum sinnvoll lösbar.

Warum? Solange nicht versucht wird "encoding aware 8-bit strings" zu erfinden und erst noch damit zu arbeiten ist der Schritt einfach.

[theo]

Also ich stelle mich jetzt mal doof an, und teste ein bisschen intuitiv rum:

Code: Alles auswählen

UTF16String  = type AnsiString(CP_UTF16);    
 
procedure TForm1.Button1Click(Sender: TObject);
var u8: UTF8String;
  u16:UTF16String;
  ucs:UnicodeString;
begin
   u8:='öäü';
   ucs:=u8;
   Caption:=IntToStr(Length(ucs));  //ist 6, also nicht nach UTF16 gewandelt!
   u16:=u8; 
   Caption:=IntToStr(Length(u16));  //ist 12
end;

Das tut alles nicht was ich erwarten würde. Habe ich einen Schalter verpasst?

[mse]

Habe ich einen Schalter verpasst?

Vermutlich ${codepage utf8} oder -Fcutf8.

[mschnell]

Warum? Solange nicht versucht wird "encoding aware 8-bit strings" zu erfinden und erst noch damit zu arbeiten ist der Schritt einfach.

Es gibt mehrere Grundsatzentscheidungen zu treffen:
- Soll alles Unicode sein oder sollen auch andere Codierungen für sichtbare Zeichen bei normalen String-Operationen zulässig sein ?
- Wenn Unicode: welche Darstellung (UTF-8, UTF-16, UTF-32) (Von den sichtbaren Zeichen, die in Unicode perverser weise nicht nur als ein Unicode-Zeichen sondern zusätzlich noch als Kombination von mehreren vollständigen Unicode-Zeichen darstellbar sind <Sxcheint bei Appel sehr beliebt zu sein> schweigen wir lieber völlig...)
- Wenn auch andere (Codierungen (ANSI) wann wird automatisch umcodiert ?
- Wenn mehrere Codierungen: Statisch (je ein Typ für eine Kodierung) oder dynamisch (die Variable enthält eine Kennung für den Typ)
- Wenn dynamisch: Wie macht man Codierungs-Unabhängige Code-Sequenzen, (nicht umcodieren, wenn nicht nötig)
- Wenn UTF-8 (oder UTF16): soll Length, Copy, Pos etc in sichtbaren Zeichen oder in Code-Elementen arbeiten ?
- Wie macht man "RAW" Strings, die explizit nie umkodiert werden sollen ? (zur praktischen Arbeit mit Byte-, Wort- oder DWort- Ansammlungen)
- Wie werden Konstanten codiert, wenn der User keinen explizit codierten Type dafür angibt. (MyString := "äöü");
- ...

Vieles hat Vor- und Nachteile

Und dann kommt noch das Problem dazu: in welcher Codierung ist eigentlich die Quell-Datei ? Müssen Variablen-Namen pures ASCII sein ? ....

Ich finde das gar nicht trivial !

-Michael