plattformabhängigen Integertypen LongInt und LongWord

[Delphi-Laie]

Zitat von Uwe Raabe:

Zitat von Delphi-Laie:

Wie man es konsequent und übersichtlich hätte machen können, beschrieb ich schon weiter vorn.

Hat man aber doch! Oder woher glaubst du, habe ich die Deklarationen?

Nun, dann müssen himitsu und meine Wenigkeit sich eben geirrt haben. Ist alles eben doch konsequent, logisch und einheitlich.

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

[Uwe Raabe]

Zitat von Delphi-Laie:

Nun, dann müssen himitsu und meine Wenigkeit sich eben geirrt haben. Ist alles eben doch konsequent, logisch und einheitlich.

Ich verstehe den Einwand jetzt nicht. Es ist schon seit einigen Versionen möglich, die Typen Int8, Int16, Int32, Int64 und die zugehörigen UInts zu verwenden. Für native Typen gibt es dann noch NativeInt und NativeUInt, während für die Angleichung an einen Pointer die Typen IntPtr und UIntPtr zur Verfügung stehen. Man muss sie halt nur benutzen. Ich hatte dich anfangs so verstanden, daß dies genau das ist, was du vorgeschlagen hast. Ich habe lediglich darauf hingewiesen, daß es das bereits gibt.

[Sherlock]

Ich darf genüßlich auf die String vs. WideString/AnsiString Diskussion verweisen, die damals™ entbrannte, als Delphi "plötzlich" Unicode konnte. In Licht dieser Erfahrungen macht es keinen Sinn ungeprüftes Bitgeschiebe zu praktizieren, oder sich auf mögliche Überläufe zu verlassen. Man arbeitet als Entwickler nunmal nicht ohne Netz und doppelten Boden. Es gibt zu jedem dieser Typen die Möglichkeit, seine Bittigkeit zur Laufzeit zu ermitteln. Berücksichtigt man das, gibt es keine Probleme, wenn man die Standardtypen ohne spezifizierte Bittigkeit nimmt.

Sherlock

[Der schöne Günther]

Also ich verstehe ihn schon, Überläufe und Bitgeschubse möchte man unter Umständen schon gerne haben.

Wenn man immer auf allen Plattformen die gleichen Typen haben möchte braucht man ein Laufzeitsystem wie .NET oder Java. Delphi ist immer gerne "native", deshalb richten sich Standard-Typen der Delphi-RTL verständlicherweise nach der Plattform.

Möchte man (CRC ist ein gutes Beispiel) einen Typ mit Länge X muss man das auch sagen (Int32, UInt8, ...)

[Sherlock]

Ich habe nichts gegen Überläufe und Bitgeschupse. Aber bitte nicht ungeprüft. Überalls sonst wird man gemahnt die Grenzen eines Objekts aktiv zu beachten. zB bei Schleifen durch ein Array eben über Low(Array) bis High(Array) zu gehen und nicht blind etwa von 1 bis length(Array) oder ähnliches.

Hier muss man eben aktiv die "Bytigkeit" seines Integers beachten/prüfen/auswerten, um zu wissen, ab wann oder ob man es mit einem Überlauf zu tun haben könnte.

Sherlock