plattformabhängigen Integertypen LongInt und LongWord

[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