Hallo,
ich muß mich in ein Arduinoprogramm einarbeiten.
Dabei bin ich auf Befehle gestoßen, die ein Ausrufezeichen vorangestellt
haben.
Hier ein Auszug als Beispiel:
//Eingänge einlesen
bool button_red_state = !digitalRead(BUTTON_RED);
bool button_yellow_state = !digitalRead(BUTTON_YELLOW);
bool button_green_state = !digitalRead(BUTTON_GREEN);
bool button_blue_state = analogRead(BUTTON_BLUE) > 100 ? false : true;
//Eingänge sind Analog-only
bool button_white_state = analogRead(BUTTON_WHITE) > 100 ? false :
true;
bool button_state = !digitalRead(BUTTON);
bool endswitch_state = !digitalRead(ENDSWITCH);
Was hat das Ausrufezeichen für eine Funktion?
Hier die Quelle des Programms:
http://crlf.eu/2017/01/siemens-s7-mit-arduino-ueber-modbus-tcp/
Hallo
meine Empfehlung:
Mach nicht den gleichen Fehler wie ich ihn auch gemacht habe:
Als Anfänger sich "einfach" ein umfangreiches und trickreiches Programm
anschauen und verstehen zu wollen zu dieses Funktioniert - das ist der
schwere und oft verwirrende Weg Programmieren zu erlernen, auch wenn
natürlich "echte" Anwendungen mit Tiefgang interessanter sind als eine
Blinkschaltung oder einen Ausgang setzen und abschalten.
Nein fange bei Adam und Eva an, auch wenn es oft erstmal nervig und
scheinbar trivial ist, überspringe nicht langweilige Teilkapitel oder
Sachen von den du meinst du du sie nie brauchen wirst.
Ich musste das selber erfahren, es geht leider nichts an den
beschwerlichen Lernweg von Null aus vorbei auch wenn dabei einen
manchmal die Lust vergeht oder der Sinn von bestimmten Lerninhalten erst
mal verborgen bleibt.
Letztendlich braucht man alles später doch einmal, und sei es "nur" um
ein Programm nach zu vollziehen.
Jemand
Du must die Zeile bis zum abschließenden Semikolon betrachten. Das ist eine Zuweisung an "button_red_state". Dieser Variablen wird der negierte (ausgedrückt durch dss Ausrufezeichen) Rückgabewert der Funktion "digitalRead(...)" zugewiesen.
Der Zeilenumbruch in der Anzeige hier im Forum verwirrt zugegebenermaßen ein wenig.
Nur was macht das "!" vor digitalRead() wenn der Eingang der ausgelesen
werden soll "1" oder "0" ist?
Dasselbe:
Aus "0" (false) wird true
und aus "1" (true) wird false.
In C/C++ gibt es native "bool" nur erst seit wenigen Jahrzehnten, vorher wurden dazu simple integers benutzt und aus Abwärtskompatibilität werden alle int, die 0 sind, generell als "false" gewertet und alle anderen als "true".
Warum digitalRead() für die Rückgabe eines "bool" einen "int32_t" bemüht, der auf einem 8-Bit-AVR auch noch unnötig teuer ist, erschließt sich mir auch nicht. Arduino eben...
Naja, den ternären Operator kann man zwar verwenden, es wird allgemein dazu aber abgeraten. Ein if() ist lesbarer, auch wenn es mehr Schreibarbeit ist.
Naja, den ternären Operator kann man zwar verwenden, es wird allgemein
dazu aber abgeraten. Ein if() ist lesbarer, auch wenn es mehr
Schreibarbeit ist.
Falsche Begründung!
Ganz falsch.
Der ternäre Operator ist ganz klar ein Daten bezogener Operator. Er manipuliert den Datenfluss.
If ist ein den Programmfluss veränderndes Statement.
Verwendet man beide für ihren jeweils vorgesehenen Zweck, ist alles ok.
Es gibt keine guten oder bösen Sprachmittel.
Nur eine falsche Verwendung.
Naja, den ternären Operator kann man zwar verwenden, es wird allgemein
dazu aber abgeraten. Ein if() ist lesbarer, auch wenn es mehr
Schreibarbeit ist.
Der ternäre Operator ist ganz klar ein Daten bezogener Operator. Er
manipuliert den Datenfluss.
If ist ein den Programmfluss veränderndes Statement.
Eine atomare Register-Transfer Anweisung ist kein (Daten-) Fluß, dagegen verursacht das automatische Ticken des ProgrammCounters schon einen (Control/Programm-)Fluß.
Oder man schaut sich das Resultat des Compilerdurchlaufes an.
Wenn für "if then else" der selbe oder äquivalenter Coder wie für "?:" erzeugt wird, ist die Wahl der Notation tatsächlich funktional gleich und man entscheidet sich dem der natürlichen Sprache näher Gestellten (bessere Lesbarkeit).
Der generierte Code für die jeweilige Variante "kann" bei bestimmten CPU-Architekturen unterschiedlich ausfallen. In einem FPGA/ASIC kann man tatsächlich einen umschaltbaren Datenpfad (Multiplexor) implementieren.
Im Fall Arduino (Load/Store Maschine) dürfte für beide Notationen der selbe Code generiert werden.
Naja, den ternären Operator kann man zwar verwenden, es wird allgemein
dazu aber abgeraten. Ein if() ist lesbarer, auch wenn es mehr
Schreibarbeit ist.
sondern ganz einfach schreiben:
bool button_blue_state = analogRead(BUTTON_BLUE) <= 100;
Das wäre mir eine Nummer zu riskant: Bei if, while, for oder ? erwarte ich einen Vergleich. Wenn er entfällt (z.B. : "if(a) ..."), ist auch das relativ schnell klar.
Dein Beispiel ist eher wie "while(a=b) ...": Man fragt sich unwillkürlich: gewollt oder Tippfehler? Und das behindert den Lesefluss.
würde ich keinen ternären Operator und erst recht kein if-else
verwenden, sonder ganz einfach schreiben:
bool button_blue_state = analogRead(BUTTON_BLUE) <= 100;
Das ist zwar korrekt, aber leider auch wieder arg in Richtung Hackermist. Würde ich nicht empfehlen. Denn der Sinn er Anweisung ist eine Auswahl. if else. Dann sollte man das auch so hinschreiben.
Das ist zwar korrekt, aber leider auch wieder arg in Richtung
Hackermist. Würde ich nicht empfehlen. Denn der Sinn er Anweisung ist
eine Auswahl. if else. Dann sollte man das auch so hinschreiben
Warum?
Das Problem ist so alt wie diese Sprache.
Sie stammt aus den Hochzeiten der Assemblerprogrammierung und gibt einem Freiheiten, die eigentlich keiner (mehr) haben möchte. Deshalb gibt es je nach Schule, einen Haufen Regeln, wie man irgendetwas zu formulieren hat.
Deshalb gibt es
je nach Schule, einen Haufen Regeln, wie man irgendetwas zu formulieren
hat.
Philosophie?
Leitmotiv:
Jedes vermeidbare IF ist ein böses IF
Jedes Vermiedene IF ist ein gutes IF
Das IF an der Stelle, kann durch jedes andere Statement/Pattern ersetzt werden
Übrigens:
Zwischen den beiden Merksätzen findet sich eine kleine, aber feine Hysterese. Und genau in dieser Hysterese steckt idealer Weise im Abschluss das fertige Programm. Erwachsen aus der Summe der gemachten Kompromisse.
Ich wette, da erkennen 80% der Leser nicht auf Anhieb, ob das überhaupt korrekt ist. Womit das Problem an "Jedes vermeidbare IF ist ein böses IF" bestätigt wäre.
Aber so weit muss man gar nicht gehen. Genau so schlecht finde ich ellenlange verschachtelte Bedingungen hinter einem if. Eine Aufsplittung in mehrere if-Anweiungen macht den Code oft deutlich besser lesbar.
würde ich keinen ternären Operator und erst recht kein if-else
verwenden, sonder ganz einfach schreiben:
bool button_blue_state = analogRead(BUTTON_BLUE) <= 100;
Das ist zwar korrekt, aber leider auch wieder arg in Richtung
Hackermist.
ein boolescher Ausdruck, die Ergebnisvariable ist ebenfalls boolesch.
Allerdings die der Ausdruck nicht direkt der Variable zugewiesen werden,
da die Anwendung des ternären Operators eine Negation bewirkt. C/C++ hat
aber bereits einen Negationsoperator (nämlich "!"), weswegen man ihn
nicht neu erfinden muss. Also wird aus der obigen Anweisung zunächst
Die Negation einer größer-Operation ist die entsprechende
kleiner-gleich-Operation. Auch den kleiner-gleich-Operator muss man
nicht neu erfinden (C/C++ kennt auch "<="). Also kann die Anweisung
weiter vereinfacht werden zu
(Wer will, darf den Ausdruck auf der rechten Seite des "=" gerne auch
klammern)
Aussagenlogisch betrachtet ist /button_blue_state/ nichts anderes als
ein Name für die Aussage "Der Analogwert am Pin BUTTON_BLUE ist maximal
100". Diese Erklärung wird sogar ein Nichtprogrammierer sofort
verstehen.
Was soll daran also Hackermist sein?
Durch die Verschwurbelung mittels des ternären Operators oder gar eines
if-else-Konstrukts wird der an sich sehr einfache Sachverhalt nur
künstlich aufgebläht.
Führte man diese Verschwurbelung konsequent für andere als den
"<"-Operator fort, bspw. für den "+"-Operator, würde eine einfache
Integer-Addition so aussehen:
1
unsignedinta,b,c;
2
...
3
if(a+b==0)
4
c=0;
5
elseif(a+b==1)
6
c=1;
7
elseif(a+b==2)
8
c=2;
9
elseif(a+b==3)
10
c=3;
11
...
Das ist zwar durchaus korrekt, aber man könnte die lange if-else-Kette
auch einfach ersetzen durch
1
c=a+b;
Ist diese Verkürzung deiner Ansicht nach ebenfalls Hackermist?
Nichts. Ich würde nur den unpassenden Namen der Variable kritisieren.
button_blue_state kann true oder false sein. Was bedeuten diese Werte? blue_button_is_pressed oder blue_button_is_released wären viel aussagekräftiger.
Außerdem bewirkt das "&& 1" überhaupt nichts. Da sollte wohl ein "||"
stehen.
Richtiger ist dieses hier:
1
belastung()<=100
2
||dauer()>KURZ
3
&&(leistung_herunter_fahren()||true)
4
||warnung_anzeigen();
oder, um näher an der Struktur von Sherlocks Beispiel zu bleiben:
1
belastung()>100
2
&&(dauer()>KURZ
3
&&(leistung_herunter_fahren()ortrue)
4
||warnung_anzeigen())
Aber auch das funktioniert nur dann, wenn die Rückgabewerte von
leistung_herunter_fahren() und warnung_anzeigen() legale Operandentypen
für && und || sind. Ohne benutzerdefinierte Konvertierungsfunktionen
und/oder Überladungen von && und || ist dies für Funktionen mit
Rückgabetyp void, struct und class nicht der Fall.
Dass es offensichtlich nicht ganz leicht ist, den korrekten logischen
Ausdruck als Ersatz für die if-if-else-Anweisung zu finden, zeigt, dass
hier die if-if-else-Schreibweise die bessere Wahl ist.
widersprechen sich teilweise, so auch in Sherlocks Beispiel. Wenn man
als weitere Regel hinzufügt, dass im Fall eines Widerspruchs der erste
Regelsatz anzuwenden ist, dann passt alles, und sie sind kein
ein boolescher Ausdruck, die Ergebnisvariable ist ebenfalls boolesch.
Keine Sorge, die Syntax verstehe ich schon.
Was soll daran also Hackermist sein?
Anstatt einen einfachen, klaren Lesefluße zu erlauben, wird mit den C inherenten logischen Ausdrücken hantiert. Das spart ein wenig Schreibarbeit, verschlechtert aber die (flüssige) Lesbarkeit.
Durch die Verschwurbelung mittels des ternären Operators oder gar eines
if-else-Konstrukts wird der an sich sehr einfache Sachverhalt nur
künstlich aufgebläht.
An if-else ist rein gar nichts verschwurbelt! Du betreibst gerade Propaganda!
Es gibt nicht umsonst den C obfuscation Contest! Dein Logikausdruck ist der erste, wenn auch kleine Schritt dahin.
Es gibt Style Guides, die empfehlen die möglichst leicht lesbare und am wenigsten missverständlichste Variante eines Konstrukts hinzuschreiben. Das muss nicht immer die kürzeste sein.
Führte man diese Verschwurbelung konsequent für andere als den
"<"-Operator fort, bspw. für den "+"-Operator, würde eine einfache
Integer-Addition so aussehen:
Hör auf solchen Käse zu erzählen. Du übertreibst massiv. Polemik beherrschen wir alle gut genug.
Naja, den ternären Operator kann man zwar verwenden, es wird allgemein
dazu aber abgeraten.
Unsinn. Es wird nicht "allgemein" davon abgeraten.
Aber wenn man ein sinnvolles Konstrukt nie verwendet oder die Syntax nicht kennt, kann man natürlich Vermeidungs"taktik" betreiben. Oder vertraut damit werden.
Aber wie gesagt: Auch das ist nur eine (wenn auch IMHO recht gut
begründete) Meinung.
Naja, sachlich spricht wenig gegen die Begründungen von Chat GPT. Und kompakte Schreibweisen sind an sich oft schon günstig(er). Aber es bleibt die Frage wie weit man damit gehen will oder sollte.
Aber es bleibt die Frage wie weit man damit gehen will oder sollte.
Natürlich nur so weit, wie es Vorteile bringt :)
Wenn man sich schon etwas länger mit einer Programmiersprache
beschäftigt und immer wieder einmal schaut, wie andere es machen¹,
bekommt man allmählich ein ganz gutes Gefühl dafür, wo die Verschlankung
von Quellcode noch zur Übersichtlichkeit beiträgt, und ab wann der Code
kryptisch zu werden droht.
ist das immer so richtig?
...
denn x > 1 schließt ja -1 aus und da -1 auch != 0 ist müßte es true sein
Du musst unterscheiden zwischen der Variable x (die kann irgendeinen
beliebigen Wert annehmen) und dem gesamten Bedingungsausdruck (x>1), der
nur die Werte true und false (true für x>1 und false für x≤1) annehmen
kann.
Der Leser ist hier also erst einmal damit beschäftigt nachzuprüfen, ob
die Zuweisung im if- und im else-Zweig tatsächlich an das gleiche
Struktur-/Array-Element erfolgt.
Nicht umsonst wurde in Python immer wieder das Fehlen des ternären
Operators kritisiert. Irgendwann hatte Guido dann ein Einsehen und hat
ihn implementiert (wenn auch mit einer anderen Syntax als in C), und
alle (oder zumindest die meisten) haben sich gefreut wie an Weihnachten
:)
Anstatt einen einfachen, klaren Lesefluße zu erlauben,
Wenn dein Lesefluss von dem ternären Operator gestört wird, dann kann man das wohl deiner Übung zurechnen. bzw. der mangelnden Übung, Evtl. Verursacht durch Ablehnung und Vermeidungsstrategien.
Also eher dein Innenwelt Problem, als eine Eigenschaft des Operators.
Weder der ternäre Operator, if und auch goto sind die ideale Losung für jede beliebige Problemstellung.
Aber in einigen Fällen durchaus nützlich.
Grundsätzlich:
Die Idee irgendwelche Sprachkonstrukte zu tabuisieren halte ich für (suchs dir selber aus).
Vorschlag: z.B. Für irregeleiteten Dogmatismus.
Aber es bleibt die Frage wie weit man damit gehen will
Der ternäre Operator hat noch einen weitere Vorteil:
Er macht klar, dass ein Wert gesetzt wird, und er kann in einer
Initialisierung z.B. einer const Variable verwendet werden:
const int var = bedingung ? wert1 : wert2;
Ich hab mal gelesen, daß man den ternären Operator im "normalen" Programmfluß eher sparsam einsetzen sollte und sich auf Makros oder eben die obige Zuweise bechränken sollte. OK, bei längerem Nachdenken ist die Zuweisung
Anstatt einen einfachen, klaren Lesefluße zu erlauben,
Wenn dein Lesefluss von dem ternären Operator gestört wird,
Wird er nicht wesentlich, ich habe das aber mehrfach in Style Guides gelesen.
Grundsätzlich:
Die Idee irgendwelche Sprachkonstrukte zu tabuisieren halte ich für
(suchs dir selber aus).
Vorschlag: z.B. Für irregeleiteten Dogmatismus.
Ohhh, Vorsicht! Das setzt eine ideale Sprache voraus! Wenn man JEDEN Blödsinn im realen Leben macht, der mit technisch C möglich ist, kommt man beim obfuscation contest raus! Es gibt schon VIELE gute Gründe, warum es Style Guides oder im Extremfall solche Geschichten wie MISRA oder LINT gibt!
Das Beispiel ist mit "1" leicht irreführend. Es wäre mit "x>33" oder "x==7" klarer, dass es um eine beliebige Bedingung geht, nicht darum, was true oder false repräsentieren.
ich lernte aber das 0 = false und true != false damit lege ich mich auf
keine Zahl fest für true
Das ist ja auch richtig, aber du verwechselst offenbar die 1 aus "x > 1" mit dem Wahrheitswert für true. 1 ist aber in diesem Fall einfach nur ein Zahlenwert, der mit dem Wert für x verglichen wird.
offensichtlich, ist ja auch schon spät, Knoten im Kopf
kein Ding. Einfach in ein paar Tagen in Ruhe nochmal lesen.
ich bleibe lieber beim für mich leichteren Verständnis
Joachim B. schrieb:
bool c;
false = 0;
true = !false;
Wir wissen, was Du sagen willst. Und das (was Du sagen willst) ist auch richtig. false ist 0 in C und true ist !false.
Aber: die Repräsentation von true und false hat nichts (!) mit dem Beispiel von Yalu zu tun.
wenn x == 36 ist wäre c = false, sieht für mich
nicht richtig aus und wenn es richtig ist, ist es nur undurchsichtig!
wenn schon denn:
if x
c = true;
else
c = false;
Unsinn. x > 1 ist in C ein (logischer) Ausdruck (expression) , der auf seinen logischen Wahrheitsgehalt geprüft wird. Das Ergebnis dieser Prüfung kann wahr (true) oder falsch (false) sein und wird hier der boolschen Variable c zugewiesen. Es kann aber auch in einem komplexeren Ausdruck weiter verwendet werden.
Relational operators >, <, ==,!= etc are used to compare 2 operands. Relational expressions consisting of operands, variables, operators, and the result after evaluation would be either true or false."
Du verwirrst mich!
Manchmal sprichst du über den Datentype bool.
Manchmal über die automatischen Konvertierungen.
Manchmal C,
Manchmal C++(zumindest ist das hier ein Arduino Thread)
Warum digitalRead() für die Rückgabe eines "bool" einen "int32_t"
bemüht, der auf einem 8-Bit-AVR auch noch unnötig teuer ist, erschließt
sich mir auch nicht. Arduino eben..
Jetzt kann man sagen: 16Bit ist immer noch zuviel.
Andererseits stammt Arduino aus der Processing Ecke.
bzw. hat das Processing als Vorlage für viele Arduino Funktionen gedient
https://processing.org/reference/libraries/io/GPIO_digitalRead_.html
Und dort ist es eben ein int als Rückgabewert.
Auch gab es noch kein natives/gemeinsames bool in C bzw. C++ als Arduino erfunden wurde.
Ansonsten gilt, wie immer:
Wenn einem digitalRead() nicht gefällt, dann baut man sich ein eigenes.
