dunkelgrüner Breakpoint ?

[EccoBravo]

Neue Dummi-Frage:

Wundere mich, daß beim debuggen Programm am Haltepunkt nicht unterbrochen wird (obwohl es müßte).
Nun Beobachtung: In einigen Codestellen ist der Haltepunkt beim Setzen nicht rot sondern dunkelgrün. Oder ein gesetzter roter Haltepunkt wird beim Compilieren dunkelgrün. Das Programm hält dann an diesen Punkten nicht an. Was hat das auf sich?
(BD7 Enterprise)

Vielen Dank

E. B.

[Treffnix]

grün bedeutet, dass das Programm an dieser Zeile niemals nicht vorbeilaufen wird. In der Regel, weil du die Funktion nirgends benutzt oder weil du ne Zeile ausgewählt hast, in der kein Befehl steht. Evtl. wurds auch wegoptimiert.

Wenn du z.B. bei

Delphi-Quellcode:

showmessage( 'Ich wollte nur mal Hallo sagen: '#13#10 +
             'Hallo' );

den Breakpoint auf die zweite Zeile setzen würdest, würde er dort auch nicht anhalten

[Mattin]

Zitat:

Zitat von EccoBravo

Neue Dummi-Frage:

Wundere mich, daß beim debuggen Programm am Haltepunkt nicht unterbrochen wird (obwohl es müßte).
Nun Beobachtung: In einigen Codestellen ist der Haltepunkt beim Setzen nicht rot sondern dunkelgrün. Oder ein gesetzter roter Haltepunkt wird beim Compilieren dunkelgrün. Das Programm hält dann an diesen Punkten nicht an. Was hat das auf sich?
(BD7 Enterprise)
E. B.

Steht der Breakpoint vielleicht auf einer Abfrage IF/ WHILE / FOR oder so ??

[jim_raynor]

Das bedeutet, dass an dieser Stelle kein Ausführbarer Code ist. Zu erkennen an dem kleinen blauen Punkt beim Starten in Delphi.

An diesen Stellen kann dann auch nicht angehalten werden, da dort kein ausführbarer Code ist. Eine Ursache kann zum Beispiel der Optimierer sein, der Teile des Codes wegoptimiert hat, weil diese einfach nicht benötigt werden oder ganze Prozeduren überhaupt nicht verwendet werden.

Falls das "Problem" in einer ganzen Unit auftritt, liegt es meistens an fehlerhaften Verzeichnissen.

[EccoBravo]

Vorgestellt habe ich mir das mit dem ausführbaren Code auch so,
aber so ganz glaube ich das nicht, denn die blauen Punkte stehen nicht vor Kommentarzeilen, und END-Zeilen. Dafür stehen sie ganz willkürlich innerhalb von BEGIN...END-Bereichen (mal ja mal nicht) vor ausführbaren Zeilen.
Und dann noch
färben sich beim Kompilieren auch mal die Haltepunkte der nicht blau punkteten Zeilen dunkelgrün und die Haltepunkte der Blau bepunkteten Zeilen bleiben rot. Also alles ziemlich unregelmäßig. Anhalten tut der Debugger in diesen Fällen nie, obgleich er müßte.

So und nun zum Optimizer,
Gehört habe ich auch schon so etwas, Mein Eindruck ist, daß dieser Optimizer ganze Quelltextpassagen einfach weggelassen hat. Ich hatte schon früher so etwas beobachtet, mich geärgert/ gewundert. Ohne diesen Optimizer zu verstehen habe ich mir geholfen, indem ich ganze Kode-Passagen umgestellt hatte, retundante Bedingungen programmiert habe usw. Zufrieden bin ich damit aber überhaupt nicht! Die Transparenz der Programme geht damit unweigerlich verloren.
Nun, kann mir jemand verraten, wie ich auf das Verhalten des Optimizers Einfluß nehmen kann?
Ich will den Kram endlich begreifen.

Am Rande sei mir wegen meiner gehäuft dummen Fragen verziehen. Als Autodidakt bin ich halt immer noch ein Amateur, obgleich ich auf 20-jährige, teils recht pragmatische Erfahrungen zurückblicken kann.
Ursprünglich als neue Dummie-Frage tituliert, sei diese Frage ernst.

Vielen Dank, E. B.

[Treffnix]

Menü Projekt -> Optionen -> Häkchen bei Optimierung weg

Bevor du dann die endgültige Programmversion compilierst, wenn alle Fehler beseitigt sind, solltest du den Haken aber wieder setzen.

*edit*
Wäre vielleicht ganz hilfreich, wenn du mal ein paar Zeilen Beispielcode posten würdest, wo ein Breakpoint nicht funktioniert, obwohl er es deiner Meinung nach müsste.

[EccoBravo]

Na klar:

Delphi-Quellcode:

...
if <bedingung 1> then 
              begin
                  <anweisung 1a>
                  <anweisung 1b>
              end
else if <bedingung 2> then  
              begin
                  <anweisung 2a>
                  <anweisung 2b>
              end
...
etwa 50 x ( else if <bedingungn> )
...
else if <bedingung n+1> then  
              begin
                  <anweisung n+1a>    // ab hier finktionieren die Braekpoints nicht mehr
                  <anweisung n+1b>
              end
else if <bedingung n+2> then  
              begin
                  <anweisung n+2a>
                  <anweisung n+2b>
              end
...
else if <bedingung n+m> then         // n+m = ca.100
              begin
                  <anweisung n+ma>
                  <anweisung n+mb>
              end

else begin
     end;

...

Egal was sich dahinter verbirgt, alle Anweisungen müßten potentiell erreichbar sein, also die Breakpoints rot bleiben.
Ob sie dann zur Laufzeit auch immer erreicht werden ist eine andere Sache.

Bei mir ist es verrückter weise so, daß eine <anweisung..a> blaubepunktet und die <anweisung..b> im gleichen BEGIN..END Bereich unbepunktet ist bzw. umgekehrt.
Oder, innerhalb eines BEGIN..END Bereiches bleibt eine <anweisung..>-zeile rot und die andere dunkelgrün.
Entweder beide rot oder beide grün, so sehe ich das.

Das wäre meine aktuelle Problemstelle,

Vielen Dank, wenn Du / Ihr etwas dazu wißt

E. B.

[Treffnix]

Bei so einem Konstrukt wird das vermutlich an der Optimierung liegen. Übrigens: Optimierung bedeutet nicht, dass er das auch wirklich löscht. Es wird nur zu einem günstigeren Konstrukt umgestellt und ist deshalb oft nicht mehr debugbar, da es in deinem Quelltext keine echte Entsprechung des Maschinencodes mehr gibt, auf die der Debugger verweisen könnte. Haste das ganze mal mit abgeschalteter Optimierung versucht?

[Oxmyx]

Zeig mal ein konkretes Quellcode-Beispiel, das bei dir nicht wie erhofft funktioniert. An deinem Pseudocode kann man so etwas nicht unbedingt erkennen.

[chris_k]

Es wird nicht nur Code wegoptimiert der nicht erreichbar ist, sondern auch überflüssiger Code. Zur Verdeutlichung mal das folgende (zugegebenermaßen recht sinnlose) Beispiel:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var a,b:integer;
begin
  a:=1;
  b:=2;
  showmessage('a='+IntToStr(a));
end;

Die Zeile b:=2; ist nicht notwendig da b nie verwendet wird, deshalb wird sie wegoptimiert.