siro hat geschrieben:Ich hoffe, er tut das nicht, das kam mir nur in den Sinn, weil ich mich fragte wie das mal funktioniert haben soll mit einem Shortint.
Der Fehler hätte doch dann früher auch schon auftreten müssen.
Ich habe mir meine eigenen Datentypen gemacht, sicherlich nicht jedermanns Geschmack,
aber ich kann meinen Code dadurch wesentlich besser lesen und dokumentieren.
Der Ursprung lag aber ursprünglich beim "C" weil ich auch nie wuste wie groß die Datentypen sind.
Der Typ Integer ist zwar in 99 Prozent der Fälle okay, aber es ist ja nie wirklich klar wie groß er nun wirklich ist.
Durch meine Deklarationen sehe ich sofort was gemeint ist.
Du weißt aber schon das es im system header vom fpc folgende Definitionen gibt oder?
Code: Alles auswählen
type
...
NativeInt = PtrInt;
NativeUInt = PtrUInt;
Int8 = ShortInt;
Int16 = SmallInt;
Int32 = Longint;
IntPtr = PtrInt;
UInt8 = Byte;
UInt16 = Word;
UInt32 = Cardinal;
UIntPtr = PtrUInt;
Und ja die ganze verwirrung kommt ja vor allem zustande da weder der C noch der C++ standard wirklich die größe von Integers definiert. Im C und auch im C++ standard ist es so definiert: short mindestens 16 bit, int mindestens 16 bit, long mindestens 32 bit und long long mindestens 64 bit. Ein Compiler der ein 20 bit short, 50 bit int, 43 bit long und 500 bit long long kompiliert wäre also komplett Standard konform, auch wenn es wenig sinn macht (es wird noch verrückter wenn man mit signed und unsigned anfängt). Daher definiert der standard sogar die type intxx_t und uintxx_t, denn diese sind genau auf xx bit definiert
In praktisch allen anderen Sprachen wird dieser Fehler der in C gemacht wurde umgangen indem praktisch überall (wie auch beim fpc) int immer 32 bit ist und vermutlich wird das vorerst auch so bleiben, denn selbst wenn die 128 bit architektur raus kommt kennt man mittlerweile die probleme aus C, und würde einen teufel tun integer zu redefinieren