For-Schleife bricht unerwartet ab

[Andrewi]

Hallo zusammen!

In einem Projekt lese ich in einer For-Schleife die Inhalt eines Memos zilenweise ein und werte die Zeilen nach bestimmten Kriterien aus. Das hat auch bis vor kurzem sauber funktionert. Jetzt ist es so, daß die Schleife immer nach dem 42ten Durchlauf abbricht. Sie wird nicht irgendwo im Code verlassen, sondern der Zähler wird einfach nicht erhöht. Eine zur Kontrolle eigesetzte MessageBox zeigt an, daß die Schleife nach 42 von 1578 Zeilen beendet wurde. Wie bereits gesagt, der Code lief bisher fehlerfrei und wurde auch nicht verändert. Hat jemand eine Idee, wo das Problem liegt?

Lazarus: 1.6.4
FPC: 3.0.2
Win 10 x64

Mfg André

[Linkat]

ohne Code kann dir wohl niemand helfen!

[mschnell]

"Rauswerfen" in einer For-Schleife geht vermutlich nicht, weil nach dem Rauswerfen sich die Datensätze verschoben haben.

-Michael

[MacWomble]

... wenn jetzt meine Glaskugel nicht in Reparatur wäre, würde ich dir helfen

[Andrewi]

Hallo!

Noch einmal zum Verständnis. Das Programm ist bis vor ein paar Tagen sauber gelaufen und hat das getan, was es soll. Es wurde dann eine weitere Prozedur dem Programm hinzugefügt, die jedoch nichts mit dem betroffenen Programmteil zu tun hat und weder wird aus der neuen Prozedeur zugegriffen noch greift der alte Code auf den neuen zu. Das Problem ist, daß die Schleife bis 42 und dann nicht eben nicht mit 43 weitermacht, sondern die Schleife bendet wird. posting.php?mode=reply&f=10&t=11440&sid=1b68b51cf633cbcd031932f73f134a5c#

[relocate]

Das

der Code lief bisher fehlerfrei und wurde auch nicht verändert.

widerspricht dem:

Es wurde dann eine weitere Prozedur dem Programm hinzugefügt, die jedoch nichts mit dem betroffenen Programmteil zu tun hat und weder wird aus der neuen Prozedeur zugegriffen noch greift der alte Code auf den neuen zu.

Es wurde ja doch etwas verändert. Wie soll jemand nun aus der Ferne, allein auf Grund der Beschreibung die hier zu finden ist, erraten (und etwas anderes wäre es nicht), was schief läuft. Aber gut raten wir...

Ändert der neue Code das Memo?
Wurde der Inhalt des Memo (woher auch immer der kommt) geändert.
Wird ggf. eine globale Variable genutzt die auch von dem Code genutzt wird, welches das Memo ausliest.
Hat der Rechner den Anhalter durch die Galaxis gelesen und meint nun er sei Deep Thought (ist nicht ernst gemeint, aber genauso hilfreich)
...
aber raten kannst Du auch.

[theo]

@andrewi: Wenn du den Code nicht zeigst, kann dir keiner helfen. (Das war auch schon die erste Antwort von Linkat).
Es gibt keine allgemeine, logische Erklärung für etwas, was der Beschreibung nach nicht sein kann.
Selbst wenn du auf einen Compiler Fehler gestoßen sein solltest (in diesem Bereich extrem unwahrscheinlich), kann man ohne Code nichts sagen.

[Andrewi]

Hallo zusammen!

Zunächst einmal Danke für eure Hinweise.
Ich hatte war der Meinung, daß ich den Code bereits beim letzten Posting angehängt hätte. War wohl nichts.
Deshalb jetzt der 2. Versuch.

Code: Alles auswählen

 
procedure TForm1.BitBtn1Click(Sender: TObject);
var
  i: ShortInt;
  buses,
  bvar: boolean;
