plattformabhängigen Integertypen LongInt und LongWord

[himitsu]

Zitat:

Zitat von Der schöne Günther (Beitrag 1390530)

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. :freak:
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. :zwinker:

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

Zitat von Delphi-Laie (Beitrag 1390526)

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

[himitsu]

Zitat:

Zitat von Sherlock (Beitrag 1390586)

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.

Und genau da lag ja mein Problem, dass sich eigentlich (ehemals) per Definition feste Typen nun plötzlich platformabhängig verhalten. :wall:

[Sherlock]

Ich verstehe ja durchaus Dein Problem, und kann Deine Verärgerung absolut nachvollziehen. Ich bin andererseits aber nie auf die Idee gekommen, nachzuschauen welche Typen jetzt festgemauert sind und welche nicht. Ich prüfe nach dem String-Debakel von 2009 bei solchen Sachen immer zur Laufzeit ob und wie die Rahmenbedingungen erfüllt sind. Ich muss allerdings noch erwähnen, daß ich keine Bitshifts oder so mache.

Sherlock

[Der schöne Günther]

Zitat:

Zitat von Sherlock (Beitrag 1390615)

Ich prüfe nach dem String-Debakel von 2009 bei solchen Sachen immer zur Laufzeit ob und wie die Rahmenbedingungen erfüllt sind.

Ich prüfe das in einem einzigen Unit-Test ob die Annahmen stimmen 8-)

[himitsu]

Zitat:

Zitat von Sherlock (Beitrag 1390615)

Ich prüfe nach dem String-Debakel von 2009 bei solchen Sachen immer zur Laufzeit ob und wie die Rahmenbedingungen erfüllt sind.

Ich schreibe ja einige Komponenten, welche nach Möglichkeit auf allen Plattformen laufen sollen, mit dem Problem, dass ich aktuell kein Android mehr kompilieren kann.
Linux mir immer zu teuer sein wird und ich auch keine iProdukte habe.

Also muß ich ja erstmal blind darauf vertrauen, dass es so auch wo anders funktionieren könnte. :cry:


Ich nutze auch lieber Delphi/Pascal-Standard-Typen (wie eben LongInt) und versuche die Codes so zu schreiben, dass Compilerabhängiges auch compilerabhängig ist und Festes eben fest.
Da ist es jetzt kein Vorteil, wenn compilerabhängige Typen plötzlich fix sind und fixe Typen manchmal sich verändern.

Als 64 Bit raus kam, da stand auch in den Entwicklerhinweisen, dass der Integer nun fest ist, aber ich kann mich nicht erinnern sowas über den LongInt gelesen zu haben.
Sah es nur zufällig, als ich wegen was Anderem da rein sah und hoffte es könnte auch ein Fehler in der Hilfe sein.