Forum: Mikrocontroller und Digitale Elektronik if befehl eingeben


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von andre1a (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Lutz H. (luhe)


Bewertung
0 lesenswert
nicht lesenswert
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);
   }

von THOR (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Copypaste-Programmieren, ja?

Vielleicht hilft das ja:

https://www.thalia.de/shop/home/rubrikartikel/ID45272569.html?ProvID=11000522

von Lutz H. (luhe)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Olaf B. (Firma: OBUP) (obrecht)


Bewertung
0 lesenswert
nicht lesenswert
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

von Erwin D. (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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...

von Nop (Gast)


Bewertung
1 lesenswert
nicht lesenswert
"if-Befehl".. als nächstes kommt wohl die Frage, wann Ritchie es 
zwischen den Gigs mit Deep Purple eigentlich geschafft hat, C zu 
entwickeln.

von Erwin D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von c-hater (Gast)


Bewertung
-14 lesenswert
nicht lesenswert
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...

von Mark B. (markbrandis)


Bewertung
5 lesenswert
nicht lesenswert
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.

von Uwe M. (andre1a)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Uwe M. (andre1a)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von c-hater (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
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.

von Manfred (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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"

von horst (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
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!!!!

von Walter S. (avatar)


Bewertung
8 lesenswert
nicht lesenswert
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

von Manfred (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
6 lesenswert
nicht lesenswert
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.

von Lutz H. (luhe)


Bewertung
-3 lesenswert
nicht lesenswert
was ist größer
           int i = 1;
            i +=+ i++ + ++i;
oder
           int i = 1;
            i += i++ + ++i;

Programmieren lernen ist so einfach.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
5 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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
von Lutz H. (luhe)


Bewertung
0 lesenswert
nicht lesenswert
Ja, ich habe mit dem +=+ provoziert. :-)

von Roland F. (rhf)


Bewertung
0 lesenswert
nicht lesenswert
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

von Roland F. (rhf)


Bewertung
0 lesenswert
nicht lesenswert
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

von Alter Lateiner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
if(Sensor == high) {Pumpe(an)}

oder so ähnlich...
Hilft das?

von Lutz H. (luhe)


Bewertung
0 lesenswert
nicht lesenswert
Roland F. schrieb:
> Interessant, welche denn?
>
> rhf

Mit möglichst wenig Zeichen auf einer Lochkarte viel zu programmieren.

von Michael U. (amiga)


Bewertung
-1 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
von Karl M. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Uwe M. (andre1a)


Bewertung
0 lesenswert
nicht lesenswert
habe es umgeschrieben und funktioniert.Vielen Dank nochmal.

von Statsitiker (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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.

von Michael U. (amiga)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
von Roland F. (rhf)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hein (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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 :-)

von Dussel (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Slippin J. (gustavo_f)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
0 lesenswert
nicht lesenswert
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
von Slippin J. (gustavo_f)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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. :-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Lutz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
int richtungA = 12;
if (richtungA, HIGH);

Was soll das eigentlich für eine Bedingung sein?

von Lutz H. (luhe)


Bewertung
-6 lesenswert
nicht lesenswert
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
von Walter S. (avatar)


Bewertung
4 lesenswert
nicht lesenswert
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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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).

von Lutz H. (luhe)


Bewertung
0 lesenswert
nicht lesenswert
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
von Michael U. (amiga)


Bewertung
0 lesenswert
nicht lesenswert
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

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Roland F. (rhf)


Bewertung
0 lesenswert
nicht lesenswert
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

von Horst (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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)

von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
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 }

;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.