While-Schleife in Assemblercode von GCC erzeugt.

Hallo Spess, hallo Peter,

ihr habt völlig recht.

Hatte absolut Tomaten auf den Augen. Aber manchmal sieht man eben vor 
lauter Bäumen den Wald nicht mehr.

Vielen Dank an euch!

Philipp S. schrieb:
> Hatte absolut Tomaten auf den Augen. Aber manchmal sieht man eben vor
> lauter Bäumen den Wald nicht mehr.

Deswegen schreibt man sowas ja auch nicht.
> while((ADCSRA & 0x40) == 1)
> while((ADCSRA & 0x40) != 0)

Sondern: while(ADCSRA & 0x40)

mfg.

Hallo Thomas,

da hast du völlig recht. Allerdings füge ich einen Timeout in die 
While-Schleife ein. Und weil daher ein weiteres Abbruchkriterium 
dazukommt, dachte ich, dass es übersichtlicher gewesen wäre.


Um diejenigen, die zufällig auf diesen Beitrag stoßen, nicht im Unklaren 
über den von mir gemachten Fehler zu lassen:

1

while((ADCSRA & 0x40) == 1); //Wird NIEMALS erfüllt

2

3

while((ADCSRA & 0x40) == 0x40); //Würde funktionieren besser ist aber die Lösung von Thomas Eckmann

So gehts auch:

1

while(!!(ADCSRA & 0x40) == 1)

Das !! macht aus Wahr eine 1.

Peter

Peter Dannegger schrieb:
> So gehts auch:

Macht man aber nur, wenn man einen Beitrag beim IOCCC einreichen
möchte. :-)

Jörg Wunsch schrieb:
> Macht man aber nur, wenn man einen Beitrag beim IOCCC einreichen
> möchte. :-)

Nö.

Es kann sein, daß das 0x40 nicht direkt im Text steht, sondern ein 
Define irgendwo ist.
Und nicht ein While den Ausdruck auswertet, sondern er als Returnwert 
von einer anderen Funktion irgendwo auswertet wird.
Dann ist das !! schon sinnvoll, um immer den Wert TRUE zu erzwingen, 
egal welche Bitposition geprüft wird.

1

#define BLA 0x40

2

// nen Haufen Code ...

3

uint8_t testbla()

4

{

5

// Code ...

6

  return !!(blablub & BLA);

7

}

8

// nen Haufen Code ...

9

  var += testbla();

Peter

Philipp S. schrieb:

> Um diejenigen, die zufällig auf diesen Beitrag stoßen, nicht im Unklaren
> über den von mir gemachten Fehler zu lassen:

Man kann deinen Fehler so zusammenfassen:

       ungleich 0
  und  gleich 1
sind nicht dasselbe

Wie man sich leicht klar machen kann. 2 ist zwar ungleich 0 (diese 
Fragstellung würde man als mit wahr beantworten), aber 2 ist nicht 
gleich 1 (diese Fragestellung würde man also mit falsch beantworten).

In C ist weniger oft mehr. Da im while bzw. im if die Bedingung 
'ungleich 0' schon implizit mit drinnen steckt(*), lässt man als 
Programmierer den am besten weg (wenn es nicht um eine extreme Betonung 
dieses Sachverhalts geht). Alles was man weglassen kann, kann auch nicht 
zu einem Tippfehler führen.

(*) dies ist so zu verstehen, dass while (oder auch if) sich nicht dafür 
interessieren, dass in ihren Klammern ein logischer Ausdruck mit einem 
boolschen Ergebnis steckt. Sie nehmen einfach den angegebenen Ausdruck, 
werten ihn aus und bewerten dieses Ergebnis nach den Regeln der Sprache 
für logische Ausdrücke.

D.h. bei
   while( x )
geht es nicht um den konkreten Aufbau dieses x. Das muss kein Ausdruck 
sein, in dem ein Vergleichsoperator vorkommt. Das ist in C nicht 
gefordert (in anderen Sprachen ist das anders!). Aus Sicht des while ist 
das einfach nur ein arithmetischer Ausdruck, dessen Ergebnis auf "0 oder 
nicht 0" untersucht wird. Ist er nicht 0, dann wird die Schleife 
(erneut) betreten.

