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