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:

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1298914)

oder kann man FixedInt auch in älteren Delphis nutzen, ohne daß man wirklich jeden Scheiß immer erstmal selber definieren/ableiten muß? :stupid:

Da die Zeitmaschine gerade kaputt ist, wirst du um eine Deklaration á la

Delphi-Quellcode:

FixedInt = LongInt

mit dem passendem IFDEF wohl nicht herumkommen.

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1298914)

Naja, das wars dan mit der vielversprochenden Abwärtskompatibilität von Delphi,

Ist es doch. Unter 32-Bit ändert sich nix.

Liegt halt an deinen Quellcode der nicht Aufwärtskompatible ist :stupid:

Zitat:

Zitat von himitsu (Beitrag 1298914)

oder kann man FixedInt auch in älteren Delphis nutzen, ohne daß man wirklich jeden Scheiß immer erstmal selber definieren/ableiten muß? :stupid:

Mit Ifdef in eigene Basisunit und schon sollte es gehen. Mach ich z.B. mit Funktionen wie CharInSet.

[himitsu]

Zusammengefasst also wie Folgt?


Wenn man einen Integer will, der 32 Bit ist, dann wird das schwerer, ohne sich den selber zu implementieren.

Vor 64-Bit-CPUs war Integer mal dynamisch und wurde danach statisch/eingefroren. Aber LongInt war wenigstens immer 32. NativeInt wurde als Ausgleich erfunden, den man davor aber nicht nutzen kann, weil ihn noch Keiner kennt und Emba keine Updates für ältere Delphi anbietet.

Seit Apfel64 ist LongInt, der eigentlich statisch ist, plötzlich dynamisch. Dafür gibt es nun FixedInt, den man davor natürlich nicht nutzen kann.



Auch Int32 gibt es noch nicht so lange, oder?
Und da Int32 doch per Definition ein LongInt ist, oder andersrum, müsste der Apfel den doch auch wachsen lassen? :stupid:


Und FixedInt als Name ist auch nicht viel besser, denn auf was ist der denn aktuell fix? (jetzt noch 32 Bit)

Beim Integer hatten sich ja fast alle so "geeinigt", auch wenn ich es immernoch für einen Fehler halte. (aber annähernd nichtmal so schlimm wie LongInt)



Multiplattform und mehrere OS-Versionen kann man so "grundsätzlich" vergessen unterstützen zu wollen und muß für jede Plattform fast schon einen eigenen Code schreiben. :freak:
Oder alles selber machen und das ständig anpassen.

[Stevie]

Ich versteh die ganze Aufregung um diese LongInt Geschichte nicht. Benutzt halt Integer oder explizit Int32 und dann seid ihr bei 32bit auf jeder Platform.
Wer nen bisschen über den Delphi Tellerrand schaut, weiß, dass LongInt nunmal *NICHT* nur 32bit sein kann.

Wer mir nicht glaubt, kann ja mal in die Code completion gucken, wenn er LongInt oder Int32 tippt, worauf die mappen - huch auf Integer (*). Das ist nunmal der Basistyp, wenn man nun aber andere gemappte Types nutzt, dann hat man nunmal nen Problem, wenn die auf ner anderen Plattform anders gemappt sind.

Einzig die Entscheidung, komplett neue Typen für etwas zu erfinden, dass es schon gibt, erschließt sich mir nicht.
Außer sie wollen irgendwann Integer auch dynamisch machen :stupid: Aber dann geh ich auch auf die Barrikade, denn dann wär das Chaos komplett.

(*) außer LongInt bei iOS64, der mappt nun auf Int64, Dankesbriefe an diejenigen, die sich den ISO Standard ausgedacht haben (siehe oben verlinkte Tabelle auf Wikipedia) und nicht immer alles Apple zuschieben, die Devs dort mussten auch in den sauren Apfel (*schenkelklopf*) beißen: siehe https://developer.apple.com/library/...pto64-Bit.html

[Uwe Raabe]

Zitat:

Zitat von Stevie (Beitrag 1298962)

Ich versteh die ganze Aufregung um diese LongInt Geschichte nicht. Benutzt halt Integer oder explizit Int32 und dann seid ihr bei 32bit auf jeder Platform.

Vor ganz vielen Jahren kamen diese LongInts unter Delphi 1 (oder war es schon in Turbo Pasacal) rein, da dort ein Integer nur 16 Bit hatte. Im Laufe der Zeit konnte man das bis XE8 aber bequem umstellen. Allerdings finden sich solche Artefakte noch immer in manchen Bibliotheken, die nicht so gut gepflegt sind.

[Stevie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1298965)

Vor ganz vielen Jahren kamen diese LongInts unter Delphi 1 (oder war es schon in Turbo Pasacal) rein, da dort ein Integer nur 16 Bit hatte. Im Laufe der Zeit konnte man das bis XE8 aber bequem umstellen. Allerdings finden sich solche Artefakte noch immer in manchen Bibliotheken, die nicht so gut gepflegt sind.

Naja, das ist ja auch erst 20 Jahre her. Gott sei Dank, musste Delphi 1 keine Lochkarten verarbeiten, sonst müssten die vermutlich auch noch unterstützt werden...

Zitat:

Zitat von gammatester (Beitrag 1298854)

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.

Vermutlich war das einfach nur eine Aufräumarbeit, da an zunehmend mehr unterschiedlichen Stellen Hash Algos benutzt werden und oftmals erneut implementiert wurden/werden mussten. Der Bob Jenkins Hash wurde seit Delphi 2009 für die Comparer aus Generics.Defaults benutzt und wurde vermutlich nur der Ordnung halber dort hinein verschoben.

[mensch72]

da ich neben Delphi auch weiter C/C++ bis herunter zu 8Bit MicroControlern schreibe, verwende ich von von C/C++ gewohnt auch in Delphi von Anfang an möglichst nur eigene Typen, welche auf ewig eine feste Größe(Bitanzahl) haben.

BYTE (oder "neumodisch" UINT8)
WORD (oder "neumodisch" UINT16)
DWORD (oder "neumodisch" UINT32)
QWORD (oder "neumodisch" UINT64)

bzw.
INT8
INT16
INT32
INT64

Ich glaube, UINT128 & INT128 werde ich wohl noch erleben (müssen).


Integer oder Cardinal oder was es da aktuell sonst noch von Delphi oder manchen C-Compilern gibt, das wird per IFDEF zentral&einmalig passend zugeordnet.
Dann noch immer nur "packed records"... so sind und bleiben Quelltexte und Daten portabel, plattform- & sprachunabhängig