In diesem Sinne ist
  while( x != 0 )
eigentlich doppelt gemoppelt. Denn das Ergebnis des Ausdrucks
   x != 0
ist seinerseits wieder eine Zahl: 0 wenn der Vergleich nicht zutrifft 
und 1 wenn der Vergleich zutrifft. Wenn das while daher das Ergebnis 
dieses Vergleichs prüft, dann stellt man fest, dass dieses Ergebnis 
immer mit dem Ergebnis des explizit hingeschriebenen Vergleiches 
übereinstimmt. D.h. diese Schreibweise mit dem expliziten != Vergleich 
ist in allen Belangen identisch zu

   while( x )

Nun kann es natürlich sein, dass man als Programmierer hier eine 
spezielle Betonung auf den Umstand des 'ungleich 0' legen will und dann 
schreibt man den Vergleich auch explizit an. Aber im Grunde ist er nicht 
notwendig, so wie bei

   i = 1 * k;

die Multiplikation mit 1 nicht notwendig ist. Und die schreibt man ja 
auch nicht explizit an, es sei denn man will da eine Betonung drauf 
legen.


Also keine Scheu

  if( PINC & ( 1 << PB4 ) )

ist perfektes C, an dem es erst mal nichts auszusetzen gibt. Es ist 
genauso logisch einwandfrei, wie

   if( isCursorVisible() )
     ...

einwandfrei ist. Denn in dieser Situation würde wohl kaum jemand

   if( isCursorVisible() != FALSE )

schreiben. Ganz im Gegenteil, würde wohl hier der zusätzliche Vergleich 
die meisten Programmierer stutzig machen und sie würden sich fragen, 
warum der da steht und ob es da wohl irgendwelche Sonderfälle gibt, die 
sie nur einfach nicht durchschauen.

In diesem Sinn:
* Vergleichsoperatoren sind in C auch nichts anderes als arithmetisch 
logische Operatoren. Sie bewerten ihr linkes Argument, bewerten ihr 
rechtes Argument, führen die Aktion durch und haben ein numerisches 
Ergebnis. Konzeptionell identisch zu den Operatoren +, -, *, /, |, .... 
und wie sie sonst alle heißen.

* In C ist weniger oft mehr.

Philipp S. schrieb:
> Und weil daher ein weiteres Abbruchkriterium
> dazukommt, dachte ich, dass es übersichtlicher gewesen wäre.
Finde ich nicht.

while((ADCSRA & 0x40) & !timeout);

Peter Dannegger schrieb:
> Das !! macht aus Wahr eine 1.
Nö.
Wahr, also true, ist immer 1. Das !! macht aus !0 eine 1.

Karl Heinz Buchegger schrieb:
> ist perfektes C, an dem es erst mal nichts auszusetzen gibt.
MISRAtene Normungspopanze regen sich da aber schon drüber auf.

mfg.

Thomas Eckmann schrieb:

>> ist perfektes C, an dem es erst mal nichts auszusetzen gibt.
> MISRAtene Normungspopanze regen sich da aber schon drüber auf.

:-)
Zum Thema MISRA: Blödeln wir rum oder programmieren wir?

(Du kennst sicherlich meine Einstellung zu MISRA. :-) )

Karl Heinz Buchegger schrieb:
> (Du kennst sicherlich meine Einstellung zu MISRA. :-) )
Sonst hätte ich das auch nicht geschrieben.

mfg.

Thomas Eckmann schrieb:
> while((ADCSRA & 0x40) & !timeout);

Oi oi oi. :-)

Peter Dannegger schrieb:
> Dann ist das !! schon sinnvoll, um immer den Wert TRUE zu erzwingen,
> egal welche Bitposition geprüft wird.

Da finde ich aber ((ADCSRA & 0x40) != 0) allemal besser verständlich.
Das erzwingt auch den Wert 1, unabhängig von der Bitposition, und
man kann es lesen, ohne erst drüber nachdenken zu müssen. ;-)