begin
  Memo2.Lines.Clear;
  buses := FALSE;
  bvar := FALSE;
  for i := 0 to Memo1.Lines.Count-1 do   {..Count = 1578 # hier bricht die Schleife nach nach 42 Durchläufen ab}  
    begin
    if pos('uses', Memo1.Lines[i]) <> 0 then
      buses := TRUE;
    if buses and not (Memo1.Lines[i] = '') then
      begin
      Memo2.Lines.Add(Copy(Memo1.Lines[i],0,Length(Memo1.Lines[i])));
      if pos(';',Memo1.Lines[i]) <> 0 then
        begin
        buses := FALSE;
        Memo2.Lines.Add('');
        end;
      end;
    if (pos('var', Memo1.Lines[i]) <> 0) and (Length(Memo1.Lines[i]) = 3)then
      bvar := TRUE;
    if bvar and not (Memo1.Lines[i] = '') then
       begin
       Memo2.Lines.Add(Copy(Memo1.Lines[i],0,Length(Memo1.Lines[i])));
       if (pos(';',Memo1.Lines[i]) <> 0) and ((Memo1.Lines[i+1] = '') or (Memo1.Lines[i+1] = 'begin')) then
          bvar := FALSE;
       end;
    if pos('* ',Memo1.Lines[i]) = 1 then
      begin
      Memo2.Lines.Add(Copy(Memo1.Lines[i],Pos('* ',Memo1.Lines[i])+2,(Length(Memo1.Lines[i]))-Pos('* ',Memo1.Lines[i])));
      end
    else
      begin
      if (pos('**',Memo1.Lines[i]) <> 0) and (i <> 0) then
        begin
        Memo2.Lines.Add('');
        end;
      end;
    end;
  ShowMessage(IntToStr(i) + ' von ' + IntToStr(Memo1.Lines.Count-1)); {Meldung: 42 von 1578}
  ShowMessage('Fertig');
end;
 

Ich habe inzwischen noch ein bischen experimentiert. Dabei habe ich festgestellt, daß die Schleife auch bei dem folgenden Code nie bis zum Schluß durchlaufen wird. Teilweise wird der gar nicht ausgeführt.
Verwendet wurden verschiedene *.pas und *.txt Dateien. Auch ein neues kleines Projekt mit ausschießlich dem folgenden Code bringt die selben Ergebnisse. Der Text wurde fest in das Memo eingebunden.

Code: Alles auswählen

 
procedure TForm1.Button1Click(Sender: TObject);
var
  i: Shortint;
begin
  for i := 0 to Memo1.Lines.Count-1 do
    begin
    ShowMessage(IntToStr(Memo1.Lines.Count-1));
    if i = Memo1.Lines.Count-1 then
      ShowMessage(IntToStr(i) + ' von ' + IntToStr(Memo1.Lines.Count-1));
    end;
end;  
 

Was mich am meisten irritiert, ist die Tatsache, daß der Code lange Zeit einwandfrei funktioniert hat. Die Dateien wurden sauber abgearbeit. Überschneidende globale Variablen kann ich ausschließen, da Form1 die einzige ist.
An einen Fehler im Compiler oder bei Lazarus glaube ich nicht. Ich habe eher das Gefühl, daß das Problem auf meinem Rechner ist. Da ich z.Zt. unterwegs bin kann ich Lazarus momentan nicht neu aufsetzen. Vielleicht hat sich Lazarus oder der Compiler aus welchen Gründen auch immer "verschluckt".

Grüße und Danke an alle
André

[wp_xyz]

Warum machst du denn i zu einem ShortInt? Der kann doch nur bis 127. Mache mal übungshalber Range-Checking an (Projekt-Optionen > Debugging > Range)...

[siro]

Dein Wert 1578 dezimal ist in Hex = 0x62A
davon bleibt beim wandeln in ein Byte (siehe wp_xyz) wegen dem Shortint nur noch 2A übrig.
und 2A Hex sind genau deine 42

Wenn das tatsächlich mal funktioniert hat, dann stand da evtl. irgendwo folgende Zeile, dann geht es nämlich wieder...

Type ShortInt = Integer;

Siro

[Mathias]

Was ich mir angewöhnt habe, wen es wichtig ist, wie ein Integer aussieht, dann deklariere ich mit int8, uint8, int16, uint16, etc.
Früher war der gewöhnliche Integer mal 16Bit, heute ist er 32Bit, wer weis, in Zukunft könnte er sogar mal 64Bit werden.

[wp_xyz]

Wenn das tatsächlich mal funktioniert hat, dann stand da evtl. irgendwo folgende Zeile, dann geht es nämlich wieder...

Type ShortInt = Integer;

Hoffentlich versteht Andrewi das jetzt nicht so, dass er so eine Schweinerei in seinen Source-Code schreiben soll.

Generell: Für Wald-und-Wiesen-Integer (Zähler, Laufvariablen, Koordinaten) nehme ich fast immer nur den Datentyp "Integer". Optimierungen der Byte-Größe bringen wegen des Alignment gar nichts, und die Verwendung von vorzeichenlosen Typen (word, etc) - "weil der Wert ja nicht kleiner als 0 sein KANN" - fliegt einem im Debug-Modus um die Ohren, weil man einen Fehlerwert als -1 codiert hat (weil man die vorzeichenlose Deklaration dann nämlich vergessen hat).

[Timm Thaler]

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.

[siro]

Hoffentlich versteht Andrewi das jetzt nicht so, dass er so eine Schweinerei in seinen Source-Code schreiben soll.

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.

Code: Alles auswählen

 
Type U8   = Byte;      { unsigned  8 Bit }
Type S8   = ShortInt;  { signed    8 Bit }
Type U16  = Word;      { unsigned 16 Bit }
Type S16  = SmallInt;  { signed   16 Bit }
Type U32  = LongWord;  { unsigned 32 Bit }
Type S32  = LongInt;   { signed   32 Bit }
Type U64  = QWord;     { unsigned 64 Bit }
Type S64  = Int64;     { signed   64 Bit }
Type F32  = Single;    { Floatingpoint 32 Bit }
Type F64  = Double;    { Floatingpoint 64 Bit }
Type BOOL = Boolean;
 

[m.fuchs]

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

Senkt aber die Lesbarkeit für andere.