Hallo,
Ich habe auf meiner Hardware einen Taster, den ich entprellen will und
komme hier bei einem seltsamen Verhalten in einer Funktion nicht weiter.
Der Debugger geht immer in die if-Bedingung rein und erzeugt dort auch
keinen Haltepunkt.
Wenn ich die Bedingung mit einem anderen Inhalt wie dem printf befülle,
gibt es keine Probleme.
"this" ist eine Taster-Klasse der eine Hardware-Klasseninstanz übergeben
wird.
Wisst ihr, was ich tun könnte, um das Problem tiefer zu verstehen?
Danke
Hannes
Dir ist bewusst dass das "static" dafür sorgt dass die Anweisung in
Zeile 72 nur genau 1x ausgeführt wird, um die Variable zu
initialisieren? Wenn state dann auf false initialisiert wird, bleibt es
das auf ewig, und auch über alle Instanzen deiner Klasse hinweg (außer
du änderst es später noch explizit).
Johannes H. schrieb:> Der Debugger geht immer in die if-Bedingung rein und erzeugt dort auch> keinen Haltepunkt.
Damit ist relativ klar, dass der Compiler die Bedingung als dauerhaft
true (oder false) erkennt, und darum die Auswertung selber weg
optimiert. Was natürlich dann ein Breakpoint setzen unmöglich macht.
Johannes H. schrieb:> Wisst ihr, was ich tun könnte, um das Problem tiefer zu verstehen?
Wenn ich der Compiler wäre, würde ich ebenfalls die beiden
if(state)-Abfragen zu einer zusammenfassen, wodurch natürlich die zweite
Abfrage "verloren" geht.
> Der Debugger geht immer in die if-Bedingung rein
Ist state tatsächlich auch mal 0?
> Wenn ich die Bedingung mit einem anderen Inhalt wie dem printf befülle,> gibt es keine Probleme.
Zeig doch mal an 2 Beispielen wie dieser Satz gemeint ist.
Welchen Sinn hat es, state als "static" zu markieren, wenn du es sowieso
sofort überschreibst? Wenn Multithreading im Spiel ist, gibt es
Race-Conditions wenn mehrere Instanzen auf mehreren Threads diese
Funktion ausführen.
Johannes H. schrieb:> isst ihr, was ich tun könnte, um das Problem tiefer zu verstehen?
Refaktoriere die static-local Variable zu einem non-static Element der
Klasse.
Zudem werden static-locals mit guards ausgestattet, um das
Initialisieren thread-safe zu machen.
Danke, dass ihr so zahlreich antwortet.
Also ich bin eher noch Programmieranfänger, deswegen kann ich mit "Race
Conditions", "guards" und "thread safe" leider (noch) nichts anfangen.
Ich habe das static gesetzt, damit state beim Aufrufen der Funktion
nicht jedes Mal neu initialisiert werden muss. Ich dachte, das ist für
die Performance besser bzw. hat zumindest keine Nachteile.
"state" habe ich nur mal testweise erstellt, damit mir das im
Watch-Fenster gleich angezeigt wird. Die eigentliche if-Bedingung ist
die auskommentierte mit der &&-Verknüpfung.
@Lothar
Ja, "state" ist die ganze Zeit 0.
Ich meinte, dass der Haltepunkt für die if-Bedinung erzeugt wird, in der
nur das printf enthalten ist. Für das andere if wird der aber nicht
generiert.
Nee, da wird nichts zusammengefasst, der Debugger geht ja bei state == 0
auch nicht zum printf, aber danach dann in die andere if-Abfrage rein.
Johannes H. schrieb:> Ich habe das static gesetzt, damit state beim Aufrufen der Funktion> nicht jedes Mal neu initialisiert werden muss. Ich dachte, das ist für> die Performance besser bzw. hat zumindest keine Nachteile.
"state" klingt so nach aktuellem Zustand, aber ein Zustand der sich nie
ändert klingt irgendwie verkehrt.
Johannes H. schrieb:> Ich meinte, dass der Haltepunkt für die if-Bedinung erzeugt wird, in der> nur das printf enthalten ist. Für das andere if wird der aber nicht> generiert
Breakpoints werden nicht erzeugt oder generiert, die setzt man
manuell... Der Debugger folgt auch oft nicht dem Verlauf im Code. Der
Compiler zerwürfelt und die Zeilen und sortiert sie um, sodass die
Abfolge im Debugger nicht immer so erscheint wie das Programm sie
tatsächlich ausführt. Das Programm kann aber durchaus trotzdem
funktionieren... Bei solchen Details hilft es auch den Assembler-Code
anzuschauen.
Johannes H. schrieb:> Ich habe das static gesetzt, damit state beim Aufrufen der Funktion> nicht jedes Mal neu initialisiert werden muss. Ich dachte, das ist für> die Performance besser bzw. hat zumindest keine Nachteile.https://www.oreilly.com/library/view/c-coding-standards/0321113586/ch09.html
"Premature optimization is as addictive as it is unproductive. The first
rule of optimization is: Don’t do it. The second rule of optimization
(for experts only) is: Don’t do it yet. [...]
As [Stroustrup00] §6’s introduction quotes so deliciously:
Premature optimization is the root of all evil. —Donald Knuth [quoting
Hoare]"
Johannes H. schrieb:> Also ich bin eher noch Programmieranfänger, deswegen kann ich mit "Race> Conditions", "guards" und "thread safe" leider (noch) nichts anfangen.>> Ich habe das static gesetzt, damit state beim Aufrufen der Funktion> nicht jedes Mal neu initialisiert werden muss. Ich dachte, das ist für> die Performance besser bzw. hat zumindest keine Nachteile.
Als Anfänger sollte man sich erstmal gar keine Gedanken um irgendeine
Mikro-Optimierung (bzw. Optimierung generell) machen: das ist Aufgabe
des Compilers und die machen ihren Job ausgesprochen gut.
"local statics" in einer Funktion (freie Funktion wie auch
Elementfunktion) einzusetzen, führt dazu, dass die freie Funktion keine
"echte" Funktion mehr ist, sondern einen inneren Zustand hat. Dies
bringt ggf. Probleme mit sich, die für Anfänger schwer einzuschätzen
sind (wie z.B. Wiedereintrittsfähigkeit zu erreichen). Elementfunktionen
sollten ausschließlich den Objektzustand manipulieren / beobachten.
Niklas G. schrieb:> Breakpoints werden nicht erzeugt oder generiert, die setzt man> manuell...
Ja, korrekt. Also ich meinte bei meiner IDE diese kleinen blauen Pfeile.
Nur an diesen möglichen Stoppmarkern kann man die Breakpoints setzen
natural sinner schrieb:> Ich sinniere zu später Stunde darüber wie beschränkt der> eigene Horizont sein muss um Sourcecode als Bild zu liefern.
Und wie beschränkt muss dein Horizont sein, um erstens so eine dümmliche
Antwort zu geben und zweitens nicht zu verstehen, dass in dem Screenshot
mit Pfeilen auf etwas hingewiesen wird, hm? Troll woanders!
if-Diskrepanz.png
(17 KB)
