Compiler Fehler ?!

gerd33 · Beiträge: 21

Hallo,

ich glaube ich habe einen Compiler Fehler entdeckt. Zumindest kann ich mir nicht erklären, wie ein boolean Ausdruck im_schach true ist.
Kann ich zum besseren Verständnis den ganzen Code hier senden? Ist nur eine Unit. Wie kann ich diese Datei hier uploaden?
Oder wer hat Interesse, dann schicke ich es zu?

Verdammt heute den ganzen Sonntag nur damit verbracht, wieso im_schach true ist. Obwohl ich es vorher immer false setze.

Gerd

Moderiert von Narses: Topic aus Algorithmen, Optimierung und Assembler verschoben am So 24.05.2020 um 22:24
Moderiert von Th69: Delphi-Tags hinzugefügt

Gausi · Verfasst: So 24.05.20 22:24

Hallo und

in der Entwickler-Ecke!

Im Beitragseditor gibt es unten rechts einen Link "Dateianhang hinzufügen". Darüber solltest du deine Unit anhängen können.

Vielleicht helfen aber auch schon Ausschnitte aus der Datei.

So ins Blaue geraten: man vergleicht ja nicht per if im_schach = True then, sondern durch if im_schach then. In der ersten Variante können schon mal Nebeneffekte auftreten. Oder es gibt ein Problem mit globalen und lokalen Variablen ...

_________________
We are, we were and will not be.

Narses · Verfasst: So 24.05.20 22:26

...oder eine Bereichsüberschreitung (und Speicher wird ungewollt überschrieben)... :nixweiss:

_________________
There are 10 types of people - those who understand binary and those who don´t.

gerd33 · Beiträge: 21

Frage:

markieren

Delphi-Quelltext

1:
2:

// Merkwuerdig, darf normalerweise niemals im_schach true sein.
if im_schach then memo2.lines.add('im schach'+inttostr(k1));

Das dürfte er meiner Meinung niemals ausgeben. Warum macht er das.

Gerd

Einloggen, um Attachments anzusehen!

LorenzS · Beiträge: 128 MS-DOS, WIN 7, WIN 10 BP7.0, D3, D5

Hallo,

vielleicht hilft es die Variable in der Procedere TForm1.loesen mal mit false zu initialisieren.
Ansonsten ist ein Zufälliger werte aus dem Speicher genommen, der je nach Kompilation auch ändern kann.

gerd33 · Beiträge: 21

Ich sage vor jedem Turm Aufruf:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:

im_schach:=false;
for v:=1 to 10 do begin
  if wT[v]<>0 then begin
    im_schach:=false;
    //
    turm(true,bitschau1(wT[v]),v,4,true,bitschau1(sK));
    if im_schach then begin
      im_schach:=false;
      weiter1:=false;
    end;
  end;
end;

Vor jedem turm() Aufruf setze ich die globale Variable schach:=false;
Keinem Zufall überlassen.

Gerd

Moderiert von Th69: Delphi-Tags hinzugefügt

gerd33 · Beiträge: 21

Ich bin mir nicht ganz sicher, aber ich habe einen grossen Verdacht:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

begin
  //horizontal
  u_magic:=71213169107795968;
  turm2bis7(48,50,51,52,53,54,55,49,51,52,53,54,55,56,50,2);

  //vertikal
  u_magic:=144117395722732034;
  turm2bis7(1,9,17,25,33,41,57,2,10,18,26,34,42,58,50,7);
end;

Der fuehrt das ja 2-fach aus. Ich glaube daran liegt es. Das kann man natuerlich ganz einfach beheben, indem man ganz oben das im_schach:=false setzt.
Ich muss nochmal eine Nacht darüber schlafen.

Gerd

Moderiert von Th69: Delphi-Tags hinzugefügt

jaenicke · Verfasst: So 24.05.20 23:56

Das ist das Problem mit globalen Variablen:
Man hat nicht den Überblick warum diese wo gesetzt werden.

Um das Logikproblem zu finden musst du doch nur einen Haltepunkt auf die einzige Zeile setzen, in der die Variable auf True gesetzt wird. Sobald du dort ankommst, kannst du doch anschauen wo das Problem liegt.

Gausi · Verfasst: Mo 25.05.20 09:55

Der Code ist mal wirklich verworren. :shock:

Die Variable im_schach ist in TForm1.loesen deklariert, die satte 1500 Zeilen Code enthält. Darin enthalten sind (mindestens) zwei Ebenen von verschachtelten Prozeduren, wobei z.B. turmtest (eingebettet in der in loesen eingebetteten Prozedur turm) wieder die Eltern-Prozedur aufruft ...

Ich fürchte, da kommst du mittelfristig nicht um ein komplettes Redesign herum. Wo genau die Variable ungewollt gesetzt wird, ist ohne Debugger absolut undurchschaubar für mich.

_________________
We are, we were and will not be.

gerd33 · Beiträge: 21

Ich habe jetzt den source code geändert.
Und es funktioniert einwandfrei, so wie ich mir das jetzt vorstelle.
Ich kann das nachvollziehen, dass alles verworren ist.
Den Selbstaufruf der procedure turm(... probe) wird jedenfalls nicht ganz ausfuehrt , sondern nur die Probe.
Damit spare ich mir nochmal eine procedure mit allen 64 Feldern zu schreiben.
Das ist mit den Türmen nicht ganz leicht zu verstehen, das gebe ich zu. Ist aber soweit mir bekannt die schnellste Art mit dem Zuggenerator, die
Türme werden im Look-up nach min max (bessere waere hier links und rechts) abgefragt.
(Und dass ich nicht der beste Programmierer bin, habe ich auch nie behauptet)

Gerd

Gausi · Verfasst: Mo 25.05.20 15:21

gerd33 hat folgendes geschrieben :

Das ist mit den Türmen nicht ganz leicht zu verstehen, das gebe ich zu. Ist aber soweit mir bekannt die schnellste Art mit dem Zuggenerator, die Türme werden im Look-up nach min max (bessere waere hier links und rechts) abgefragt.

Ja, dass da irgendein "bekannter" Algorithmus abläuft, habe ich mir schon gedacht. Wenn so viele "Magic Numbers" irgendwo auftauchen, steckt meistens etwas mehr dahinter als "Ich bastel mir da mal was zusammen". :think:

Ist halt nur so, dass bei einigen Diskussionen zu "Wie lang darf eine Prozedur sein" gelegentlich Aussagen kommen wie "maximal eine Bildschirmseite". Dieses Extrem ist sicher nicht immer einzuhalten, aber so ein "Monster" wie das hier steht dann auf der anderen Seite der Extrembeispiele.

Ob man das sinnvoll in eine Klassenstruktur umändern kann, mit einigen privaten Prozeduren/Funktionen/Variablen etc. kann ich auf Anhieb auch nicht überblicken. Kann auch sein, dass man dann so viel Overhead rein bekommt, dass der Vorteil des Verfahrens auch wieder flöten geht ...

Wenn es jetzt läuft, ist ja erstmal alles in Ordnung. :zustimm:

_________________
We are, we were and will not be.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme