uppercase und lowercase

[mschnell]

Neuste Lazarus-Version auf Windows.
wideuppercase wandelt äöü nicht um, widelowercase wandelt ÄÖÜ nicht um.

Bei Turbo-Delphi klappt das.


Strings scheinen mit der neuen Version nun nicht mehr OS- und locale- spezifisch codiert zu sein, sondern mit utf8. Damit sollte uppercase und lowercase bei strings auch mit äöü bzw ÄÖÜ klappen. Scheint aber nicht zu funktionieren. (Hat das früher geklappt ? In Turbo-Delphi klappt es jedenfalls nicht).

ANSIUpperCase und ANSILowerCase klappen auch nicht. In Turbo-Delphi funktionieren sie.

In Turbo-Delphi gibt es die Funktion utf8UpperCase. Die kennt lazarus nicht. Da sie durch die utf8-Codierung der normalen Strings identisch mit Uppercase ist, wäre sie leicht zu implementieren .

-Michael

[mse]

wideuppercase und widelowercase erwarten widestring parameter und geben widestring zurück. Zur Umwandlung von ansistring widestring wird der widestring manager benützt, welcher die Systemcodierung verwendet. Lazarus benützt utf8 codierte ansistring um Texte zu speichern, so dass diese automatische Umwandlung unter Windows in der Regel schiefläuft.
Alternativen:
Die Lazarus eigenen UTF8* routinen verwenden oder mit MSEide+MSEgui arbeiten, welches durchgängig widestring verwendet, soeben wurde Version 2.0beta1 freigegeben.

Martin

[theo]

In Turbo-Delphi gibt es die Funktion utf8UpperCase. Die kennt lazarus nicht. Da sie durch die utf8-Codierung der normalen Strings identisch mit Uppercase ist, wäre sie leicht zu implementieren .

Gibt's. Das Zeug ist in LCLProc. Diese Funktion benutzt aber intern WideString.

Die ganze Angelegenheit ist schon ziemlich verwirrend im Moment.
@mse: Weisst du eigentlich, was es mit dem FPC unicodestring Branch auf sich hat?
http://svn.freepascal.org/cgi-bin/viewv ... ortby=date" onclick="window.open(this.href);return false;

[theo]

mit MSEide+MSEgui arbeiten, welches durchgängig widestring verwendet

Berücksichtigst du auch die Zeichen über $FFFF (Surrogate) oder nur UCS-2?

[mse]

Urspünglich waren widestring in FPC auf allen Plattformen Referenz-gezählt (hmm, sieht nicht sehr deutsch aus...), dieselbe Implementierung wie in Kylix. Ab 2.0, wenn ich mich recht erinnere, wurden die Windows widestring zu nicht Referenz-gezählten OLE strings umgewandelt um Delphi kompatibel zu werden. Der "neue" unicodestring kehrt nun auf allen Plattformen wieder zum ursprünglichen Referenz-gezählten widestring zurück. Das heisst, eigentlich ändert sich lediglich in Windows etwas, in den anderen Systemen gilt unicodestring=widestring.

[mse]

Berücksichtigst du auch die Zeichen über $FFFF (Surrogate) oder nur UCS-2?

Die edit widgets arbeiten im Moment mit UCS2, es hindert dich nichts daran, in deinem Code "surrogate pair handling" vorzunehmen. Die üblichen Zuweisungs-, Such- und Vergleichsoperationen funktionieren sowohl mit utf-16 als auch mit UCS2. Es gilt die gleiche Entsprechung wie zwischen ansistring und UTF8String.
Übrigens scheint sogar unser aktiver chinesischer Anwender liuzg keine Probleme mit der UCS2 Einschränkung zu haben, BIDI wäre vermutlich wichtiger.

[mschnell]

wideuppercase und widelowercase erwarten widestring parameter und geben widestring zurück.

Na klar. ich habe in meinem Text-Code "wideuppercase" auch nur mit variablen des Type widestring verwendet, "uppercase" nur mit variablen vom Typ String und "ansiuppercase" nur mit variablen vom Typ AnsiString. Trotzdem das beschriebene Fehlverhalten.

