XE8: Sinn von FixedInt, FixedUint, System.Hash

[gammatester]

Was ist der vermutliche Sinn dieser Neuigkeiten in XE8?

Neue Integer-Typen
Die Größe der bisher platform-unabhängigen longint und longword hat sich (mW entgegen bisherigen Zusagen) nun doch geändert und wird wohl einige Inkompatibilitäten bringen. Und um die Verwirrung zu steigern, führt man dann noch zwei sofort zwei neue Typen (mit den Eigenschaften der alten) ein: FixedInt und FixedUInt, natürlich mit der Eigenschaft überall (heute) 32-Bit zu sein. Interessanterweise fehlt die Zusicherung, daß sich die Größe nicht ändern wird.

Sinnvoll und systematisch wäre Int32 und UInt32 stärker zu propagieren. Da ich bisher bei meinen Units auf die seit 25 Jahren unveränderte longints setze, währe eine Umstellung auf Int32/UInt32 allerdings eine ziemliche Arbeit.

Neue Hash-Unit
In System.Hash soll es 3 (in Worten DREI) Funktionen geben:Bob Jenkins, MD5, SHA1!

Zu Bob Jenkins (was genau das auch immer ist, Wiki listet 4 verschiedene) kann ich nichts sagen. Aber MD5 und SHA1 sind als kryptogragische Hashfunktionen gebrochen bzw. angezählt und für den nicht-kryptografischen Einsatz viel zu langsam. Als zwei veraltete Funktionen in ein umfassenden Unit OK, aber so ist es doch fahrlässig.

Nichts von SHA256, SHA3 (und Finalisten) bzw. anderen (schnellen) nicht-kryptogragischen (FNV etc) Funktionen.

[mkinzler]

Die von dir angesprochenen Änderungen kamen nicht mit XE8, sondern mit dem 64Bit-Kompiler.

[gammatester]

In diesem XE7-Beitrag werden sie noch als plattform-unabhängig bezeichnet: http://docwiki.embarcadero.com/RADSt...#Integer_Types

[Neutral General]

Also System.Hash ist auf jeden Fall erst seit XE8 dabei.
Finds nicht so tragisch dass nur die 3 Funktionen enthalten sind. MD5 und SHA1 sind wahrscheinlich mit Abstand die am häufigsten verwendeten Hash-Algorithmen.
Damit hat Embarcadero wahrscheinlich 80% der Fälle abgedeckt. Ein paar mehr wären natürlich nett, aber notfalls benutzt man halt weiterhin die 3rd-Party Units falls SHA1/MD5 nicht reichen.
Vielleicht kommt ja mit den nächsten Versionen noch der ein oder andere Algorithmus nach.

[Uwe Raabe]

Zitat:

Zitat von mkinzler (Beitrag 1298856)

Die von dir angesprochenen Änderungen kamen nicht mit XE8, sondern mit dem 64Bit-Kompiler.

Soweit ich weiß, hat Apple das ausgelöst, bei denen ein LongInt auf 32- und 64-Bit unterschiedlich groß ist. Das spiegelt sich ja auch in der aktuellen Implementation in Delphi wieder, bei der lediglich unter 64-Bit iOS der LongInt eine andere Größe hat als sonst.

Ich muss allerdings zugeben, daß ich auch einen anderen Lösungsansatz bevorzugt hätte.

[mkinzler]

Ich habe die Frage totla falsch verstanden. Mit der Einführungung von 64 Bit wurden die plattformabhängigen Typen auf einmal Plattformunabhängig ( wg. Verhalten C/C++ unter Windows) nun wird das veränderte Verhalten unter der neuen 64 Bit iOS Plattform eingeführt und in Delphi werden hierfür wieder andere Typen eingeführt. Schon bei der Einführung des 64Bit Compilers hätte ich, wie die meisten anderen Anwender eher die Einführung von neuen Typen für das neue Verhalten bei Beibehaltung der alten (unveränderten) Typen bevorzugt.

[himitsu]

Zitat:

Zitat von gammatester (Beitrag 1298857)

In diesem XE7-Beitrag werden sie noch als plattform-unabhängig bezeichnet: http://docwiki.embarcadero.com/RADSt...#Integer_Types

Auch in XE8, aber wie gut die Hilfe manchmal ist, braucht man wohl nicht erwähnen.

http://docwiki.embarcadero.com/RADSt...#Integer_Types


Ich hab mich jetzt drauf eingestellt, daß Integer nicht wächst und in anderen Programmiersprachen tut der das auch nicht, wenn er das in Delphi nun doch tun sollte, dann gibt's Haue.





Ist ja schon schlimm genug, daß sLineBreak je nach Zielplattform mal String und da plötzlich Char ist,
aber dem nicht genug, das ist genau genommen sogar AnsiString und AnsiChar, obwohl man sich im NextGen viel mühe gegeben hat das ANSI rauszuwerfen.
Vesucht mal diesen Dreck plattformunabhängig ohne IFDEFs als PChar zu verwenden, oder an ein Char (natürlich nur, wenn Length=1) zuzuweisen. :wall:

[add]
LongInt = 64 Bit?

LONG = 32 Bit
LONG LONG = 64 Bit

Ich hoffe mal LongInt ist und bleibt 32 Bit :shock:

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1298883)

http://docwiki.embarcadero.com/RADSt...#Integer_Types

...

Ich hoffe mal LongInt ist und bleibt 32 Bit :shock:

Wie aus deinem Link unschwer zu erkennen ist, trifft das für iOS-64 ja bereits nicht mehr zu.

[Bernhard Geyer]

Zitat:

Zitat von Uwe Raabe (Beitrag 1298896)

Zitat:

Zitat von himitsu (Beitrag 1298883)

http://docwiki.embarcadero.com/RADSt...#Integer_Types

...

Ich hoffe mal LongInt ist und bleibt 32 Bit :shock:

Wie aus deinem Link unschwer zu erkennen ist, trifft das für iOS-64 ja bereits nicht mehr zu.

Letztenlich muss sich Emba mehr oder minder daran halten was der OS-Hersteller vorgiebt damit die API-Header möglichst 1:1 übernommen werden können.
Und Apple/MS definieren hier auf OS-Seite jeweils eigene Regeln: http://en.wikipedia.org/wiki/Integer...ter_science%29

[himitsu]

Man sollte den Apfel mal verklagen.


Naja, das wars dan mit der vielversprochenden Abwärtskompatibilität von Delphi,
oder kann man FixedInt auch in älteren Delphis nutzen, ohne daß man wirklich jeden Scheiß immer erstmal selber definieren/ableiten muß? :stupid: