plattformabhängigen Integertypen LongInt und LongWord

[Der schöne Günther]

Und ich dachte Entwickler könnten nur im unendlichen Tabs gegen Leerzeichen-Krieg so emotional werden.

[himitsu]

Konsequent und logisch, aus Sicht der jeweiligen Plattformen vielleicht, aber aus Sicht eines Codes für Multiplatform ist es das IMHO nicht.
Und vorallem auch nicht aus Sicht der "uns" bekannten Muster von Typen. (wegen der Wiederverwendbarkeit alter Codes / uns = Windows+Pascal)

Gut, dass Integer und Cardinal nun nicht mehr systemabhängig sind, das kann man verkraften, wenn man einfach still und heimlich vergisst wie es zu Zeiten von 8 und 16 Bit mal war.
(dabei war Delphi im Jahre 2006 noch sooooooooooooo stolz auf seine berühmte Abwärtskompatibilität)

Aber es war nunmal früher so, dass LONG = 32 und LONG LONG = 64, also LongInt immer 32 und nicht plötzlich 64, auch auf 64 Bit-Systemen (außer im Windows 64).
Was hätte dagegen gesprochen den LongInt 32 zu lassen und wegen MacOS stattdessen z.B. ein OptimalInt zu erfinden?



Genauso gibt es keinen plausiblen Grund, warum obj.Free unter ARC nicht Free macht, sondern einfach "fahrlässig" komplett ignoriert wird (garnichts macht).
Hier gab es aus den anderen Systemen ein Äquivalent, also hätte man DisposeOf auch als Alias für Free hinzufügen können, weil es dort das Selbe wie ohne ARC das Free macht, um leichter C#-Code nach Delphi portieren zu können,
und stattdessen ein FreeLater (oder so), als Äquivalent zum obj:=nil der bekannten GarbageCollector-Systeme.

[Der schöne Günther]

Die Memory-Management-Geschichte ist eine Katastrophe, das sehe ich auch so.

Aber das Problem mit den Typbezeichnungen verstehe ich ehrlich gesagt immer noch nicht. Angenommen man erstellt Code in Zeiten als Delphi rein "Windows only" war. Der gleiche Code tut doch auch heute, egal ob Windows 32 oder 64-Bit immer noch das absolut richtige, oder?

Das man auf anderen Plattformen gleiche/ähnliche Namen für teilweise andere Datentypen erfunden hat kann man doch Delphi nicht anlasten, oder?


PS: Wenn ich z.B. etwas plattformspezifisches mit der WinApi mache nehme ich auch immer die entsprechenden Typen (wie DWORD oder ULONG) statt den "High-Level-Typen" (wie Cardinal) die grade jetzt in meiner aktuellen Konfiguration drauf passen würden. Ist das nun richtig oder falsch?

[himitsu]

Zitat von Der schöne Günther:

Der gleiche Code tut doch auch heute, egal ob Windows 32 oder 64-Bit immer noch das absolut richtige, oder?

Nein?

Wenn die Funktion auf 32 Bit ausgelegt war und man deswegen auch absichtlich LongInt anstatt Integer verwendet hatte, aber der Typ jetzt plötzlich 64 Bit ist, dann funktionieren Überläufe und Bitschieberreien nicht mehr richtig.
In Nicht-Windows-64-Bit sind diese Typen aber nun in ihrer Funktion vertauscht.
Unter 16&32 Bit waren sie andersrum, bei 32 Bit und im Windows waren sie gleich und unter 64 Bit nun sorum (außer Windows).
> 16 und 32 Bit : Integer = platformabhängig und LongInt = 32 Bit
> 32 und 64 Bit : Integer = 32 Bit und LongInt = platformabhängig (außer Win64)

Aus einen CRC32 wird ja auch nicht gleich ein CRC64, nur weil man den mit 64 Bit kompilert.

[Zacherl]

Ich denke nicht, dass sich unter Windows für dich etwas ändert. Diese skalierenden Integertypen sind nicht so ungewöhnlich, wenn man schonmal mit C/C++ gearbeitet hat. Da garantieren die Standardtypen (short, long, long long, etc) auch jeweils nur MINDESTENS die Größe von (16, 32, 64-Bit).

Unter Windows sehen die Typen mit EXAKTER Größe allerdings trotzdem immer wie folgt aus:

Code:

typedef signed char        int8_t;
typedef short              int16_t;
typedef int                int32_t;
typedef long long          int64_t;