Die Zuordnung einer Konstante (z.B. "s := "abcdefgäöü") scheint bei allen Typen korrekt zu klappen: Es scheint die jeweils richtige Kodierung erzeugt zu werden.

-Michael

[mschnell]

Urspünglich waren widestring in FPC auf allen Plattformen Referenz-gezählt (hmm, sieht nicht sehr deutsch aus...), dieselbe Implementierung wie in Kylix. Ab 2.0, wenn ich mich recht erinnere, wurden die Windows widestring zu nicht Referenz-gezählten OLE strings umgewandelt um Delphi kompatibel zu werden.

Wie kann man denn ohne reference-counting anständig mit Strings umgehen ?

Im Vergleich dazu sind dynamische Arrays ja nicht reference-counting. Wenn man eines nicht mehr benutzt, muss man den speicher explizit mit setlength(x,0) (als Komfort-Funktion geht auch x:=NIL) freigeben, sonst wird der Speicher nie wieder freigegeben.

-Michael

[mse]

Wie kann man denn ohne reference-counting anständig mit Strings umgehen ?

Da müsste man Microsoft fragen.

Im Vergleich dazu sind dynamische Arrays ja nicht reference-counting. Wenn man eines nicht mehr benutzt, muss man den speicher explizit mit setlength(x,0) (als Komfort-Funktion geht auch x:=NIL) freigeben, sonst wird der Speicher nie wieder freigegeben.
l

Dies ist nicht richtig. Dynamische Arrays verhalten sich wie dynamische Strings mit zwei Ausnahmen:
- der Speicherbereich wird bei setlength() mit Nullen initialisiert.
- Der Schreibzugriff mittels index (arrayxy[index]:= value) löst keinen impliziten Kopiervorgang aus falls der Referenzzählerstand > 1 ist.

Martin

[mschnell]

Du meinst also:
- dynamische Arrays machen Reference-counting (wie Strings)
- dynamische Arryas machen keine "lazy copy" (anders als Strings, sondern verhalten sich bei Zuweisungen also wie Objekte und nicht wie "Zahlen" (und string) )

Da lasse ich mich gerne überzeugen.

Dann nimm nehmen wir Beispiel für nicht reference-counting Dinge also (von TObject abgeleitete) Objekte.

Wie soll der Compiler denn wissen, dass er einen Widestring freigeben darf wenn er die Referenzen nicht zählt ?

-Michael

[mse]

Wie soll der Compiler denn wissen, dass er einen Widestring freigeben darf wenn er die Referenzen nicht zählt ?

Der reference count ist bei OLE strings (Windows widestring) immer 1. Wenn ein OLE string kopiert wird, wird nicht der Referenzähler incrementiert, sondern eine Kopie des string mit reference count 1 erzeugt. Beim Verlassen des scope wird decrementiert, reference count erreicht 0 -> der string wird freigegeben.

[mschnell]

D.h.: Kein lazy copy bei Widestrings ?!?!?!?!
A:= B bewirkt also ein ein Kopieren des kompletten String-Inhats (als u.U. viele Megyabyte).
Das ist aber ein Rückschritt !

-Michael

[mschnell]

Die Frage, warum wideuppercase bei Widestrings und AnsiUppercase bei Ansistrins nicht mit Umlauten funktioniert, steht immer noch im Raum.

Mache ich was falsch oder ist das ein Bug ? (wie gesagt: bei Turbo-Delphi macht derselbe code das, was ich erwarte).

-Michael

[Christian]

Ich komm nicht wirklich mit, a := b sollte doch immer den gesamten string kopieren oder ? Und wann verarbeitet man megabyteweise Daten in strings ?

[mse]

D.h.: Kein lazy copy bei Widestrings ?!?!?!?!
A:= B bewirkt also ein ein Kopieren des kompletten String-Inhats (als u.U. viele Megyabyte).
Das ist aber ein Rückschritt !

Unter Windows ist dies leider eine Tatsache, vielleicht kannst du dich noch an mein Gezeter auf fpc-devel erinnern.

Die Frage, warum wideuppercase bei Widestrings und AnsiUppercase bei Ansistrins nicht mit Umlauten funktioniert, steht immer noch im Raum.

Ich nehme an, dass Du unter Windows mit utf-8 codierter Pascal Datei arbeitest. Für AnsiUpper/Lowercase ist es klar, die strings werden an das Betriebssystem weitergeleitet welches die Systemcodierung erwartet, dies ist unter Windows höchstwahrscheinlich nicht utf-8.
Mit widestrings sollte es funktionieren, hast du -Fcutf8 als Compilerparameter angegeben?