XE8: Sinn von FixedInt, FixedUint, System.Hash

[Uwe Raabe]

Zitat von himitsu:

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

Da die Zeitmaschine gerade kaputt ist, wirst du um eine Deklaration á la FixedInt = LongInt mit dem passendem IFDEF wohl nicht herumkommen.

[Bernhard Geyer]

Zitat von himitsu:

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

Zitat von himitsu:

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

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?


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

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 von Uwe Raabe:

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 von gammatester:

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