Hallo Programmierfreunde!

Zur Zeit quäle ich mich wieder durch einen C(++)-Quelltext, um diesen nach Pascal zu portieren.

Konkret geht es um die Zeile:



(alle vier Variablen sind vom Typ "int").

Bisher war das für mich eine Kurzschreibweise für:



doch so einfach scheint es nicht zu sein.

Die (beispielhaften, im Programmverlauf ggf. auch andere) Werte betragen vor der Ausführung:
cbuf: 0
havebuf: 1
lblocks: 256
nkeys: 79

bei if (havebuf) wird diese Integervariable als boolean interpretiert. Egal, irgeneinen der beiden Werte - den von lblocks oder den von nkeys - muß (müßte) cbuf doch nach der Ausführung haben?! Tatsächlich sind jedoch alle Variablenwerte nach der Ausführung dieses Bedingungsoperators gleich(geblieben).

Wie ist das zu erklären, bzw. wie lautet die "lange Schreibweise" korrekt oder gar Pascal-Übersetzung (die bekomme ich natürlich selbst noch hin)?

Vielen Dank und Gruß

Delphi-Laie

Hey,



Da würde ich jetzt eigentlich einen Syntax Error erwarten. Vor dem else darf kein ; stehen.

MfG Bergmann

Bergmann89 hat folgendes geschrieben :

Hey, markieren Delphi-Quelltext     1: 2: 3: if (havebuf) then cbuf = lblock; else cbuf = nkeys; Da würde ich jetzt eigentlich einen Syntax Error erwarten. Vor dem else darf kein ; stehen.

Meinetwegen, ich übersetzte das ad hoc in die ausführliche Schreibweise, fügte diese jedoch nicht in den Quelltext ein.

Das hat aber mit meiner eigentlichen Fragestellung nichts zu tun.

Die Werte bleiben unverändert. Das kann ich, wenn es jemand nicht glaubt, auch mit Bildschirmkopien demonstrieren.

Kann es sein daß bei Dir infolge Optimierung gar kein Code für Dein Beispiel erzeugt wird?

Hi,

mich wundert das der Compiler das überhaupt durchgehen lässt. Die Delphi Versionen mit denen ich gearbeitet habe würden einen Boolean in der if-Bedingung erwarten, aber die sind zugegeben auch etwas älter.

Wenn ich es richtig in Erinnerung habe ist in C 0 == false und alles andere == true. Daher würde ich die Sache so formulieren:



Gruß

Danke für Eure Wortmeldungen!

Wegen allgemeiner (schon geahnter) Skepsis hier die beiden Bilschirmkopien (eigentlich Fensterkopien), einmal im Zustand vor und einmal im Zustand nach der Ausführung, als Anhang.

Ergänzung: Der Compiler ist der des Visualstudios 2008.

- Nachträglich durch die Entwickler-Ecke gelöscht -

Sicher das dein Code zum Binary passt? Wenn das in den Bilden wirklich ein Einzelschritt war, dann würde ich eigentlich erwartet, dass er auf dem if stehen bleibt und nicht im if-Block.

Bergmann89 hat folgendes geschrieben :

Sicher das dein Code zum Binary passt?

Mit dieser Frage kann ich leider kaum etwas anfangen. Ich habe Quelltext(e), zu einem compilierbaren Programm geformt. Man / ich kann mit oder ohne Debugging starten. Das Programm wird daraufhin ausgeführt. Wie sollte das Binary nicht zu diesem Quellcode "passen"?

Bergmann89 hat folgendes geschrieben :

Wenn das in den Bilden wirklich ein Einzelschritt war, dann würde ich eigentlich erwartet, dass er auf dem if stehen bleibt und nicht im if-Block.

Die Tücken dieses Compilers sind mir unbekannt. Soeben setzte ich noch einmal explizit einen Haltepunkt auf die if-Anweisung - es läßt sich dort einer setzen - doch das Programm weigert sich, an dieser Stelle die Ausführung zu unterbrechen, es geht danach an bekannter Stelle weiter. Offensichtlich ist die if-Bedingung aber erfüllt.

