Quo vadis Delphi XE8 ?

[mkinzler]

Zitat:

Naja... Apple macht es anders... Da ist ein Char auch unter 64Bit immer noch 1 Byte lang (Wenn ich die Tabelle richtige verstehe)

Es macht aber ein Unterschied, ob man eine Entscheidung als Betriebssystemhersteller ( Apple) oder als ( nicht führender) Hersteller von Entwicklungssoftware ( CodeGEAR/EMBT) trifft.
Der Unicodesschnitt war hart aber richtig.

Zitat:

Hätte EMBA das auch gemacht, würden nicht so viele Projekte noch auf D2007 hängen... Und es gäbe nicht die "Unicode-Hürde".

Dann wären die Projekte vielleicht auf neue Versionen gehoben, aber immer noch nicht unicodefähig.
Es wäre eher wie mit der BDE, solange es diese gibt, besteht kein Zwang sich von ihr zu verabschieden.

[Bernhard Geyer]

Zitat von mkinzler:

Zitat:

Naja... Apple macht es anders... Da ist ein Char auch unter 64Bit immer noch 1 Byte lang (Wenn ich die Tabelle richtige verstehe)

Es macht aber ein Unterschied, ob man eine Entscheidung als Betriebssystemhersteller ( Apple) oder als ( nicht führender) Hersteller von Entwicklungssoftware ( CodeGEAR/EMBT) trifft.
Der Unicodesschnitt war hart aber richtig.

Ein Char bleibt ein Char, aber zur speicherung von Text werden in den String-Klassen UniChars verwendet

Zitat:

Hätte EMBA das auch gemacht, würden nicht so viele Projekte noch auf D2007 hängen... Und es gäbe nicht die "Unicode-Hürde".

Dann wären die Projekte vielleicht auf neue Versionen gehoben, aber immer noch nicht unicodefähig.[/QUOTE]
Ich glaube auch das viele Projekte bei D2007 hängen geblieben sind da durch die VCL.NET (und des generellen .NET-Ausflugs) viel Entwicklungszeit investiert wurde den man danach wegschmeißen konnte. Das dürfte für einige Firmen das Ende bedeutet

Zitat:

Es wäre eher wie mit der BDE, solange es diese gibt, besteht kein Zwang sich von ihr zu verabschieden.

Dast stimmt. Da würde auch noch die Forderung kommen Chars genauso unter iOS, Android und OSX mit 1 Byte pro Character zu haben.

[himitsu]

Frag mal den Andreas ... die 1-Byte-Chars/Strings gibt es noch. (heimlich versteckt)

Auch wenn ich nicht wirklich verstanden hab, warum man das ANSI/UTF-8 abgeschafft hat.

[jaenicke]

Zitat von himitsu:

Auch wenn ich nicht wirklich verstanden hab, warum man das ANSI/UTF-8 abgeschafft hat.

Weil es leider in vielen Fällen ohne Not einfach so benutzt wird. Oft aus Unkenntnis, oft aus Bequemlichkeit. Selbst in zwei Projekten, die Andreas Unit verwenden, wird es offenbar einfach nur verwendet, damit es Ansi ist, obwohl es dort gar keinen Grund dafür gibt. Nur funktioniert die App nur dadurch nicht z.B. mit chinesischer Sprache (ist aber auch nicht im AppStore).

Deshalb kann ich den Schritt durchaus nachvollziehen...

Es gibt aber natürlich auch seltene Fälle, in denen Ansistrings tatsächlich Sinn machen, auch auf mobilen Plattformen. Zum Beispiel, wenn man mit einem Dienst direkt kommuniziert, der Ansistrings benutzt.

[Stevie]

Zitat von jaenicke:

Es gibt aber natürlich auch seltene Fälle, in denen Ansistrings tatsächlich Sinn machen, auch auf mobilen Plattformen. Zum Beispiel, wenn man mit einem Dienst direkt kommuniziert, der Ansistrings benutzt.

Da kann man doch aber problemlos TBytes hin und her ballern und das per TEncoding lösen oder?

[CHackbart]

Wenn jch überlege was für Verrenkungen ich bei Synapse TCP machen musste. Es macht keinen Sinn den Entwickler zu bevormunden. Fast jede Lowlevel API verlangt nach Ansi und da dauernd Verrenkungen einbauen zu müssen ist eher eine Gängelung.

[jaenicke]

Zitat von Stevie:

Da kann man doch aber problemlos TBytes hin und her ballern und das per TEncoding lösen oder?

Das ist auch der bessere Weg, aber besser ist nicht einfacher und deshalb möchten viele den Weg nicht bestreiten.

[jbg]

Für mich persönlich wäre es schön, wenn zumindest UTF8String zur Verfügung stehen würde. Auf den ANSI-String kann ich verzichten. Aber UTF8 ist der Quasi-Standard des Internets. Und laufend mit TBytes herumzuhantieren macht da wenig Spaß.

Was sieht wohl leserlicher aus (und nein, ich werden Byte nicht in WideChar konvertieren was ein unnötiges "MOVZX" einfügen würde):

Delphi-Quellcode:

B[I] in [Ord('A')..Ord('Z'), Ord('a')..Ord('z'), Ord('_'), Ord('0')..Ord('9')]
// oder
S[I] in ['A'..'Z', 'a'..'z', '_', '0'..'9']

[Mavarik]

Zitat von mkinzler:

Dann wären die Projekte vielleicht auf neue Versionen gehoben, aber immer noch nicht unicodefähig.
Es wäre eher wie mit der BDE, solange es diese gibt, besteht kein Zwang sich von ihr zu verabschieden.

Das mag zwar sein, aber wie viele Leute brauchen den Unicode?
Hätte man das in Projekt XY gebraucht, hätte man sicherlich schon eine Fremdkomponente dafür benutzt und es wäre keine "Hürde"...

Mavarik

[Bernhard Geyer]

Zitat von Mavarik:

Das mag zwar sein, aber wie viele Leute brauchen den Unicode?

Mit Sicherheit genügend. Nicht umsonst gibt es einige Bibliotheken die für alte Delphi-Versionen das Problem halbwegs gelöst haben.
Und du solltest so eine Frage nicht bei den Delphi-Entwicklern stellen die (damals) noch mit Delphi arbeiten sondern bei denen die nicht mehr mit Delphi arbeiten. Ein grund wird fehlender Unicode-Support gewesen sein.

Zitat von Mavarik:

Hätte man das in Projekt XY gebraucht, hätte man sicherlich schon eine Fremdkomponente dafür benutzt und es wäre keine "Hürde"...

Solange die Basisimplementierung der VCL nicht Unicodefähig sind, stellen Fremkomponenten immer nur eine unnötig Komplexen "Fremdkörper" dar. Ich hätte mir damals (2002) sicherlich einige Arbeit sparen können wenn damals die VCL Unicodefähig gewesen wäre und ich nicht komplett auf WideString (glücklicherweise mit eigener Stringdefinition) umsteigen hätte müssen.