Wird if Schleife ignoriert, wenn sie nie eintritt?

Natürlich gehts um Arduino, sonst würde ich nicht so dumme Fragen 
stellen und alte Kühe durchs Dorf treiben. Ihr seid wahrscheinlich 
gelangweilt von derart trivialen Fragestellungen. Allerdings konnte ich 
auf die schnelle keinen alten Thread auffinden, in dem diese Frage 
gestellt wurde.

Präprozessor-Direktiven sind das, was Du suchst (#define, #ifdef)

Sim J. schrieb:
> Natürlich gehts um Arduino, sonst würde ich nicht so dumme Fragen
> stellen und alte Kühe durchs Dorf treiben.

Ihm ging es nicht um die Arduino Frage, sondern um die erwähnte 
"if-schleife"

http://if-schleife.de

---
Ich würde dir auch Präprozessor-Direktiven empfehlen:

1

#define DEBUG

2

3

void loop()

4

{

5

   #ifdef DEBUG

6

   Serial.println("...");

7

   #endif

8

}

Dann wird es entweder mitcompiliert oder nicht.

Sim J. schrieb:
> Allerdings konnte ich
> auf die schnelle keinen alten Thread auffinden, in dem diese Frage
> gestellt wurde.

Das mag auch an der falschen Terminologie gelegen haben: 
http://if-schleife.de/

Danke für die Hinweise mit den Präprozessor direktiven.
Danke auch für den Hinweis mit der GROSSSCHREIBUNG. Das klingt sinnig 
für mich!

Sim J. schrieb:
> Ihr seid wahrscheinlich
> gelangweilt von derart trivialen Fragestellungen.

nö nur amüsiert die "if schleife"

Du wirst also schon einiges gelesen haben, leider auch FALSCHES, zeige 
wo es deine if schleife geben soll!

Es gibt Schleifen!
Es gibt If Abfragen!

If Schleifen gibt es nicht!!!!! merken 1000x aufschreiben.

Sim J. schrieb:
> Hallo,
> angenommen ich möchte für Debugzwecke in einer Interruptroutine ein Flag
> setzen

tu das
volatile boolean merker=false;
IRQ merker = true;
if merker == true machwas();

Joachim B. schrieb:
> If Schleifen gibt es nicht!!!!! merken 1000x aufschreiben.

Nunja :-D

Ich hatte das mal in C umgeschrieben, aber wie gesagt, BITTE NICHT SO 
MACHEN!

http://blog.ebene7.com/2010/01/15/und-es-gibt-sie-doch-if-schleifen-so-wird-es-nicht-gemacht/

Hoffe ihr steinigt mich jetzt nicht.

Frank schrieb:
> Auch das ist keine Schleife, sondern eine Abfrage auf die ein
> Sprungbefehl folgt.

Ja...hast recht! Fands nur amüsant.

Um das auch mal zu beantworten:

Sim J. schrieb:
> Wird die if Schleife im folgenden Fall vom Compiler ignoriert, sodass
> diese gar nicht erst in den Speicher des µC geladen wird (da debug =
> false)?

> Ein anderer Fall. Wenn ich debug = true setze, trifft die if Anweisung
> ja immer zu. Findet dann eine rechenzeit kostende Abfrage statt oder
> Kürzt der Compiler die if-Abfrage komplett heraus

Der Compiler kürzt bei Compilierung mit Optimierung zur Compilezeit 
bekannte Bedingungen heraus, und entfernt ungenutzen Code, wenn der 
eindeutig ungenutzt ist. Bei ersterem ist dafür ein const oder constexpr 
vor dem bool hilfreich.

#define braucht es für sowas in C++ nicht, das brauchts nur in C.

Oliver

Schlaumaier schrieb:
> Es würde mich wundern wenn Compiler so intelligent sind.

Je nach Qualität des Compilers fliegen nie erreichte Codeschnipsel (nach 
einer Warnung) bei höheren Optimierungsstufen tatsächlich raus. Das og 
Konstrukt mit den Konstanten ist so ein Fall.

Schlaumaier schrieb:
> Es würde mich wundern wenn Compiler so intelligent sind.

Es würde dich noch mehr wundern, wenn du wüsstest, wieviel Aufwand die 
Compilerbauer in die Optimierungen gesteckt haben und immer noch 
stecken, und was die alles können.

Ungennutzen Code entfernen ist allerdings eine der Basis-Optimierungen 
überhaupt, das gibt es schon seit ewigen Zeiten.

Oliver

Sim J. schrieb:
> Wird die if Schleife im folgenden Fall vom Compiler ignoriert, sodass
> diese gar nicht erst in den Speicher des µC geladen wird (da debug =
> false)?

Nö.
Er kann ja nicht wissen, ob die Variable nicht in einer anderen 
Compile-Unit
geändert wird.
Du müßtest sie schon als static deklarieren.

Sim J. schrieb:
> Wenn ich debug = true setze, trifft die if Anweisung ja immer zu. Findet
> dann eine rechenzeit kostende Abfrage statt oder Kürzt der Compiler die
> if-Abfrage komplett heraus?

Mal was zum Thema:

Wenn der Compiler mit einer entsprechenden Optimierungs-Option (-O bzw. 
-O2) gestartet wurde, kann er solche if-Abfragen schon wegoptimieren- 
sowohl wenn debug == true oder debug == false gesetzt wird.

Allerdings musst Du ihm schon etwas unter die Arme greifen, indem Du ihm 
sagst, dass auf die Variable debug nur in dieser Übersetzungseinheit 
zugegriffen wird und nicht ausserhalb. Das geht mit dem Zauberwort 
"static":

1

static bool debug = false;

Dann kann der Compiler - wenn er schlau genug ist - die if-Abfragen 
komplett wegoptimieren, da er sieht, dass sich die Variable "debug" 
nicht ändern kann. Wenn Du das "static" weglässt, muss der Compiler 
davon ausgehen, dass die Variable extern geändert werden kann, da er 
jede Übersetzungseinheit für sich getrennt sieht. In diesem Fall kann er 
die if-Abfragen nicht wegoptimieren. Ausnahme ist LTO - aber das ist 
wieder ein ganz anderes Thema.

Welcher Compiler das kann und ab welchem Optimierungslevel er das tut, 
kann man nicht pauschal sagen. Im Zweifel sollte man sich das 
Assemblerlisting anschauen. Ich bin mir aber ziemlich sicher, dass der 
gcc das ab -O kann, vorausgesetzt, Du hast diese Variable auch static 
definiert.

Ein ganz anderes Thema ist Deine Interupt-Funktion. Im Allgemeinen muss 
eine Variable "volatile" definiert werden, wenn auf sie innerhalb und 
außerhalb einer Interrupt-Funktion zugegriffen wird.

Fazit:
Verwende die vorgeschlagene Preprozessor-Variante. Diese funktioniert 
immer und ist nicht vom Gutdünken des verwendeten Compilers abhängig.

P.S.
Leider machen viele Programmierer viel zu wenig von dem Typenbezeichner 
"static" Gebrauch. Auch Funktionen, die nur innerhalb der 
Übersetzungseinheit (C- oder C++-Datei) aufgerufen werden, sollte man 
static definieren. In diesem Fall kann der Compiler unter Umständen auch 
Funktionsaufrufe eliminieren oder inlinen.

Forenverzweifler schrieb:
> Leider ist der Umgangsstil in diesem Forum echt unter jeder Sau.

genial ein Rundumschlag an ALLE!

Forenverzweifler schrieb:
> Danke, dass du im 18. Beitrag dieses Threads als erster fachkompetent
> antwortest.

und zählen kannst du auch nicht, oder erkläre mir was an der 13ten 
Antwort fachlich falsch war.