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.