plattformabhängigen Integertypen LongInt und LongWord

[himitsu]

http://docwiki.embarcadero.com/RADSt...t_und_LongWord

Zitat:

Zitat von LongInt und LongWord

LongInt definiert den Integertyp mit Vorzeichen und LongWord den Integertyp ohne Vorzeichen. Die Größe der plattformabhängigen Integertypen LongInt und LongWord ist auf jeder Plattform anders, mit Ausnahme von 64-Bit-Windows; hier bleibt die Größe unverändert (32 Bit).

Ähhhh... :?::wall:

Seit wann sind die Plattformabhängig?
Und wenn ja, was soll der Dreck?

Erst kommen paar ganz Schlaue auf die "geniale" Idee und frieren die plattformabhängigen Typen (INT und UINT / Intager und Cardinal) ein
und nun auch noch das, aber dann nichtmal überall einheitlich, oder ist das nur ein Fehler in der Doku?

Da soll man doch nun NativeInt und NativeUInt für Platformabhängiges nehmen,
aber ich kenn jetzt keine neuen Typen für Platformunabhängiges. :gruebel:
FixedInt, Integer und Int32 (ich weigere mich Integer als Fixed anzusehn, das passt syntaktisch einfach sowas von garnicht)
Aber dennoch knallen nun auch alle Codes, die absichtlich mit LongInt geschrieben wurden, weil der Typ schließlich FIX war. :stupid:

[mensch72]

die ANTWORT liefern es von und für C/C++ Programmierer schon seit Urzeiten... sollen Compilerhersteller doch machen was sie wollen, man arbeite mit eigenen und stets "definierten" Typen... und das klappt auch unter Delphi, man muss nur mit ein paar #ifdefs für CompilerVersion&Plattform arbeiten:)

Delphi-Quellcode:

ACHAR   PACHAR    
WCHAR   PWCHAR

INT8    PINT8     // verwende ich selbst nicht (bei NonUniCode & Microcontrolern ein 8Bit "ACHAR")
INT16   PINT16    
INT32   PINT32
INT64   PINT64

UINT8   PUINT8    // verwende ich selbst nicht, ich bevorzuge hier "BYTE"
UINT16  PUINT16   // genutzt für Shared Code, wenn andere BYTE/WORD/DWORD/QWORD nicht mögen
UINT32  PUINT32   // genutzt für Shared Code, wenn andere BYTE/WORD/DWORD/QWORD nicht mögen 
UINT64  PUINT64   // genutzt für Shared Code, wenn andere BYTE/WORD/DWORD/QWORD nicht mögen

BYTE    PBYTE     // auch wenn es außer Mode ist, ich habe und schreibe noch viel Code unter Nutzung dieser Type
WORD    PWORD     // gehört weiter zu meinen bevorzugten Grundtypen
DWORD   PDWORD    // gehört weiter zu meinen bevorzugten Grundtypen
QWORD   PQWORD    // verwende ich der "optischen" Einheitlichkeit wenn "WORD"&"DWORD" in Verwendung, sonst "UINT64"

Ich gebe aber zu, das ich viel "PAS" Quelltexte sehe, wo quasi nur mit "integer" oder wenn es hoch kommt nochmal mit cardinal gearbeitet wird.
Da fange ich stets zu grübeln an, wenn da mit "shl" Bits geschoben werden, wo und ob denn ein "gewollte" Typüberlauf ist als implizites Modulo bzw. AND-Maske ist.

Ich möchte das mein Quelltext sich unter allen Umständen gleich verhält. Das gelingt mit unter Nutzung "verständlicher" und 100% langzeit konstanter Grund-Typen. Und wenn wir irgendwann bei 128Bit Typen sind, dann werden das für mich zusätzliche komplett neue sein, die nichts an meinen anderen Typen ändern:)

[Der schöne Günther]

Ich bin da kein Spezialist, aber ich verstehe das so:

1. Ja, unter Windows war und ist "Long int" fix, egal ob 32 oder 64 Bit
2. Plattformen wie z.B. Apple verstehen unter "long int" unter Umständen etwas anderes

