plattformabhängigen Integertypen LongInt und LongWord

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

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.

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

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

[himitsu]

Zitat von Sherlock:

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.


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.

[himitsu]

Zitat von Der schöne Günther:

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

Für Dinge, wo man davon ausgeht, dass sie immer so sind, da schreibt selten jemand einen Test für.