CreateDirUTF8 funktioniert nicht mit "ä"...[gelöst]

[corpsman]

Beide Variablen sind als String deklariert mit dem switch

Code: Alles auswählen

{$mode objfpc}{$H+} 

Warum es mit dem Code geht ist mir auch schleierhaft. Der Code wird nach

Code: Alles auswählen

Application.initialize

und vor dem ersten

Code: Alles auswählen

Application.CreateForm(TForm1, Form1);

aufgrerufen.

Was dasUTF16 Zeug angeht, fragte ich ja weil ich auch was das soll, gerade weil ich keinen direkten Vorteil erkennen kann. Ich weis auch nicht wie das Thema überhaupt hoch kam, aber zumindest in der Mailingliste ging das auch mal ne ganze weile rum. Mir reicht es vollkommen aus, wenn ich lese, dass der Auffwand "Doppelt" wäre, was sich für mich liest, als bleibt vorerst alles beim alten *g*.

[mschnell]

Mir reicht es vollkommen aus, wenn ich lese, dass der Auffwand "Doppelt" wäre, was sich für mich liest, als bleibt vorerst alles beim alten *g*.

Meine Kollegen wollen auf die Dauer ihre Delphi - Programme für Linux bereitstellen.

Der Aufwand wäre doppelt, wenn man ein aktuelles Delphi-Programm, um es auf Linux lauffähig zu machen, nach Lazarus portiert (also von 16-Bit-Strings auf UTF-8 Strings) und FPC (und damit auch Lazarus) später auf (dynamisch codierte oder) 16-Bit Strings umschwenkt, so dass alles wieder zurückportiert werden müsste, was eigentlich hätte bleiben können wie es war.

Deshalb rate ich ihnen von der momentanen Lazarus-Version ab.

Wenns zu lange dauert, nehmen sie vermutlich Java (nicht meine Idee...)

-Michael

[mschnell]

. Das Problem liegt erstmal in der Unicode-untauglichen RTL, nicht in der LCL.

Das ist natürlich war, Für den User aber Wurscht.

-Michael

[corpsman]

Verstehe ich das Richtig, alle Welt nutzt Utf8, nur mal wieder die Redmonder nicht und deswegen sollen die anderen nun auf 16 -Bit Strings wechseln ?

[mse]

Verstehe ich das Richtig, alle Welt nutzt Utf8, nur mal wieder die Redmonder nicht und deswegen sollen die anderen nun auf 16 -Bit Strings wechseln ?

Das verstehst du falsch.

Martin

[mse]

Wenns zu lange dauert, nehmen sie vermutlich Java (nicht meine Idee...)

Da gäbe es ja auch noch andere Alternativen.

[Socke]

Verstehe ich das Richtig, alle Welt nutzt Utf8, nur mal wieder die Redmonder nicht und deswegen sollen die anderen nun auf 16 -Bit Strings wechseln ?

Ob man jetzt UTF-16 oder UTF-8 verwendet ist doch Banane Es sind zwei verschiedene Zeichenkodierungen (engl. character encoding) für den selben Zeichensatz (engl. charset). Daher kann man verlustfrei zwischen beiden Formaten hin und her konvertieren.

Allenfalls kann man die Anzahl der Programmbenutzungen auf UTF-8 Betriebssystemen mit der Anzahl der Programmbenutzungen auf UTF-16 Betriebssystemen vergleichen und danach entscheiden, welche Kodierung im Allgemeinen (auf allen Betriebssystemen zusammen) zu weniger Umkodierungsaufwand führt.

[Patito]

Der Aufwand wäre doppelt, wenn man ein aktuelles Delphi-Programm, um es auf Linux lauffähig zu machen, nach Lazarus portiert (also von 16-Bit-Strings auf UTF-8 Strings) und FPC (und damit auch Lazarus) später auf (dynamisch codierte oder) 16-Bit Strings umschwenkt, so dass alles wieder zurückportiert werden müsste, was eigentlich hätte bleiben können wie es war.