Dementsprechend hätte Borland/CodeGear/Embarcadero doch alles richtig gemacht, oder?

Beispiel:
http://www.agner.org/optimize/calling_conventions.pdf (Stand 2017)
listet für "long int" meist 4 Byte, aber manche Plattformen eben auch mit 8 Byte.

[himitsu]

Zitat:

Zitat von mensch72 (Beitrag 1390473)

Ich möchte das mein Quelltext sich unter allen Umständen gleich verhält.

Genau darum geht es ja.

entweder ic will immer und überall fest mit einer bestimmten Menge an Bits arbeiten,
oder es soll sich z.B. an der größe des Speicherbereichs (Pointer) ausrichten.

Ein Code der eigentlich das Selbe macht, aber wo unter Windows 32 Bit und unter MacOS 64 Bit, obwohl Beides mit 64 Bit kompilert, ist doch krank und IMHO nicht wirklich nutzbar.
Es wird einem ja schon mit ARC in den Mobilen das Leben zur Hölle gemacht, weil sich sich dort Objekte nicht mit Free freigeben, selbst wenn ich das eigentlich wollte und es ist ohne IFDEFs fast nicht möglich einen platfomübergreifenden einfachen Code zu basteln.

[Sherlock]

Zitat:

Zitat von mensch72 (Beitrag 1390473)

Ich möchte das mein Quelltext sich unter allen Umständen gleich verhält.

...weshalb du auch niemals die Delphi Version wechselst. :thumb:
Dein Quelltext wird sich zwischen zwei Delphi-Versionen annähernd gleich verhalten, aber das ist keine sichere Sache, und IMHO auch keine zugesicherte Eigenschaft eines Delphi-Compilers.

Das gilt natürlich nur, wenn Du keinen Assemblercode verwendest. Aber wozu dann noch Delphi? Andererseits, mit jedem Prozessorrelease kann sich auch etwas ändern...

Dein Ziel ist also, meiner bescheidenen Meinung nach, nicht zu erreichen und rechtfertigt den Aufwand mithin nicht.

Sherlock

[freimatz]

Zitat:

Zitat von himitsu (Beitrag 1390494)

entweder ic will immer und überall fest mit einer bestimmten Menge an Bits arbeiten,
oder es soll sich z.B. an der größe des Speicherbereichs (Pointer) ausrichten.

Und das hält EMB und auch ich für nicht sinnvoll.

Es gibt bei mir viele Fälle wo ich nicht eine bestimmten Menge an Bits benötige sondern will das es effizient läuft.
Zum Beispiel ein "for i := 0 to Container.Count do ...". Angenommen der Count ist typischerweise 5-10 groß, kann vielleicht auch mal 20 sein. Da ist es mir wurscht ob das ein 8,16,32,... ist. Da ist es mir recht dass der Compiler dann das nimmt was er für am effizientesten hält.

[himitsu]

Zitat:

Zitat von freimatz (Beitrag 1390504)

Es gibt bei mir viele Fälle wo ich nicht eine bestimmten Menge an Bits benötige sondern will das es effizient läuft.

Dafür wurde doch NativeInt erfunden, als man den Integer einfror.
Ein Integer-Typ, der sich nach der Bitigkeit der CPU Registergröße/Speicheradressierung richtet.

Mir war nur grade aufgefallen, das auch der andere "Feste"-Typ nun nicht mehr fest ist.

[Delphi-Laie]

himitsu, ich stimme Dir zu. Das sind so die alltäglichen Widrigkeiten, Ärgernisse und Mehraufwendungen, die besonders verärgern, weil sie unnötig sind.

M.E. hätte man schon früher klare Typisierungen festlegen - und diese dann auch durchhalten - und weitsichtigere Entscheidungen treffen sollen.

Mir schwebt folgendes vor:

Integertyp mit und ohne Vorzeichen, plattformabhängig, erkennbar am Fehlen einer Zahl. Wobei "Byte" ja schon seit Computerur- oder zumindest -frühzeiten auf 8 Bit festgelegt ist. Diese Universaltypen wären dann am ehesten Cardinal und Integer, die ja auch mal dafür so geplant waren.

