STM32: if-Bedingung irrelevant und enthaltener Code wird ausgeführt

[Johannes (menschenskind)]

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

[Niklas G. (erlkoenig)]

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).

[EAF (Gast)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.

[Johannes (menschenskind)]

Hi Niklas,
Danke für den Hinweis. Habe es angepasst.

[Niklas G. (erlkoenig)]

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.

[Wilhelm M. (wimalopaan)]

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.

[Johannes (menschenskind)]

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.

[Niklas G. (erlkoenig)]

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.

[natural sinner (Gast)]

Ich sinniere zu später Stunde darüber wie beschränkt der
eigene Horizont sein muss um Sourcecode als Bild zu liefern.

[Jester (Gast)]

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]"

[Wilhelm M. (wimalopaan)]

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.

[Johannes (menschenskind)]

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!

[Johannes (menschenskind)]

Noch ne kleine Nachinformation:

Ich habe die if-Bedingung dann so geschachtelt:

  if( hw.semaExtendedPress->get_And_Reset_If_Larger(10) ){
    if( this->flag_extendedPress == true ){
.
.

Das macht den Code etwas besser lesbar und beseitigte auch das initiale 
Problem.