Von wegen UTF-8 ist die Quelle allen Übels...

[theo]

...eine Quelle von Unicode Problemen sind automatische Umwandlungen (Sage ich übrigens schon seit längerem).

Im Embarcadero Forum aufgeschnappt:

We now have the Alice-in-Wonderland situations where...

"#128 <> chr (128)" but "ord (#128) = ord (chr (128))"
and
"#128 = #20AC" but "ord (#128) <> ord (#20AC)"

@mschnell, mse: Hier ist von Delphi die Rede, nicht von UTF-8 Lazarus!!

[Patito]

Genau. Einer der Vorteile von Pascal war immer, dass es nicht so viele unsichere automatische Umwandlungen gab wie in C.
Aber heutzutage muss ja alles "einfach" sein. Und ein Labyrinth sieht eben viel einfacher aus wenn man die Mauern unsichtbar macht...

[DiBo33]

Die Problematik ist eher, dass sich bisher nur die wenigsten Entwickler Gedanken um irgendwelchen Charsets/Kodierungen gemacht haben (ehrlich gesagt mich damals eingeschlossen).

Nun, nach und nach kommt halt alles zum Vorschein.

[theo]

Die Problematik ist eher, dass sich bisher nur die wenigsten Entwickler Gedanken um irgendwelchen Charsets/Kodierungen gemacht haben (ehrlich gesagt mich damals eingeschlossen).
Nun, nach und nach kommt halt alles zum Vorschein.

@Patito:
@DiBo33: Das stimmt sicher, aber wenn man's dann mal weitgehend verstanden hat, treten einen eigentlich nur noch die Automatismen in den Hintern.
Wenn so etwas "true" wird:
#128 = #20AC
dann ist doch was faul im Staate Dänemark.

Von mir aus kann man dieses automatische "Glump" streichen.
Ich habe auch nie wirklich nachvollziehen könne warum
WideString:=AnsiString und AnsiString:=WideString
überhaupt erlaubt wurde. Weder die Elementgrösse noch die Kodierung ist gleich.
Ich finde das un-pascalisch.

Wenn das wirklich erlaubt sein soll, warum geht dann nicht auch gleich:
integer:=float; //bissel truncen oder rounden. Am besten Betriebssystemabhängig
integer:=true; //-1 oder vllt. 1 auf Windows?
string:=integer; //auto inttostr: das wäre wenigstens eindeutig.
etc.

[mse]

Von mir aus kann man dieses automatische "Glump" streichen.
Ich habe auch nie wirklich nachvollziehen könne warum
WideString:=AnsiString und AnsiString:=WideString
überhaupt erlaubt wurde. Weder die Elementgrösse noch die Kodierung ist gleich.
Ich finde das un-pascalisch.

Das ist das Microsoft Prinzip: Konstruiere alles so, dass es den Erstkäufern und Anfängern am meisten Spass macht. Und da alle gerne sehr reich werden möchten, wird dieses Prinzip immer mehr angewendet...

[theo]

Das ist das Microsoft Prinzip: Konstruiere alles so, dass es den Erstkäufern am meisten Spass macht. Und da alle gerne sehr reich werden möchten, wird dieses Prinzip immer mehr angewendet...

Dem ist (leider) nichts hinzuzufügen.

[mschnell]

@mschnell, mse: Hier ist von Delphi die Rede, nicht von UTF-8 Lazarus!!

Habe ich je gesagt, dass die "Probleme" mit dem aktuellen Delphi gelöst sind ? Bestimmt nicht, Ich habe nämlich gar kein aktuelles Delphi, sondern nur das kostenlose, nicht-Unicode Turbo-Delphi.

Also: so nicht gut und so auch nicht gut.

Die Details schaue ich mir später an.

-Michael

[theo]

http://docwiki.embarcadero.com/RADStudi ... e_(Delphi)
Da kann man mal sehen, welche Blüten die von einigen hier geforderte "no-brainer" implementierung von Unicode treibt.

Oder wie im Embarcadero Forum gesagt wird:

