Quo vadis Delphi XE8 ?

[Insider2004]

Wenn man sich so die SVN Folder im Netz anschaut, dann bekommt man schon wieder Schüttelfrost. Man wollte doch den String-Salat aufräumen, damit Anfänger sich besser in Delphi zurechtfinden (siehe UTF8 abschaffen etc.). Das hat man dann auch gründlich gemacht. Doch was müssen meine blutunterlaufenen Äuglein jetzt sehen!?!? LargeInt, LargeUInt, FixedInt, FixedUInt. Ich wette, denen fällt bestimmt noch mehr ein! Die Prozessorregister werden nicht mehr. Auch wenn man 10 weitere Typen einführt. Da wünsche ich dann noch fröhliches Typ-Raten im Informatikunterricht und den restlichen Delphi-Stuben auf der Welt!

BTW: scheinbar kennen die Ingenieure bei Emba nicht mehr den Unterschied zwischen generischen und fundamentalen Integern. Das geht bei denen wild drunter und drüber. Die wären vermutlich auch bei Niklaus Wirth durch das Vor-Diplom gefallen.

[Stevie]

Könnte das am Ende gar daran liegen? ...

[Daniel]

Das ist grundsätzlich nichts Neues.
Wir haben Datentypen, die plattformabhängig sind und welche, die plattformunabhängig sind.

Die Datentypen sind allesamt hier dokumentiert:
http://docwiki.embarcadero.com/RADSt..._Integer_Types

Das Zielsystem gibt die jeweiligen Spielregeln vor - alles andere würde wenig Sinn machen, schliesslich wollen wir ja gerade die Interoperabilität mit den jeweiligen Systemen. Und nun eben auch mit iOS64.

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