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.
andre1a schrieb: > if (richtungA, HIGH); > > { > digitalWrite(laserPin,HIGH);// Anweisungsblock für wahr > delay(100); > } if (richtungA, HIGH) ///////// ; { digitalWrite(laserPin,HIGH);// Anweisungsblock für wahr delay(100); }
Copypaste-Programmieren, ja? Vielleicht hilft das ja: https://www.thalia.de/shop/home/rubrikartikel/ID45272569.html?ProvID=11000522
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...
"if-Befehl".. als nächstes kommt wohl die Frage, wann Ritchie es zwischen den Gigs mit Deep Purple eigentlich geschafft hat, C zu entwickeln.
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 ist größer
int i = 1;
i +=+ i++ + ++i;
oder
int i = 1;
i += i++ + ++i;
Programmieren lernen ist so einfach.
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.
:
Bearbeitet durch User
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
Roland F. schrieb: > Interessant, welche denn? > > rhf Mit möglichst wenig Zeichen auf einer Lochkarte viel zu programmieren.
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 einfach1 | 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
:
Bearbeitet durch User
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_t n; |
2 | n = 0x34; |
3 | {
|
4 | uint8_t n; |
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.
Angehängte Dateien:
-
Voreinstellungen.png
64 KB
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
:
Bearbeitet durch User
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
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...
:
Bearbeitet durch User
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.
int richtungA = 12; if (richtungA, HIGH); Was soll das eigentlich für eine Bedingung sein?
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.
:
Bearbeitet durch User
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... .
:
Bearbeitet durch User
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.
Hallo Jörg, Jörg W. schrieb: > Natürlich nirgends, weil es Unsinn ist. Das war mir schon klar, aber ich wusste nicht wie die Aussage gemeint war. rhf
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 } ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.