For-Schleife bricht unerwartet ab

[Warf]

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

[indianer-frank]

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

Das ist nur halb-richtig, im FPC-Default-Modus ist integer 16-Bit,

The integer type maps to the smallint type in the default Free Pascal mode

[indianer-frank]

(Bitte löschen, falsche Funktion)

[Warf]

Das ist nur halb-richtig, im FPC-Default-Modus ist integer 16-Bit,

The integer type maps to the smallint type in the default Free Pascal mode

Stimmt, default FPC mode ist allerdings auch Praktisch eine andere, lang gestorbene, Sprache. Mit fpc meinte ich ObjFPC mode, da heutzutage keiner mehr das alte Pascal verwendet. Und auch da ist es wenigstens immer 16 bit, und nicht zwischen durch mal 32 oder 64 je nach dem wie der compiler lust und laune hat

[Mathias]

Was ich mir angewöhnt habe, wen es wichtig ist, wie ein Integer aussieht, dann deklariere ich mit int8, uint8, int16, uint16, etc.

Ist auf Embedded Systemen sinnvoll. Bringt auf dem PC gar nichts. Die Datentypen werden immer auf die 32 oder 64bit des OS erweitert.

Ist mir mal böse aufgestoßen, als ich eine Rechenroutine für einen Sensor auf dem PC "optimieren" wollte. Da funktionierte das mit int16 wunderbar, auf dem µC dann gar nicht. Ja, der Compiler hat auf dem PC die int16 einfach auf 64bit erweitert und da passten alle Werte locker rein.

Wie hast du dies hingekriegt ?
Hattest du die Integer in einem record ?

[Timm Thaler]

Und auch da ist es wenigstens immer 16 bit, und nicht zwischen durch mal 32 oder 64 je nach dem wie der compiler lust und laune hat

Sicher?

Code: Alles auswählen

var
  utemp : uint16;
  bmp_ac5, bmp_ac6 : uint16;
  x1 : int16;
begin
  x1 := (utemp - bmp_ac6) * bmp_ac5 div 32768;

Funktioniert auf dem PC, weil der Compiler die Multiplikation uint16 x uint16 auf 32 oder 64 Bit erweitert. Funktioniert nicht auf dem µC, weil der Compiler da ohne weiteres Casting mit 16 Bit durchrechnet.

[Mathias]

Jetzt weis ich was du meinst, wen es auf jedes Byte ankommt, wie auf einem AVR, ist dies sicher ärgerlich.

[Warf]

Sicher?

Code: Alles auswählen

var
  utemp : uint16;
  bmp_ac5, bmp_ac6 : uint16;
  x1 : int16;
begin
  x1 := (utemp - bmp_ac6) * bmp_ac5 div 32768;

Funktioniert auf dem PC, weil der Compiler die Multiplikation uint16 x uint16 auf 32 oder 64 Bit erweitert. Funktioniert nicht auf dem µC, weil der Compiler da ohne weiteres Casting mit 16 Bit durchrechnet.

Das sagt ja nichts über die Typgröße aus, sondern nur über die Größe des Ergebnisses einer Multiplikation. Und das ein 32 Bit Multiplikationswerk ein 32 Bit Ergebnis auspuckt ist an sich zu erwarten. Es geht mir darum das der Typ Integer immer 32 Bit groß ist und nicht wie in C mal 16, 32 oder 64 Byte groß ist. Es gibt auch Spaßcompiler für C die genau diese sachen aufs korn nehmen und diese wagen stellen aufs ärgste ausreizen

[Timm Thaler]

Und das ein 32 Bit Multiplikationswerk ein 32 Bit Ergebnis auspuckt ist an sich zu erwarten.

Vorsicht. Hier gehen zwei 16-Bit-Werte in die Multiplikation, und es ist durchaus nicht selbstverständlich, dass der Compiler daraus eine 32-Bit-Multiplikation macht. Unter C macht er das nicht, und FPC auf dem µC macht es auch nicht. Das rechnet da mit 16 Bit durch, wenn man nicht explizit VORHER in 32 Bit wandelt.

Jetzt weis ich was du meinst, wen es auf jedes Byte ankommt, wie auf einem AVR, ist dies sicher ärgerlich.

Es geht weniger um die Speicherstellen, aber eine Longint-Multiplikation auf dem AVR dauert etwa 100mal länger als das Gleiche in 16 Bit. Bin ich gerade dran das mit dem Oszi auszumessen und zu optimieren.

[BeniBela]

Den Zähler kann man auch ganz weglassen, dann hat man keine Probleme damit:

Code: Alles auswählen

 
var line: string;
for line in Memo1.Lines do ...
 

[Socke]

Dann wird es aber schwierig auf die nächste bzw. vorherige Zeile zuzugreifen.
Im Quelltext wird das getan; da fehlt nur die Prüfung, ob die nächste Zeile tatsächlich existiert.

[mschnell]

Ich habe mir meine eigenen Datentypen gemacht, sicherlich nicht jedermanns Geschmack, aber ich kann meinen Code dadurch wesentlich besser lesen und dokumentieren.

Dann nimm doch wenigstens die Namnen, die im Linux source code verwendet werden:
uint8_t, uint16_t, uint32_t, uint64_t, int8_t, int16_t, int32_t, int64_t, ...
-Michael

[Mathias]

Dann nimm doch wenigstens die Namnen, die im Linux source code verwendet werden:
uint8_t, uint16_t, uint32_t, uint64_t, int8_t, int16_t, int32_t, int64_t, ...

Wieso so kompliziert, FPC hat dies schon fertig, wie oben schon beschrieben.

[Andrewi]

Hallo zusammen!

Vielen Dank für eure Hilfe.
Shortint in Integer geändert --> alls läuft!
Habe den Rest der Diskusion mit Interesse gelesen und hoffe, daß ich mal wieder etwas in diesem Forum gelernt habe.

André