Und dann plattformunabhängige, bitanzahlkonstante Integertypen: Card16, Card32, Card64, Int16, Int32, Int64 usw.

Ist das so schwierig?

[Uwe Raabe]

Zitat:

Zitat von Delphi-Laie (Beitrag 1390509)

Und dann plattformunabhängige, bitanzahlkonstante Integertypen: Card16, Card32, Card64, Int16, Int32, Int64 usw.

Meinst du sowas? (Kopiert aus System.pas):

Delphi-Quellcode:

  Int8    = ShortInt;
  Int16   = SmallInt;
  Int32   = Integer;
  IntPtr  = NativeInt;
  UInt8   = Byte;
  UInt16  = Word;
  UInt32  = Cardinal;
  UIntPtr = NativeUInt;

[Delphi-Laie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1390510)

Meinst du sowas?

Sicher.

Es kommen mit jeder Bitanzahlverdoppelung native Integertypen - und dann noch mit eigenem Namen - hinzu, sodaß es immer mehr werdne un das Chaos immer größer wird.

[TiGü]

Zitat:

Zitat von Delphi-Laie (Beitrag 1390511)

Zitat:

Zitat von Uwe Raabe (Beitrag 1390510)

Meinst du sowas?

Sicher.

Es kommen mit jeder Bitanzahlverdoppelung native Integertypen - und dann noch mit eigenem Namen - hinzu, sodaß es immer mehr werdne un das Chaos immer größer wird.

Joah, vier signed Typen und vier unsigned Typen sind schon echtes Chaos...:roll:

Da reicht eine Hand nicht mehr zum Abzählen, muss man die zweite mit hinzunehmen. :lol:

[Delphi-Laie]

Zitat:

Zitat von TiGü (Beitrag 1390512)

Joah, vier signed Typen und vier unsigned Typen sind schon echtes Chaos...:roll:

Da reicht eine Hand nicht mehr zum Abzählen, muss man die zweite mit hinzunehmen. :lol:

Byte, Word, Integer, ShortInt, SmallInt, Cardinal, Int64, LongInt, LongWord, NativeInt, NativUInt...

So aus dem Stegreif. Sind jetzt schon 11. Wer zählen kann, ist klar im ...

[Uwe Raabe]

Zitat:

Zitat von Delphi-Laie (Beitrag 1390511)

Es kommen mit jeder Bitanzahlverdoppelung native Integertypen - und dann noch mit eigenem Namen - hinzu,

Dann nimm doch die oben gezeigten. Bei denen ist die Größe ja durch die Zahl im Namen eindeutig. Da die bereits in System.pas deklariert sind, muss man da auch nicht noch selbst was erfinden.

[Delphi-Laie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1390515)

Bei denen ist die Größe ja durch die Zahl im Namen eindeutig.

Genau das war doch meine Aussage.

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

[TiGü]

Zitat:

Zitat von Delphi-Laie (Beitrag 1390513)

Zitat:

Zitat von TiGü (Beitrag 1390512)

Joah, vier signed Typen und vier unsigned Typen sind schon echtes Chaos...:roll:

Da reicht eine Hand nicht mehr zum Abzählen, muss man die zweite mit hinzunehmen. :lol:

Byte, Word, Integer, ShortInt, SmallInt, Cardinal, Int64, LongInt, LongWord, NativeInt, NativUInt...

So aus dem Stegreif. Sind jetzt schon 11. Wer zählen kann, ist klar im ...

Mit Int64 und UInt64 komme ich auf zwei mal fünf...der Rest sind Aliasse.
Weißt du, was ein Alias ist?

Selbst wenn es zwanzig oder dreißig wären...na und? Überfordert dich das? Wirklich? :shock:

[Uwe Raabe]

Zitat:

Zitat von Delphi-Laie (Beitrag 1390516)

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?

[Delphi-Laie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1390525)

Zitat:

Zitat von Delphi-Laie (Beitrag 1390516)

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:

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.

[himitsu]

Zitat:

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

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

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