marc hoffman wrote:
Ugh.

Seconded

I can see any source code using that having to be heavily commented
///// DANGER DO NOT REMOVE LEADING ZEROS - BIZARRE COMPILER SYNTAX AHEAD /////////

Da kommt dem Niklaus Wirth im Pflegeheim die Grütze hoch.

Bin dafür, dass im mode objfpc der ganze automatische Kram deaktiviert und die Zuweisung von AnsiString<>WideString verboten wird.
Haltet die Sprache sauber!
Wer ist noch dafür?

[mschnell]

die Zuweisung von AnsiString<>WideString verboten wird.

Soweit ich weiß war
var R:real; i: Integer;
begin
r := i;
nie verboten.
i:=r;
gibt aber ein Fehlermeldung

Das ist doch ein ähnlicher Fall. aber was folgern wir daraus ?

Und wie macht man dann eine Widestring-Konstante ?

MyWideString := 'abcäöü' sollte doch wohl etwas sinnvolles machen ?!?!? Der Compiler müsste also automatisch auf der rechten Seite den richtigen Konstantentyp erzeugen (ganz bestimmt unabhängig von der Codierung der Source-Datei).

-Michael

-Michael

[theo]

Und wie macht man dann eine Widestring-Konstante ?
MyWideString := 'abcäöü' sollte doch wohl etwas sinnvolles machen

Ich wüsste nicht wozu die unter Lazarus gut sein sollten.

[mschnell]

Ich wüsste nicht wozu die unter Lazarus gut sein sollten.

Das ist wohl Geschmackssache. Aber im Endeffekt egal. Was durch den Compiler geht, sollte ein sinnvolles Ergebnis liefen. Ob es durch den Compiler geht, hat wiederum mit Lazarus nix zu tun, das bestimmt der FPC. Und wenn Widestrings überhaupt existieren, sollte man Ihnen auch auf "normale" Art einen Konstanten Text zuweisen können. Ob Widestrings existieren, hat auch mit Lazarus nix zu tun, das bestimmt ebenfalls der FPC.

-Michael

[theo]

Ja, gut, wenn man die Konstante typisiert, wäre wohl nichts einzuwenden, wenn der Compiler die Umwandlung innerhalb Unicode (also die UTF8 Quelle -> UTF16)
durchführt.
Also so:
const us:UnicodeString='pipapö';

[RSE]

const us:UnicodeString='pipapö';

Dann ist die Konstante aber auch wieder nicht mehr konstant, sondern schreibbar...
Dann lieber:

Code: Alles auswählen

const
  sconst = 'pipapö';
var
  s: UniCodeString;
begin
  s := UniCodeString(sconst);
  ...
end;

[Hitman]

Naja, damit verliert man aber die Möglichkeit der Resource Strings (ich sag nur GNU GetText ...).

[mschnell]

Ja, gut, wenn man die Konstante typisiert...

Wenn
MyString := '1234abcäöü';
ohne Fehlermeldung durch den Compiler geht, muss auch was sinnvolles rauskommen, egal welchen Type MyString hat. Also entweder grundsätzlich Fehlermeldung, wenn rechts von "=", ":=" oder bei einem Unterprogrammaufruf direkt eine Stingkonstante ohne Typangabe steht (das wäre aber sehr lästig) oder der Compiler erzeugt die konstante automatisch im richtigen Typ (macht er ja bei Zahlen auch, wenn sie beispielsweise in einem Unterprogramm-Aufruf angegeben werden: z.B. "1" wird dann automatisch als Byte, Smallint, Int, Int64 oder Extended, oder einem anderen Real-Type codiert).

Der Compiler kann das jetzt schon bei ShortString und AnsiString. es sollte also auch bei WideString und UnicodeString (welcher auch immer) gehen.

Die nächste oder übernächste Compiler-Version wird das sicher in D2010-Art mit dynamisch typisierten Strings machen, was aber (siehe erster Beitrag in diesem Thread) eben auch nicht alle Probleme löst

-Michael