hallo zusammen
ich bin am verzweifeln!!!!!!!!
ich würde gerne einen "if" Befehl einbinden-aber ich weis nicht wie.
int richtungA = 12;
int richtungB = 13;
int pwmB = 11;
int pwmA = 3; //hat gefehlt
int bremseA = 9;
int bremseB = 8;
int laserPin = 4;
int geschwindigkeit = 128;//Geschwindigkeit max 255
int geschwindigkeitA = 110;
int geschwindigkeitB = 128;
void setup()
{
pinMode(richtungA, OUTPUT); //Motorrichtung als Ausgang
pinMode(richtungB, OUTPUT);
pinMode (bremseA, OUTPUT);//Bremse als Ausgang
pinMode (bremseB, OUTPUT);
analogWrite (pwmA, 100); //Geschwindigkeit der einzelnen Motoren
analogWrite (pwmB, 128);
digitalWrite (bremseA, HIGH);//Bremse Motor aus
digitalWrite (bremseB, HIGH);
pinMode (4,OUTPUT);
}
void loop() {
delay(2000);//2Sekunden warten
digitalWrite (richtungA, HIGH);//Motoren vorwärts
digitalWrite (richtungB, HIGH);
if (richtungA, HIGH);
{
digitalWrite(laserPin,HIGH);// Anweisungsblock für wahr
delay(100);
}
digitalWrite (bremseA, LOW); //Bremse lösen
digitalWrite (bremseB, LOW);
delay(3000);//1Sekunde fahren
digitalWrite (bremseA, HIGH);//Bremsen Motoren aus
digitalWrite (bremseB, HIGH);
delay(2000);//2Sekunden warten
digitalWrite(richtungA, LOW);//Motoren rückwärts
digitalWrite(richtungB, LOW);
digitalWrite(bremseA, LOW);//Bremse lösen
digitalWrite(bremseB, LOW);
delay(1000);//1Sekunde fahren
digitalWrite(bremseA, HIGH);//Bremsen Motor aus
digitalWrite(bremseB, HIGH);
}
Ich versuche mich seit Tagen daran,es zu verstehen.Leider komme ich
nicht weiter.Ich benutze ein uno3 mit aufgestecktem "Arduino Motor
Shield".
Versucht es bitte verständlich zu erklären,oder es so umzuschreiben das
es funktioniert,und ich es dadurch lerne.
Ich habe mir alles mögliche über Funktionen erlesen,aber irgendwie
verstehe ich das nicht.
Wo schreibt man z.B. den "if" Befehl hin?In das Setup oder in den
"Loop"?
Ich hätte gerne das Der Laser nur dann arbeitet wenn "MotorA" im "HIGH"
Zustand ist.
Wenn der Sketch vorher bearbeitet werden muss,bevor er hier hochgeladen
wird,sagt mir bitte wie.
Lutz H. schrieb:> ;
Ohne das Semikolon geht es besser,
dadurch werden die Anweisungen zwischen den Klammern ausgeführt, sonst
manchmal nur nichts vor dem Semikolon. Deshalb schreibe ich immer
Klammern.
Lutz H. schrieb:> Deshalb schreibe ich immer Klammern.
Hat mich auch schon Stunden des Suchens gekostet ein Semikolon am Ende.
Einfach nicht gesehen. Habe es mir auch angewöhnt immer Klammern zu
verwenden.
mfg
Olaf
Olaf B. schrieb:> Lutz H. schrieb:>> Deshalb schreibe ich immer Klammern.>> Hat mich auch schon Stunden des Suchens gekostet ein Semikolon am Ende.> Einfach nicht gesehen. Habe es mir auch angewöhnt immer Klammern zu> verwenden.>> mfg>> Olaf
Was nützen die Klammern, wenn in der if-Zeile ein Semikolon steht?
Die Klammern sind doch nur dafür da, zwei oder mehrere Zeilen eines
Anweisungsblocks zusammenzufassen. Das nützt aber nichts, wenn hinter
dem if ein Semikolon steht...
Nop schrieb:> "if-Befehl".. als nächstes kommt wohl die Frage, wann Ritchie es> zwischen den Gigs mit Deep Purple eigentlich geschafft hat, C zu> entwickeln.
Blackmore hat kein C entwickelt...
Erwin D. schrieb:> Blackmore hat kein C entwickelt...
Zum Glück hat er das nicht getan. Er hat sich auf Sachen beschränkt, von
denen er was versteht. Hard loving man z.B. ist ziemlich genial.
Anders als die Erfinder von C, denn deren Ansatz, Assembler durch eine
leicht zu lernende Hochsprache zu ersetzen, kann man nur als auf voller
Breite gescheitert einschätzen.
Einerseits kann C Assembler nicht wirklich ersetzen (höchstens
teilweise) und andererseits ist C keine wirkliche Hochsprache (höchstens
ansatzweise) und letztlich: ganz sicher ist C auch alles andere als
leicht zu erlernen. Im Prinzip können es nur sehr wenige Menschen auf
der Erde vollständig.
Wobei ich hier optimistischerweise davon ausgehe, das die ihren selbst
verfassten Scheiss tatsächlich nicht nur einmalig hingeschrieben haben,
sondern den Inhalt jederzeit vollständig als anwendungsbereites Wissen
inclusive aller Implikationen vorhalten, was ich für fast unmöglich
halte.
Ich wäre fast sicher, dass man sogar den Verfassern des (eines der
vielen) Sprachstandards Fallen stellen könnte, auf die sie hereinfallen
würden, jedenfalls solange man sie nicht in ihrem Wälzer blättern
läßt...
c-hater schrieb:> Anders als die Erfinder von C, denn deren Ansatz, Assembler durch eine> leicht zu lernende Hochsprache zu ersetzen, kann man nur als auf voller> Breite gescheitert einschätzen.
Du hast eine seltsame Definition von "gescheitert".
Kleiner Tipp:
Ein Produkt, das eine extrem weite Verbreitung erfahren hat, stufen
normale Menschen üblicherweise als "erfolgreich" ein.
Wenn das alles ist,aber kein"Copypaste". Aber ich darf auf diese Aussage
nicht antworten.
Dem Rest schon mal im voraus Vielen Dank.Ich werde mir das morgen
nochmal anschauen.
Ich habe mir einiges erlesen und finde viele Funktionen eher als
schwierig umzusetzen,da sie zu allgemein gehalten sind.
Ich bin Quereinsteiger und bin am lernen um zu verstehen.
Uwe M. schrieb:> Ich bin Quereinsteiger und bin am lernen um zu verstehen.
Dafür wäre es aber sinnvoll, mal ein oder zwei der zahlreichen
Tutorials durchzugehen, die es so im Netz gibt.
Man kann quer einsteigen, kein Problem, aber nicht, indem man die
Basics der benutzten Programmiersprache errät. Ein bisschen
Handwerkszeug muss man einfach mal lernen und üben, um es später
benutzen zu können.
ich bin nicht nur ein oder zwei Tutorials durchgegangen-wenn ich mir
hätte selber helfen können,hätte ich nicht gefragt.
Ich beneide zu tiefst die,die es schneller verstanden haben als manch
anderer.
Hoffentlich habt ihr nie Kinder die nicht gleich alles verstehen.
Mark B. schrieb:> Du hast eine seltsame Definition von "gescheitert".
Ja, das gebe ich gern zu.
> Kleiner Tipp:> Ein Produkt, das eine extrem weite Verbreitung erfahren hat, stufen> normale Menschen üblicherweise als "erfolgreich" ein.
Das genau ist das Problem.
Siehe z.B. VHS vs. Konkurrenz. Ja, VHS war natürlich erfolgreich, wenn
man es allein an der Verbreitung festmacht. Aber es war trotzdem das
technisch beschissenste der drei damals konkurrierenden
Video-Systeme...
Begreifst du anhand dieses Beispiels, was ich gemeint habe?
Dazu kommt: Die Macher von VHS haben immerhin keinerlei Ziele
formuliert, sie wollten also einfach nur Geld machen. Das haben sie
tatsächlich erreicht. Eben über die erreichte Verbreitung ihres Systems.
Das System war einfach billig und geringe Preise sprechen den
unwissenden Konsumenten natürlich an und beeinflussen primär dessen
Kaufentscheidung.
Ganz anders die Macher von C, die haben Ziele formuliert, die durchaus
jenseits des schnöden Mammons lagen. Und sie haben nicht eins davon
wirklich erreicht...
Aber die unwissenden Konsumenten haben es trotzdem angenommen. Und
sorgen seitdem für eine quasi virale Verbreitung. Ist wie ein
Schnupfenvirus, einfach nicht tot zu kriegen, diese Seuche.
Uwe M. schrieb:> ich bin nicht nur ein oder zwei Tutorials durchgegangen-
5 Minuten, Zehn Minuten lang?
> wenn ich mir> hätte selber helfen können,hätte ich nicht gefragt.
Das sind Grundlagen, ohne die man zu nichts kommt. Wenn das nicht
klappt, anderes Hobby suchen.
Ich gebe zu, dass ich an if und else zu Anfang auch kauen musste, bin
aber nicht annähernd auf die Idee gekommen, sowas ins Forum zu tragen.
Es gibt Schulskripte und Bücher!
Neben der falschen Klammer "{" noch ein Hinweis: Stichwort "Operatoren"
c-hater schrieb:> Aber die unwissenden Konsumenten haben es trotzdem angenommen. Und> sorgen seitdem für eine quasi virale Verbreitung. Ist wie ein> Schnupfenvirus, einfach nicht tot zu kriegen, diese Seuche.
es ist vielmer die "Geschweifte-Klammer-Seuche" die das eigentliche
Problem darstellt. Jede superduper fancy Programmiersprache die noch
langsameren Code erzeugt als ihr Vorbild verwendet sie heute. Dies um ja
nicht in die "falsche" Ecke gestellt zu werden - zu Sprachen die richtig
echte ausgeschriebene Wörter oder sinnvolle Kürzel verwenden als
Blockbegrenzer, damit man nicht in die Breduille kommt den Zweck eines
Codeabschnitts schneller erfassen zu können.
Wozu die ganzen Wörter noch in C? Das ist doch wie Basic! Raus damit,
wir finden sicher noch Sonderzeichen aus dem UTF-Zeichensatz welche dann
"if","define" usw ersetzen können, alles Andere ist doch für
Amateure!!!!
auch diese Klammerseuche in der Mathematik überhaupt, damit wollen nur
diese selbsternannten Experten ihr Herrschaftswissen bewahren,
statt
(3+5)*6
sollte man besser schreiben
nimm die Zahl 3 und addiere 5 dazu, da kommt dann was raus und das
multiplizierts du dann mit 6
horst schrieb:> es ist vielmer die "Geschweifte-Klammer-Seuche" die das eigentliche> Problem darstellt.
Ja, die Klammern haben mich anfangs heftig zur Verzweifelung getrieben.
Es ist halt eine der diversen Konventionen jeder Sprache, man begreift
sie nach einer Weile Übung und gut ist.
> Jede superduper fancy Programmiersprache die noch> langsameren Code erzeugt als ihr Vorbild verwendet sie heute.
Was für eine unsinnige Aussage ist das denn? Eine Hochsprache erreicht
nicht die Geschwindigkeit einer manuell optimierten
Assemblerprogrammierung, soweit Richtig. Es gibt aber nur sehr wenig
Anwendungen, in denen das von Bedeutung ist, von daher haben diese
Hochsprachen sich durchgesetzt.
In den 90er-Jahren habe ich Steuerungsabläufe in Assembler geschrieben
und auch da schon Timer und Wartezyklen einbauen dürfen. Heutzutage
würde ich den Kram per Arduino machen, weil nämlich die Peripherie im
Umfeld in den 25 Jahren kein Stück schneller geworden ist, aber die
Controller vielfach schneller und erheblich billiger geworden sind.
Es ist einfach Quark, eine Umgebung zu verteufeln, weil man theoretisch
schneller könnte, es in der real existierenden Anwendung aber garnicht
notwendig ist. Im übrigen hält Dich niemand davon ab, den unkritischen
Teil in C zu machen und zusätzlich Assembler-Routinen einzubinden.
Walter S. schrieb:> auch diese Klammerseuche in der Mathematik überhaupt, damit wollen nur> diese selbsternannten Experten ihr Herrschaftswissen bewahren ...
Sehr gut kommentiert, danke!
Uwe M. schrieb:> Hoffentlich habt ihr nie Kinder die nicht gleich alles verstehen.
Habe ich. Aber auch denen ist nicht geholfen, dass man es ihnen
vorkaut. Damit sie es lernen, müssen sie es selbst machen.
Wenn du hier nach irgendwas Kompliziertem gefragt hättest, und für
viele fängt das schon bei Zeigern an (außer vielleicht Leute, die
mal Assembler programmiert haben), oder den ternären Operator:
kein Thema, dafür ist wirklich das Forum gut. Aber eine simple
Bedingung ist grundlegendes Handwerkszeug. Da musst du die
Tutorials einfach durchgehen, bis du es verstanden hast.
C lässt sich übrigens deutlich einfacher lernen, wenn man das auf
dem PC macht und nicht gleich auf dem Controller.
Was willst du jetzt hier mit Dingen provozieren, die einfach
undefiniertes Verhalten triggern? Meinst du, damit wäre dem TE
in irgendeiner Weise geholfen?
Wenn dich Präfix- oder Postfixoperatoren in C stören und du gern
diesbezüglich zur Klarheit von Pascal möchtest: nimm sie einfach
nicht. Keiner sagt, dass du sowas wie "i++" unbedingt schreiben
musst. Du kannst auch jederzeit "i = i + 1" schreiben.
Jörg W. schrieb:> Du kannst auch jederzeit "i = i + 1" schreiben.
genau, klar und logisch, die Gemeinheiten i++; (wobei der Asm Progger
das schon von inc kennt) kann man ja später nutzen um Schreibarbeit zu
mindern, nur nutzt das manchmal nichts weil der optierende Compiler
sowieso gleichen Code draus macht oder machen kann (könnte) mich
überrascht er manchmal noch, das "meine Optimierungen" längeren Code
verursachen.
Uwe M. schrieb:> ich bin nicht nur ein oder zwei Tutorials durchgegangen...
Vielleicht wäre es ganz gut wenn du dir auch mal ein entsprechendes Buch
zulegen würdest.
rhf
c-hater schrieb:> Ganz anders die Macher von C, die haben Ziele formuliert, die durchaus> jenseits des schnöden Mammons lagen. Und sie haben nicht eins davon> wirklich erreicht...
Interessant, welche denn?
rhf
Hallo,
vorweg: ich kann etwas C, soviel, daß es für meine Vorhaben reicht und
wenn nicht, lerne ich eben dazu...
Problematischn wohl gerade für Anfänger Konventionen in C, die man eben
hinnehmen (nachlesen...) muß.
Eine Anweisung in C endet immer mit einem Semikolon.
1
a = 1;
2
3
...
Soweit gut.
1
IF (a == 1)
2
a = 2;
3
4
...
Das Semikolon beendet hier eigentlich die IF-Anweisung...
1
IF (a == 1) then a = 2;
2
3
...
"then" gibt es aber nicht, das darf man sich aber dazudenken.
Schreibt man es also wie oben in 2 Zeilen beendet das eine Semikolon
eigenlich die Anweisung a = 2 und die IF-Anweisung...
Passt bei mehreren Anweisungen also nicht mehr, da muß ein Block in {}
her.
[/code]
Soweit gut.
1
IF (a == 1)
2
{
3
a = 2;
4
b = 3;
5
}
6
7
...
Jetzt fehlt aber eigentlich das Semikolon nach den Klammern für das Ende
der IF-Anweisung...
1
IF (a == 1)
2
{
3
a = 2;
4
b = 3;
5
};
6
7
...
Das darf da aber weggelassen werden, das erledigt } mit.
Ein Anweisungsblock in {} gehört zu irgendwas, wo er ausgeführt wird.
Zu IF, zu ELSE, zu WHILE, ...
Er muß aber auch zu garnichts gehören, ich kann auch einfach
1
a = 1;
2
3
// Servowerte setzen
4
{
5
servo1 = 2;
6
servo2 = 3;
7
}
8
9
e = 4;
10
11
...
weil ich es toll finde es so für mich zu gruppieren...
Man möge mich gern korrigieren.
Gruß aus Berlin
Michael
Hallo Michael,
ja wenn die einen neuen Block über {} erzeugt, gilt auch ein andere
Scope für Variable, speziell Variable, die man innerhalb des Blocks
anlegt, sind außerhalb nicht sichtbar. Somit kann man auch mehrfach den
vermeindlich gleichen Variablennamen vergeben.
1
uint8_tn;
2
n=0x34;
3
{
4
uint8_tn;
5
if(n==0x34){
6
// do something
7
}
Sollte eine Fehlermeldung generieren, da n ohne Wert/ initialisiert ist.
Karl M. schrieb:> Sollte eine Fehlermeldung generieren
Genauer: eine Warnung, allerdings muss man diese auch einschalten
(-Wall -Wextra). Weiß nicht, wie das die Arduino-IDE handhabt, da
sind die Compiler-Kommandos mehr oder minder in (Java-)Stein
gemeißelt.
Walter S. schrieb:> auch diese Klammerseuche in der Mathematik überhaupt, damit wollen nur> diese selbsternannten Experten ihr Herrschaftswissen bewahren,> statt>> (3+5)*6> sollte man besser schreiben> nimm die Zahl 3 und addiere 5 dazu, da kommt dann was raus und das> multiplizierts du dann mit 6
Horst hat es gut auf den Punkt gebracht.
Dein Beitrag dagegen trifft den Zusammenhang überhaupt nicht, weil es
nicht um "normale" Klammern geht, die die Reihenfolge von
Rechenoperationen regeln, sondern um geschweifte Klammern, die böse
Verwirrung stiften können, weil sie keine syntaktischen Fehler
darstellen, sondern "nur" zu falschen Resultaten führen.
Hallo,
Jörg W. schrieb:> Karl M. schrieb:>> Sollte eine Fehlermeldung generieren>> Genauer: eine Warnung, allerdings muss man diese auch einschalten> (-Wall -Wextra). Weiß nicht, wie das die Arduino-IDE handhabt, da> sind die Compiler-Kommandos mehr oder minder in (Java-)Stein> gemeißelt.
jein... ;)
Ab Warnungen "Weitere" erhält man diese Meldung:
C:\Users\Roehre\AppData\Local\Temp\arduino_modified_sketch_941637\Blink.
ino:30:12: warning: 'b' is used uninitialized in this function
[-Wuninitialized]
a = b + 3;
^
Natürlich muß man diese Möglickeiten der Arduino-IDE auch nutzen.
Gruß aus Berlin
Michael
Roland F. schrieb:> Lutz H. schrieb:>>> Mit möglichst wenig Zeichen auf einer Lochkarte viel zu programmieren.>> Das wusste ich gar nicht, wo kann man das mal nachlesen?>> rhf
Auf Karte Nr. 27...32 :-)
Statsitiker schrieb:> Dein Beitrag dagegen trifft den Zusammenhang überhaupt nicht, weil es> nicht um "normale" Klammern geht, die die Reihenfolge von> Rechenoperationen regeln, sondern um geschweifte Klammern, die böse> Verwirrung stiften können, weil sie keine syntaktischen Fehler> darstellen, sondern "nur" zu falschen Resultaten führen.
Wo können die denn Verwirrung stiften? Geschweifte Klammern werden
benutzt, um einen Block zu erzeugen. Ich hatte auch am Anfang ein paar
Probleme mit C, aber geschweifte Klammern haben nie dazugehört. Die
Initialisierung von Arrays ist ein komplett anderer und deutlich
unterschiedlicher Anwendungsbereich. Damit kann es also keine
Verwechslung geben.
Michael U. schrieb:> Problematischn wohl gerade für Anfänger Konventionen in C, die man eben> hinnehmen (nachlesen...) muß.>> Eine Anweisung in C endet immer mit einem Semikolon.a = 1;>> ...> Soweit gut.> IF (a == 1)> a = 2;>> ...>> Das Semikolon beendet hier eigentlich die IF-Anweisung...IF (a == 1)> then a = 2;>> ...> "then" gibt es aber nicht, das darf man sich aber dazudenken.> Schreibt man es also wie oben in 2 Zeilen beendet das eine Semikolon> eigenlich die Anweisung a = 2 und die IF-Anweisung...>> Passt bei mehreren Anweisungen also nicht mehr, da muß ein Block in {}> her.> [/code]> Soweit gut.> IF (a == 1)> {> a = 2;> b = 3;> }
Ist doch eigentlich ganz logisch:
1
if(Bedingung)EineAnweisung;
Das 'then' fehlt nur weil es überflüssig ist.
> Jetzt fehlt aber eigentlich das Semikolon nach den Klammern für das Ende> der IF-Anweisung...> IF (a == 1)> {> a = 2;> b = 3;> };>> Das darf da aber weggelassen werden, das erledigt } mit.
Möchte man anstelle von 'EineAnweisung' mehrere machen (was ja durchaus
häufig vorkommt) macht man halt einen neuen Block mit geschweiften
Klammern auf. Die Anweisungen darin werden jeweils ganz normal mit einem
Semikolon abgeschlossen. Der Block aber nicht, denn er ist ja kein
Anweisung, sondern dient nur der Gruppierung.
> Ein Anweisungsblock in {} gehört zu irgendwas, wo er ausgeführt wird.> Zu IF, zu ELSE, zu WHILE, ...
Ja, genau so ist es. Ohne Blöcke müsstest du nämlich anstelle von
1
if(a){
2
anweisung1;
3
anweisung2;
4
anweisung3;
5
}
das hier schreiben:
1
if(a)
2
anweisung1;
3
if(a)
4
anweisung2;
5
if(a)
6
anweisung3;
> Er muß aber auch zu garnichts gehören, ich kann auch einfach> a = 1;>> // Servowerte setzen> {> servo1 = 2;> servo2 = 3;> }>> e = 4;
Ein Block macht jeweils einen neuen Scope auf. Eine Variable die
innerhalb des Blocks deklariert wird ist auch nur darin gültig.
Ich benutze das z.B. gerne in case-Statements. Auch in C++ in
Kombination mit RAII macht das Sinn. Da kann man sehr genau bestimmen
wann eine gekapselte Ressource wieder freigegeben werden soll.
Slippin J. schrieb:> Ja, genau so ist es. Ohne Blöcke müsstest du nämlich anstelle von> if (a) {> anweisung1;> anweisung2;> anweisung3;> }>> das hier schreiben:> if (a)> anweisung1;> if (a)> anweisung2;> if (a)> anweisung3;
Was aber nicht das gleiche ist.
Wenn eine Anweisung die Bedingung "a" verändert, werden die folgenden
Anweisungen nur im oberen Fall auf jeden Fall auch ausgeführt. Im
unteren vielleicht, vielleicht aber auch nicht. Oder ganz bestimmt
nicht. Oder doch...
Thomas E. schrieb:> Was aber nicht das gleiche ist.>> Wenn eine Anweisung die Bedingung "a" verändert
Hast recht. Den Sonderfall habe ich nicht betrachtet.
horst schrieb:> es ist vielmer die "Geschweifte-Klammer-Seuche" die das eigentliche> Problem darstellt.
Sehe ich nicht so. Ich hab ja mit Pascal angefangen (kann also
vergleichen), und das begin/end fand ich total nervig. Wenn ich einen
C-Text habe, tarnen sich meine Bezeichner und Funktionsaufrufe optisch
nicht in einer Bleiwüste aus Blockbegrenzern.
Abgesehen davon finde ich C auch als Sprache einfach schön. Ist nicht
so, daß ich das notgedrungen als Werkzeug einsetze, nein, es macht mir
auch noch ausgesprochen Spaß. Allein schon die genialen Möglichkeiten
mit den Pointern, herrlich. Nur das computed goto hätten sie gerne noch
offiziell in den Standard aufnehmen können.
Meine Begeisterung erstreckt sich dabei allerdings nicht auf Stroustrups
total verunglückten Messiehaufen. :-)
Roland F. schrieb:> Lutz H. schrieb:>>> Mit möglichst wenig Zeichen auf einer Lochkarte viel zu programmieren.>> Das wusste ich gar nicht, wo kann man das mal nachlesen?
Natürlich nirgends, weil es Unsinn ist.
Lochkarten waren bei Großrechnern (Mainframes) üblich, UNIX ist auf
Minicomputern entstanden. Die hatten Fernschreiber als Terminals.
Allerdings waren die 100 Bd des Fernschreibers wohl in der Tat ein
limitierender Faktor, deshalb sind UNIX-Befehle recht kurz gehalten.
Kann im Prinzip natürlich auch sein, dass man deshalb auch lieber
einzelnen Klammern statt langer Wörter in der Programmiersprache
bevorzugt hat, darüber gibt es keine Überlieferung.
Lutz schrieb:> Was soll das eigentlich für eine Bedingung sein?
Da sparen ganz smarte C Programmierer Zeichen.
Es wird der Wahrheitswert von richtungA, HIGH getestet.
Es spart == high oder == low 7 Zeichen.
Bei alten Compilern ist irgend ein definierter Wert wahr oder falsch ,
und darauf wird getestet.
Lutz H. schrieb:> Lutz schrieb:>> Was soll das eigentlich für eine Bedingung sein?>> Da sparen ganz smarte C Programmierer Zeichen.
Unsinn, da hat nur jemand keine Ahnung
Lutz H. schrieb:> Es wird der Wahrheitswert von richtungA, HIGH getestet.
Nein, es wird der Wahrheitswert von HIGH getestet, RichtungA wird
nur zuvor evaluiert (was natürlich kaum irgendeinen Sinn haben kann).
Jörg W. schrieb:> Nein, es wird der Wahrheitswert von HIGH getestet, RichtungA wird> nur zuvor evaluiert (was natürlich kaum irgendeinen Sinn haben kann).
Meine ich es fehlt == um Ahnung zuhaben.
Es muss hingeschrieben werden, was gemacht werden soll und
da hilft dann die Entwicklungsumgebung mit Fehlermeldungen... .
Hallo,
auch die Arduino-IDE hilft mit den Fehlermeldungen, man muß sie eben
auch einschalten...
1
In file included from sketch\sketch_jan29a.ino.cpp:1:0:
2
3
D:\Arduino\sketch_jan29a\sketch_jan29a.ino: In function 'void loop()':
4
5
C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:40:14: warning: left operand of comma operator has no effect [-Wunused-value]
6
7
#define HIGH 0x1
8
9
^
10
11
D:\Arduino\sketch_jan29a\sketch_jan29a.ino:37:18: note: in expansion of macro 'HIGH'
12
13
if (richtungA, HIGH);
14
15
^
16
17
D:\Arduino\sketch_jan29a\sketch_jan29a.ino:37:23: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
18
19
if (richtungA, HIGH);
20
21
^
ist vom Sketch aus dem ersten Posting.
Gruß aus Berlin
Michael
Jörg W. schrieb:> Lutz H. schrieb:>> Es wird der Wahrheitswert von richtungA, HIGH getestet.>> Nein, es wird der Wahrheitswert von HIGH getestet
Naja, stimmt ja eigentlich beides. Der Wahrheitswert von richtungA, HIGH
ist nur der selbe wie der von HIGH. Der Wert, der in richtungA steht,
wird dazu eben nicht berücksichtigt.
Lutz H. schrieb:> Lutz schrieb:>> Was soll das eigentlich für eine Bedingung sein?>> Da sparen ganz smarte C Programmierer Zeichen.
Wenn das nur zum Sparen von Zeichen so da stünde, wäre das besser:
1
if(HIGH)
das hat nämlich den selben Effekt. Bzw. dank des Semikolons hätte die
Zeile auch ganz weggelassen werden können. Nein, das ist nicht zum
Sparen von Zeichen so geschrieben worden, sondern weil der TE nicht
wusste, wie es richtig wäre.
> Bei alten Compilern ist irgend ein definierter Wert wahr oder falsch ,> und darauf wird getestet.
Das ist auch bei neuen Compilern so.
Dussel schrieb:> Statsitiker schrieb:>> Dein Beitrag dagegen trifft den Zusammenhang überhaupt nicht, weil es>> nicht um "normale" Klammern geht, die die Reihenfolge von>> Rechenoperationen regeln, sondern um geschweifte Klammern, die böse>> Verwirrung stiften können, weil sie keine syntaktischen Fehler>> darstellen, sondern "nur" zu falschen Resultaten führen.> Wo können die denn Verwirrung stiften? Geschweifte Klammern werden> benutzt, um einen Block zu erzeugen. Ich hatte auch am Anfang ein paar> Probleme mit C, aber geschweifte Klammern haben nie dazugehört. Die> Initialisierung von Arrays ist ein komplett anderer und deutlich> unterschiedlicher Anwendungsbereich. Damit kann es also keine> Verwechslung geben.
Es ist doch nur der erste Beitrag zu lesen, einer der Fehler die
immerwieder, auch Profis passiert. Hier geht es doch nicht darum zu
sagen C wäre partout scheiße, sondern die Kritik am Designfehler der
universellen Blockbegrenzer "geschweifte Klammer". Ein Design mit
ausgeschriebenen, eindeutigen und zur Anweisung passenden
Blockbegrenzung würde derartige Fehler vermeiden helfen.
Das Pascal auf der anderen Seite wieder viel zu geschwätzig sein will
steht außer Frage. Ein gutes Design ist beispielsweise XOJO (llvm
backend)
Horst schrieb:> Ein Design mit ausgeschriebenen, eindeutigen und zur Anweisung passenden> Blockbegrenzung würde derartige Fehler vermeiden helfen.
Es hindert einen ja niemand daran, sowas zu machen:
#define BEGIN {
#define END }
;-)