Wenn ich mir allerdings die Downloadzahl meiner Archivdatei mit den beiden Fensterkopien anschaue und die bisher allgemeine Ratlosigkeit, die das auslöste - kein Vorwurf, im Gegensatz, ich bin über jedes Hilfsbemühen dankbar! - so stelle ich fest, daß ich wohl doch die richtige Programmiersprache / Umgebung noch in den Frühzeiten des PCs wählte. An C & Co. gefällt mir zwar einiges, so die Möglichkeit, Code stärker zu komprimieren und auch die größere Flexibilität, dennoch ist mir dieses mysteriöse Rumgemache damit, das manchmal sogar unlösbare Rätsel hat und unüberwindliche Hürden aufstellt, bis heute suspekt bis antipathisch. Ich kann jeden Informatiker verstehen, der Algorithmen entweder im Pseudocode oder doch in einer daran angelehnten Programiersprache (Algol oder Wirth'sche Sprachen) veröffentlicht, nicht jedoch mit diesem C.

Bergmann98s Frage zielte wohl darauf ab, ob Du den Quelltext mal editiert aber dann nicht neu kompiliert / gebaut hast. Dann würdest Du eine Anwendung ausführen (und debuggen), die nicht mehr zum Quelltext passt.

Christian S. hat folgendes geschrieben :

Bergmann98s Frage zielte wohl darauf ab, ob Du den Quelltext mal editiert aber dann nicht neu kompiliert / gebaut hast. Dann würdest Du eine Anwendung ausführen (und debuggen), die nicht mehr zum Quelltext passt.

Nein, das tat ich natürlich mitnichten!

Hallo,

versuche doch mal



Andere Idee: Vielleicht optimiert der Compiler ja was weg und der Debugger sieht das nicht. Leg doch mal cbuf global an, so dass cbuf auf jeden Fall beschrieben werden muss. Zur Sicherheit würde ich an anderer Stelle im Programm noch irgendeine belanglose Sache mit cbuf machen.

Noch eine Idee: Ich hatte letztens in C in einer Schleife (bool x):


Eine Weile wurde immer abwechselnd macheA und macheB aufgerufen, wie geplant. Plötzlich bei jedem Durchlauf die gleiche Routine (weiß nicht mehr ob A oder B). Ursache: Ich hatte versehentlich x einmalig (!!) mit einem Zahlenwert überschrieben. Daher die Idee obern mit der robustren Abfrage havbuf==0.

Bin gespannt auf die Lösung,
Gruß
GuaAck

GuaAck hat folgendes geschrieben :

Andere Idee: Vielleicht optimiert der Compiler ja was weg

Das ist eine gute Idee. Mit derlei Tricks hatte ich auch schon mit diversen Delphi-Compilern meine liebe Not. So etwas kann einen, der das nicht weiß, fast zur Verzweiflung treiben, denn die Auskunftsfreude darob ist doch ziemlich defizitär.

GuaAck hat folgendes geschrieben :

und der Debugger sieht das nicht.

Dann stimmt die Kommunikation zwischen beiden nicht. In Delphi werden solche Zeilen dann wenigstens ignoriert - und, wie gesagt, wenn man den Grund dafür nicht weiß, sucht man sich nach der Ursache einen Wolf.

GuaAck hat folgendes geschrieben :

Bin gespannt auf die Lösung.

Ich im Prinzip auch, aber praktisch kaum, da es wahrscheinlich keine geben wird. Ich bin da pragmatisch: Was mich ärgert und seine Existenzberechtigung nicht nachweisen kann, wird weggeputzt. Sofern der (Sortier-)Algorithmus auch ohne fehlerfrei funktioniert - und hier scheint die Anweisung schon im Original keine erkennbaren Auswirkungen zu haben - sind derlei Codebstandteile faktisch / praktisch Redundanz und erleiden dann ihr verdientes Schicksal. Ewige Ursachenforschung ist hierbei nicht "mein Ding".

Es könnte auch sein, daß der Compiler die Zuweisumg an der Operator-Zeile wegoptimiert und erst bei den Aufrufen einsetzt. Gibt den Wert von cbuf doch mal in beiden Zweigen aus (dann müßte die Zuweisung vorher ausgeführt werden).

Wenn Du die Möglichkeit hast, beim Debuggen auch den erzeugten Maschinencode einzusehen mach davon ein Bild und setze es hier ein.
Dann läßt sich sehr wahrscheinlich mehr sagen.
Wie man es bei Deiner C-Umgebung macht kann ich Dir aber nicht sagen, vielleicht aber jemand anderes hier.´oder Du findest es auf die Schnelle.
Bei Delphi sagt man einfach nachdem ein Haltepunkt erreicht wurde "CPU-Fenster zeigen".

Gammatester hat folgendes geschrieben :

Es könnte auch sein, daß der Compiler die Zuweisumg an der Operator-Zeile wegoptimiert und erst bei den Aufrufen einsetzt. Gibt den Wert von cbuf doch mal in beiden Zweigen aus (dann müßte die Zuweisung vorher ausgeführt werden).

Guter Spürsinn, danke!

Yo, nun wird es richtig lustig. Nachdem ich die Bildschirmausgabe des int-Datentyps endlich hinbekam, zeigen sich zwei unterschiedliche Werte: Der im Debugger ist 0, ausgegeben wird jedoch der vermutlich korrekte Wert 256. Ich hoffe, daß es an der Bildschirmkopie (Anhang) erkennbar ist.

mandras hat folgendes geschrieben :

Wenn Du die Möglichkeit hast, beim Debuggen auch den erzeugten Maschinencode einzusehen mach davon ein Bild und setze es hier ein.

So gut kenne ich mich mit dem Visual Studio (2008) nicht aus. Debuggen -> Fenster -> Disassambly scheint passend zu sein, es zeigt jedenfalls Maschinencode bzw. Mnemonics, auch mit gelbem Haltepfeil. Doch ist das nicht etwas zuviel des Guten? Na gut, auf Wunsche eines einzelnen Forumsmitgliedes gern, siehe Anhang.

Man kann sich auf den Debuger im Visual Studio nicht verlassen, jedenfalls nicht im gleichen Maße wie auf den in Delphi. Das hat mir gammatesters Anregung, die ich umsetzte, eindeutig gezeigt. Werde ich demnächst zur Sicherheit eben den "händischen" Weg (bzw. den "zu Fuß") über Bildschirmausgaben wählen (müssen). Kein berauschendes Debuggingniveau.

> Doch ist das nicht etwas zuviel des Guten?

Jein. Es ging mir darum zu sehen ob der Fehler daran liegt, daß die Werte in Registern gehalten werden.
Dann hätte ich geraten, die Optimierungsstufe zu reduzieren.

Mit VS / C habe ich zu lange keine Erfahrungen mehr, ich kenne solche Fehler bei Delphi gerne bei folgender Situation:
Optimierung an, Debugging im Einzelschritt, Variablen werden aber nach der aktuellen Position gar nicht mehr verwendet -
da kommt der Debugger (ich weiß es sicher von D6 und D7) durcheinander. Ich sollte mal nachsehen ob die aktuellen
Versionen auch noch dieses Verhalten aufweisen.

Ah, der Compiler hat das IF weg optimiert, wenn havebuf ungleich 0 ist. Siehe Assembly Offset 0x0145. Da springt er direkt nach 0x0150 anstatt zu 0x014D (wo das IF steht). Aber um deine eigentliche Frage zu beantworten. Der äquivalente Pascal Code wäre (wie du schon gesagt hast)

Warum der Debugger da im VS jetzt so verrückt spielt sei ja erstmal dahin gestellt...

Bergmann89 hat folgendes geschrieben :

Warum der Debugger da im VS jetzt so verrückt spielt sei ja erstmal dahin gestellt...

Nun, das weiß ich natürlich erst recht nicht, und es interessiert mich auch nicht sonderlich, maximal dafür, das wegzubekommen. Aber dafür reichen meine Kenntnisse in und meine Experimentierlaune mit Visual Studio bei weitem nicht. Ich bin jedesmal froh, möglichst bald von C & Co. wieder wegzukommen, also ist meine Verweildauer in dessen Entwicklungsumgebungen nicht mehr als nötig.

Dank gammatester bin ich nun aber doch auf der richtigen Fährte. Hätte ich im Prinzip auch darauf kommen können, wenn mir denn in den Sinn gekommen wäre, es mit der "alternativen" Ausgabemöglichkeit zu versuchen. Diese benutze ich auch heute noch gelegentlich bei Delphi - kleine Showmessages oder Pieptöne wechselnder Frequenz zwischendrin - oder noch viel eher bei Lazarus / Freepascal, weil dessen Debugger doch noch nicht an Delphi heranreicht.

Nochmals Dank an alle!