Quo vadis Delphi XE8 ?

[himitsu]

Jupp, leider ist Emba daran mal nicht Schuld.

Immerhin waren die ja nicht die Ersten, werlche für 64 Bit eine Entwicklungsumgebung anboten (eher die Letzten )
und da waren Andere (Microsoft, Intel usw.) schon vorher auf die geniale Idee gekommen und haben beschlossen den Integer-Typen einzufrieren und dafür einen neuen Typen einzuführen, welcher ab jetzt als dynamischer/plattformabhängiger System-Typ definiert wurde, der sich an die CPU anpasst.

In Delphi nannte er sich er sich dann NativeInt und NativeUInt.


Und im Grunde war GodeGear/Embarcadero wenigstens konsequent, als sie von ANI auf Unicode umstellten.
Es ist ja nicht deren Schuld, daß viele ihren Code "schrottig" schrieben, indem sie z.B. PChar verwendeten, obwohl sie eigentlich ausschließlich einen ANSI-String behandeln wollten, oder daß sie bei Verwendung von PChar nicht die Größe richtig "dynamisch" bestimmten.

Gut, beim Integer hatte man somit Pech, wobei Integer-Casts von und zu Pointern nicht wirklich richtig waren, denn auch dafür gibt es entsprechende Typen, wie z.B. IntPtr, welche auch jetzt noch richtig gearbeitet hätten.
Für die Parameter bei den Messages gab es auch schon immer die entsprechenden Typen WPARAM, LPARAM und LRESULT.

Und PChar, Char und String war per Definition auch schon lange vor 2009 als dynamisch/plattformabhängig definiert.
Außerdem hätte man wissen müssen, daß man Speicher und Übertragungsformate niemals plattformabhängig definiert, außer man schreibt den Typen mit ins Protokoll.

Wer alles vorher richtig gemacht hatte, hatte bei Umstellungen auf Unicode oder 64 Bit keine oder zumindestens fast keine Probleme.



Wie man in Stevies Link sieht, war/ist es in C/C++ traditionell üblicher, daß es da viel mehr Typen gibt und diese speziell auf gewisse Bereiche ausgelegt sind, damit sich zukünftige Änderungen genauer anpassen.
In Pascal versuchte man das einfacher zu halten und fasste viele Typen quasi zusammen und leider wurde der Integer, Char und PChar zu oft für falsche Dinge eingesetzt, auch wenn sich Herr Wirth und Andere schon ein paar Gedanken gemacht hatten und für gewisse Dinge spezielle Typen einführten.

[Mavarik]

Zitat von himitsu:

Und im Grunde war GodeGear/Embarcadero wenigstens konsequent, als sie von ANI auf Unicode umstellten.
Es ist ja nicht deren Schuld, daß viele ihren Code "schrottig" schrieben, indem sie z.B. PChar verwendeten, obwohl sie eigentlich ausschließlich einen ANSI-String behandeln wollten, oder daß sie bei Verwendung von PChar nicht die Größe richtig "dynamisch" bestimmten.

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

[OT]
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".
Ja ja ja die VCL... Schon klar... Hätte man zweigleisig fahren müssen...Ein schönen Compilerswitch welche Version gelinkt werden soll....[/OT]

Mavarik

[Bernhard Geyer]

Zitat von Mavarik:

Naja... Apple macht es anders... Da ist ein Char auch unter 64Bit immer noch 1 Byte lang (Wenn ich die Tabelle richtige verstehe)
[OT]
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".

Apple hat eine dem String-Type entsprechenden Typ CFString und der Arbeitet mit UniChar. Wenn man diesen Verwenden und die dafür vorgesehen Zugriffsfunktionen wird man (ähnlich wie bei der MFC mit CString) relativ wenig mitbekommen haben als man auf Unicode umgestiegen ist.
Bei Delphi konnte man viele Jahre "faulenzen" und die Compilermagic verwenden statt sich an den relevanten Stellen (Datei speichern, APIs, ...) Gedanken machen zu müssen.
Mit D2009 musste halt diese Stellen angepasst werden. Wenns man richtig gemacht hat waren es nicht zu viele.

Zitat von Mavarik:

Ja ja ja die VCL... Schon klar... Hätte man zweigleisig fahren müssen...Ein schönen Compilerswitch welche Version gelinkt werden soll....[/OT]

Man kann per Unit diesen Schalter setzten bis man diese gefixt hat. Aber dies Diskussion wieso und wieso nicht gabs schon öfter.

[himitsu]

Nein PChar muß 2 Byte sein, denn PChar ist das Äquivalent zum String, welches na nun ein Alias für den UnicodeString ist.

Ja, man hätte natürlich auch den String als Alias für einen UTF8String nehmen können, dann wäre PChar 1 Byte geblieben,
aber dann müsste man für alle WinAPIs einen Wrapper bauen können, da es Diese nur als ANSI oder UTF-16 (Unicode) gibt.

So paßt nun der PChar genau auf die Unicode-Versionen der WinAPIs drauf.

[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.

[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.