Deshalb rate ich ihnen von der momentanen Lazarus-Version ab.
-Michael

Hm. Mal angenommen FPC schwenkt auf 16-Bit Strings um. Spätestens wenn der Compiler dann intern für alles doppelt soviel Speicher und doppelt soviel Zeit braucht gibt es dann hoffentlich bald jemanden, der das forkt und wieder auf 8-Bit gerade biegt.

Also ich halte mich da auch erst mal zurück, aber den eigenen Code auf UTF-8 aufzubauen halte ich prinzipiell für eine gute technische Lösung.

Der Drang FPC auf 16-Bit umzustellen kommt doch wohl politisch aus der Ecke, dass Leute ihren Delphi-Code von den "instabilen" Delphi-Versionen jetzt mit FPC compilieren wollen. Wobei ich Leuten, die auf instabile Pferde setzen, nicht sonderlich viel Einfluss in die FPC-Entwicklung wünsche...

Dass man in der RTL teilweise zweigleisig fahren sollte halte ich für sinnvoll. (Typ UTF-8 und Typ UTF-16. Methoden overloads, bzw. doppelter Methodensatz, ....)
Komplett vom einen auf das andere umzuschwenken halte ich für problematisch. Soll doch jeder Komponentenentwickler selber entscheiden was er braucht.
Alles mit einem Standard-Typ auf Low-Level Compiler-Ebene erledigen zu wollen kommt mir so vor wie wenn man Integer und Double in einen einzigen Typ vereinheitlichen wollte.

[theo]

Warum es mit dem Code geht ist mir auch schleierhaft.

Ist dir das nicht unheimlich?

[Socke]

Hm. Mal angenommen FPC schwenkt auf 16-Bit Strings um. Spätestens wenn der Compiler dann intern für alles doppelt soviel Speicher und doppelt soviel Zeit braucht gibt es dann hoffentlich bald jemanden, der das forkt und wieder auf 8-Bit gerade biegt.

Wenn der Compiler jetzt plötzlich doppelt so viel Speicher benötigt wäre mir das egal Selbst wenn nur der Compiler intern UTF-16 verwenden sollte, wäre das toll. Problematisch könnte es werden, wenn die RTL komplett auf UTF-16 umgestellt wird. Die Annahme, dass dadurch "doppelt soviel Speicher und doppelt soviel Zeit braucht", ist schlichtweg ungenau.

Ein Text benötigt nur dann doppelt so viel Speicher in UTF-16 als in UTF-8, wenn sämtliche Zeichen einen Codepoint unter 127 haben. Werden sämtliche Zeichen in UTF-8 mit zwei Byte kodiert, ist der Speicherverbrauch in UTF-16 gleichwertig. Lediglich benötigt UTF-16 zwei terminierende Null-Bytes (und damit per Definition mehr Speicher als UTF-8). Bei Zeichen, die in UTF-8 mit mehr als zwei Byte abgebildet werden, wage ich keine Prognose. Hier ist der Speicherverbrauch in UTF-16 davon abhängig, ob das Zeichen in der Basic Multilingual Plane (BMP) liegt (2 Byte) oder nicht (4 Byte).

Wenn wir von Zeit sprechen, sollten wir auch über die Worte Register und Speicher reden sowie deren Anbindung im Prozessor. Geht man davon aus, dass der gesamte Computer ein Byte nach dem anderen Verarbeitet, benötigt UTF-16 doppelt so viel Zeit wie ein ASCII Text (im Vergleich mit UTF-8 ist das wie üblich von der Zeichenverteilung abhängig). Dies ist mittlerweile nur noch bei einigen Microcontroller-Familen der Fall. Hier ist die Frage UTF-8 oder UTF-16 in der Regel durch den verfügbaren Speicher und die primäre Anwendungssprache von vornherein beantwortet.

[mschnell]

