Hallo
Mit diesem kleinen Programm möchte ich "wert" auf min. 0 begrenzen.
1
wert=100;
2
if(!(PINA&(1<<PINA7)))
3
{
4
if(wert>0);
5
{
6
wert=wert-10;
7
}
8
if(wert<=0)
9
{
10
wert=5;
11
}
12
_delay_ms(1);
13
}
Mit dem drücken des Tasters wird wert um -10 gemacht. Stelle ich
if(wert<11)
dann funktioniert es. Bei kleineren Zahlen geht es sofort in -.
Sorry, bin Anfänger und versuche es zu verstehen.
LG
utoa(grad,grade,10);// Berechne Wert von OCR1B für Winkel
21
lcd_printlc(4,3,"Grad =");
22
lcd_printlc(4,11," ");
23
lcd_printlc(4,12,grade);
Die Anzeige der Werte erfolgt mit utoa korrekt, ebenfalls die Bgrenzung
nach oben auf 2890. Wenn ich 0 erreiche geht es in den negativen
Bereich.
OCR1B kann doch nur 0 -3999 haben (Timer 16 Bit mit 16MHz Quarz auf
20ms)
Es geht dabei nur um die Begrenzung von OCR1B auf 0.
Der Bastler schrieb:> if(OCR1B > 0);Wie Udo S. schrieb:> was soll hier das Semikolon hinter der Bedingung?
Mit dem Semicolon ist die if-Abfrage beendet. Da steht also eigentlich
sowas:
Udo S. schrieb:> was soll hier das Semikolon hinter der Bedingung?
Damit soll die IF Anweisung sofort beendet werden, damit der
nachfolgende Code auf jeden Fall ausgeführt wird.
Und dieser Nachfolgenden Anweisungsblock solle einen eigenen unbenutzten
Namensraum/Geltungsbereich öffnen.
(wozu auch immer)
EAF schrieb:> Damit soll die IF Anweisung sofort beendet werden, damit der> nachfolgende Code auf jeden Fall ausgeführt wird.
Ich weiss das, aber das "soll" war wohl eher ein "Uuups".
Der Bastler schrieb:> Brauche wohl doch bald eine Brille.
Den Fehler hat jeder der meint C zu können schon gesucht. Und zwar mehr
als einmal.
Ist also keine Schande
Udo S. schrieb:> was soll hier das Semikolon hinter der Bedingung?
Scharfer Blick, nicht schlecht!
Und ein schönes Beispiel für eine völlig verrückte Programmiersprache,
die solchen Unfug zulässt.
Jeden Tag aufs Neue ein Wunder, dass unsere Welt noch immer
zusammenhält, irgendwie zumindest, wenn man sich überlegt, mit welchen
mistigen Sprachen Software gebaut wird. Wahnsinn.
Seit wann kann ein OCR negativ werden?
Du solltest eine Dummy-Variable nutzen und nach der Versrbeitung dem
Register zuweisen, dubble-buffered oder in Software timersynchron
Stefan ⛄ F. schrieb:> Müsste die IDE nicht an dieser Stelle eine Warnung anzeigen?
Anweisungen und auch Anweisungsblocks dürfen leer sein.
Also nein.
Kann/wird sich allerdings ändern.
z.B. while(1);
EAF schrieb:> Anweisungen und auch Anweisungsblocks dürfen leer sein.
Ist mir schon klar. Von einer zeitgemäßen IDE erwarte ich trotzdem
solche Hilfestellungen.
Stefan ⛄ F. schrieb:> Müsste die IDE nicht an dieser Stelle eine Warnung anzeigen?
Ein statisches Code Analyse Tool schaut nochmal ganz anders als ein
Compiler.
Probier das Beispiel Mal hier aus:
https://www.gimpel.com/demo.html
Das kommt eine Warnung "If Statement has empty Body..." und ähnliches.
Helge schrieb:> ein compiler ist doch keine "Mutti" :-)
Wer solche Warnungen unterdrückt oder ignoriert ist von Mutti wohl zu
heiß gebadet worden. Da muss dann der Compiler Ran.
EAF schrieb:> Stefan ⛄ F. schrieb:>> Müsste die IDE nicht an dieser Stelle eine Warnung anzeigen?>> Anweisungen und auch Anweisungsblocks dürfen leer sein.> Also nein.
Natürlich darf da trotzdem gewarnt werden. Es wird an vielen Stellen
gewarnt, die zwar laut Sprachdefinition korrekt wären, aber so aussehen,
als seien sie so nicht gedacht. Ein if ohne etwas, das dann auch
abhängig von der Bedingung ausgeführt wird, gehört da eigentlich dazu,
denn es gibt keinen sinnvollen Grund, sowas zu machen.
> Kann/wird sich allerdings ändern.> z.B. while(1);
Das ist aber was ganz anderes.
Stefan ⛄ F. schrieb:> Müsste die IDE nicht an dieser Stelle eine Warnung anzeigen?
In C?
Warum sollte eine leere Anweisung verboten sein?
Die Syntax-Regeln erlauben soviel logische Sch..ße zu bauen ...
Warnungen sind der verzweifelte Versuch dem C die
Assemblernähe/-freiheit auszutreiben
Jürgen S. schrieb:> und man vorausschauen rechnen sollte?
Nicht nötig, wenn man es hinterher wieder zurechtflickt:
1
if(wert<=0)
2
wert=5;
Aber richtig: sowas deutet darauf hin, dass woanders wahrscheinlich auch
noch eigenartige Stellen im Code sind.
Ich hätte diesen Programmabschnitt annähernd funktionsgleich etwa so
geschrieben:
1
if(wert>15)wert-=10;
2
elsewert=5;
Und dann auch gleich das rechenzeitverschwendende _delay_ms()
weggelassen.
Jürgen S. schrieb:> Kann es sein, dass das nicht ganz stimmt und man vorausschauen rechnen> sollte?>> IF ( (Wert-10) <0( THEN wert = 0> ELSE Wert = Wert - 10
Das unterscheidet sich vom vorherigen Code nicht wirklich, außer dass
die Subtraktion jetzt zweimal durchgeführt wird. Welchen Vorteil hat das
deiner Ansicht nach?
Beide Varianten haben den Nachteil, dass sie erfordern, dass wert
vorzeichenbehaftet ist, obwohl es im Normalfall immer größer als 0 ist.
Deshalb würde ich diese Variante bevorzugen:
Lothar M. schrieb:> if (wert > 15) wert -= 10;> else wert = 5;
Man könnte noch die magischen Werte ersetzen:
Helge schrieb:>> Von einer zeitgemäßen IDE erwarte ich trotzdem solche Hilfestellungen> ein compiler ist doch keine "Mutti" :-)
Ich habe "IDE" geschrieben, nicht "Compiler".
Forist schrieb:> Warum sollte eine leere Anweisung verboten sein?
Es geht nicht um "verboten", sondern um "wahrscheinlich so nicht
gewollt". Von meinen Entwicklungsumgebungen bin ich entsprechende
Warnhinweise gewohnt.
Auch z.B. wenn man einen switch/case schreibt, in dem ein wahrscheinlich
case vergessen wurde. Oder wenn man eine Variable liest, bevor man sie
beschrieben hat.
Stefan ⛄ F. schrieb:> Auch z.B. wenn man einen switch/case schreibt, in dem ein wahrscheinlich> case vergessen wurde. Oder wenn man eine Variable liest, bevor man sie> beschrieben hat.
Gerade bei dem switch/case nervt es aber auch. Bei mir kommt es da schon
mal öfters vor, dass nicht alle Werte abgefragt werden, weil es an der
Stelle einfach keinen Sinn ergibt. Dann steht halt im Code sowas:
1
switch(...)
2
{
3
...
4
default:
5
;// shut up stupid GCC warning
6
}
So ein nutzloser leerer default wäre dann eigentlich viel eher das, wo
ich mir stattdessen eine Warnung wünschen würde.
Klaus H. schrieb:> Stefan ⛄ F. schrieb:>> Müsste die IDE nicht an dieser Stelle eine Warnung anzeigen?>> Mit der richtigen Option meckert der (gcc) Compiler> if (x<0);> //src/main.cpp:16:13: warning: suggest braces around empty body in an> 'if' statement [-Wempty-body]
Lustige Warnung. Der Inhalt klingt irgendwie unsinnig. Der Compiler
schlägt also vor, das zu ändern in:
Rolf M. schrieb:> Warum ist das jetzt besser?
Weil jetzt viel eher auffällt, dass der Anweisungsblock der if-Bedingung
leer ist. Das Semikolon im ersten Beitrag des TO hab' ich auch erst
nicht gesehen.
rossi schrieb:> Rolf M. schrieb:>> Warum ist das jetzt besser?>> Weil jetzt viel eher auffällt, dass der Anweisungsblock der if-Bedingung> leer ist. Das Semikolon im ersten Beitrag des TO hab' ich auch erst> nicht gesehen.
Die Klammern machen das if aber auch nicht weniger überflüssig.
Der Bastler schrieb:> Udo S. schrieb:>> was soll hier das Semikolon hinter der Bedingung?>> Danke, das war der Fehler. Brauche wohl doch bald eine Brille.
Wäre mit Python nicht passiert.
Rolf M. schrieb:> Die Klammern machen das if aber auch nicht weniger überflüssig.
Leutens, jetzt nicht am Thema vorbei diskutieren:
Es ging um das Aufdecken eines Semikolon zwischen if Bedingung und
nachfolgender Klammerung.
1
if(wert>0);// warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
Rolf M. schrieb:> if (x<0){;}> Warum ist das jetzt besser?
Weil man so etwas nicht aus Versehen hin schreibt. Wenn das so im Code
steht, war es mit Sicherheit Absicht.
Mir ging es eigentlich darum, dass man das auch nicht mit Absicht
hinschreibt. Also könnte der Compiler, statt zusätzlicher Klammern
vorzuschlagen, einfach sagen, dass da ein if ohne Inhalt steht.
Rolf M. schrieb:> Also könnte der Compiler, ... vorzuschlagen
Ich sehe es wie Helge
Helge schrieb:> ein compiler ist doch keine "Mutti"
Diese ganzen Checks gehören meiner Meinung nach in ein separates
Programm ausgelagert welches in die IDE eingebunden ist. Die Zeiten wo
mir mit Edlin programmierten sind nämlich vorbei.
Rolf M. schrieb:> Mir ging es eigentlich darum, dass man das auch nicht mit Absicht> hinschreibt. Also könnte der Compiler, statt zusätzlicher Klammern> vorzuschlagen, einfach sagen, dass da ein if ohne Inhalt steht.
Hat er ja ;-) - Als Bestätigung, dass man das so wollte, wurden die
Klammern 'ausgemacht'.
Sowas ähnliches:
> Warum ist das jetzt besser?
Weil damit angezeigt wird, dass dieser Schwachsinn, so schwachsinnig er
auch ist (und immer bleiben wird) BEABSICHTIGT ist. Es ist schlicht sehr
einfach, versehentlich ein ";" zu schreiben, aber schon sehr viel
unwahrscheinlicher, versehentlich ein "{;}" zu schreiben.
Das eigentliche Ziel ist also, sehr wahrscheinlich nicht so gewollte
Sachen nochmal zum Nachdenken vorzulegen. Und der Vorschlag dient dazu,
für den unwahrscheinlichen Fall, dass der Schwachsinn doch beabsichtigt
war, die Warning für die Zukunft nicht mehr erscheinen zu lassen. Der
Schwachsin darf also Bestand haben, wenn es denn wirklich so gewollt
ist. Wozu auch immer...
Aber wer würde sich mit den richtigen C-Cracks auf eine Sinndiskussion
einlassen? Das ist genauso nutzlos, wie mit erz-islamischen Taliban über
Frauenrechte zu streiten oder mit dem Papst über den Sinn des Zölibats.
Eiferer jeder Coleur, die ihren ganzen Lebensinhalt darin sehen, eine
"Schrift" möglichst wortgenau zu befolgen, sind einfach keine dankbaren
Diskussionspartner.
Thread beobachten
Seitenaufteilung abschalten