Hm. Mal angenommen FPC schwenkt auf 16-Bit Strings um. Spätestens wenn der Compiler dann intern für alles doppelt soviel Speicher und doppelt soviel Zeit braucht gibt es dann hoffentlich bald jemanden, der das forkt und wieder auf 8-Bit gerade biegt.

Das Argument in der fpc Devel Mailing Liste war hauptsächlich Delphi-Kompatibilität, nicht bessere oder schlechtere Brauchbarkeit (die meiner Ansicht nach mit 16 Bit Strings besser ist, da gibt es aber hier auch andere Meinungen). Das Speicher-Argument wurde nicht angeführt. Speicher ist heute auch eigentlich kein Thema mehr.

, dass Leute ihren Delphi-Code von den "instabilen" Delphi-Versionen jetzt mit FPC compilieren wollen.

Wieso meinst Du, Delphi XE2 sei instabil ? Meine Kollegen haben damit ein riesenhaftes System (schätzungsweise 20 Mannjahre) am laufen das bei hunderten Kunden im Einsatz ist. Einziges Problem: Es benötigt Windows.

Dass man in der RTL teilweise zweigleisig fahren sollte halte ich für sinnvoll.

Ich kann mich nicht erinnern, ob das diskutiert wurde. Das wäre sicher möglich, aber eine völlig neue Funktionalität. Der Comiler kennt ja die diversen Kompatibilitäts-"Modi" ( {$mode ... ) (z.B. "Delphi"). Ich wüsste nicht, wie man eine unterschiedliche RTL-API auswählen könnte. Die LCL dagegen hat bereits IDE Macros, die man für diesen Zweck verwenden könnte (sollte wohl besser LCL Macros heißen, weil die Werte beim Bauen der LCL für das Projekt verwendet werden.)

(Typ UTF-8 und Typ UTF-16. Methoden overloads, bzw. doppelter Methodensatz, ....)

Ich glaube nicht, dass das so möglich/sinnvoll ist. Der Default-String Typ soll laut Mailing-Liste nach Delphi-Art zu dynamisch kodierten Strings migriert werden.

-Michael

[mschnell]

Verstehe ich das Richtig, alle Welt nutzt Utf8, nur mal wieder die Redmonder nicht und deswegen sollen die anderen nun auf 16 -Bit Strings wechseln ?

Wer sagt denn dass das eine schlechte Entscheidung war, nur weil es aus Redmond kommt ?????

16 Bit Strings erleichtern das Arbeiten nur, wenn man von vorne herein weiß, dass alles was man im Programm verarbeitet BMP ist. Ansonsten hilft es natürlich überhaupt nicht.

Software die nur "im Westen" laufen soll, ist aber zu 99% BMP-only.

-Michael

[Socke]

16 Bit Strings erleichtern das Arbeiten nur, wenn man von vorne herein weiß, dass alles was man im Programm verarbeitet BMP ist. Ansonsten hilft es natürlich überhaupt nicht.

Microsoft hat in Windows NT von Anfang an mit UCS-2 gearbeitet. Das ist UTF-16 ohne die Unterstützung für Surrogate Pairs und kann daher nur die BMP darstellen. Seit Windows 2000 wurde dann die UTF-16 Unterstützung ausgebaut. Seit Windows XP ist das dann auch kein Thema mehr, Windows auf Chinesisch zu lokalisieren.

[Patito]

Das Argument in der fpc Devel Mailing Liste war hauptsächlich Delphi-Kompatibilität, nicht bessere oder schlechtere Brauchbarkeit (die meiner Ansicht nach mit 16 Bit Strings besser ist, da gibt es aber hier auch andere Meinungen). Das Speicher-Argument wurde nicht angeführt. Speicher ist heute auch eigentlich kein Thema mehr.

Err... doppelt soviel Speicher -> doppelte Rechenzeit bei der Datenverarbeitung (z.B. beim hashen).
Sowas ist heutzutage ein Thema, und so etwas wird auch immer ein Thema bleiben (solange es gesunden Menschenverstand gibt und man EDV betreiben will).
Wenn man z.B. ein File parst, das zu 100% aus ASCII besteht, wäre es extrem doof die Sachen intern in UTF-16 zu verwalten.

Wieso meinst Du, Delphi XE2 sei instabil ? Meine Kollegen haben damit ein riesenhaftes System (schätzungsweise 20 Mannjahre) am laufen das bei hunderten Kunden im Einsatz ist. Einziges Problem: Es benötigt Windows.

Nun gut. Ich denke nicht dass XE2 im Reich der etablierten Entwicklungsumgebungen angekommen ist. Es fehlt einfach die Masse (die frühere Delphi-Versionen hatten). Und die Zukunftsaussichten sind auch nicht gerade toll (keine Bugfixes - bei den nächsten Versionen ist vielleicht die VCL schon komplett deprecated und es gibt nur noch Firemonkey). Projekte kann man damit sicher machen, für die beste Idee halte ich es aber nicht.

Dass man in der RTL teilweise zweigleisig fahren sollte halte ich für sinnvoll.

Ich glaube nicht, dass das so möglich/sinnvoll ist. Der Default-String Typ soll laut Mailing-Liste nach Delphi-Art zu dynamisch kodierten Strings migriert werden.

Nunja. Vielleicht kommt ja was gutes dabei raus. Nur UTF-16 als Standard wäre eben sehr unglücklich.

Bei Integer und Double hat man die Situation ja auch irgendwie gemeistert und ein IntToStr() und ein FloatToStr() hinbekommen ... wieso die Leute immer gleich mit Makros und Compiler-Switches kommen und ans dynamisch kodieren denken ist mir aber immer noch nicht ganz klar.

[Socke]

Das Argument in der fpc Devel Mailing Liste war hauptsächlich Delphi-Kompatibilität, nicht bessere oder schlechtere Brauchbarkeit (die meiner Ansicht nach mit 16 Bit Strings besser ist, da gibt es aber hier auch andere Meinungen). Das Speicher-Argument wurde nicht angeführt. Speicher ist heute auch eigentlich kein Thema mehr.

Err... doppelt soviel Speicher -> doppelte Rechenzeit bei der Datenverarbeitung (z.B. beim hashen).
Sowas ist heutzutage ein Thema, und so etwas wird auch immer ein Thema bleiben (solange es gesunden Menschenverstand gibt und man EDV betreiben will).
Wenn man z.B. ein File parst, das zu 100% aus ASCII besteht, wäre es extrem doof die Sachen intern in UTF-16 zu verwalten.

Speicher ist ein Thema -- das stimmt. Die Frage ist nur, welche Priorität es erhält.

Dann noch mal zum Speicher: Ein UTF-16 String benötigt nur dann doppelt so viel Speicher, wie ein UTF-8 String, wenn er nur ASCII Zeichen (das heißt, Zeichen mit einem Codepoint kleiner gleich 127) enthält. Das kommt allenfalls in englischsprachigen Dateien vor. Englisch wird zwar häufig verwendet, ist aber (wie keine Sprache) der Weisheit letzter Schluss.

Dann noch mal zur Verarbeitung: Wenn du einen Hash-Algorithmus verwendest, der Byte-Weise arbeitet, benötigt dieser doppelt so viel Zeit, wenn doppelt so viel Speicher (siehe oben) gehasht werden soll. Dies ist jedoch ein spezieller Anwendungsfall. Es spricht nichts dagegen, verschiedene Texte unterschiedlich zu behandeln. Wenn eine Anwendung in verschiedene Sprachregionen eingesetzt werden soll, könnte sie sich je nach Region für einen anderen Hash-Algorithmus entscheiden.
Ob du nun 1 Byte oder 4 Byte in ein Prozessorregister lädst ist bei einer Speicheranbindung von 4 Byte Breite egal. Beide Operationen benötigen gleich viel Zeit.