was bedeutet: while(tmp & status);

OP #2079127
Hallo Leutz!

Ich versuche mich gerade in einen vorhandenen Programmcode für ein 
Grafikdisplay ein zu lesen.

da ist mir folgenene Schleife nicht geläufig:
1
while(tmp & status);

müsste es nich && heißen? Oder gibt es auch als einzelnes zeichen und 
was bedeutet es dann?
Gast
Der Bitoperator & wird in dieser Form benutzt, um bestimmte Bits mit der 
Bitmaske status in der Variable tmp abzufragen. tmp ist in solchen 
Warteschleifen (while(...)>;<) in der Regel als volatile 
gekennzeichnet.
Gast
Geschmackssache.

Ich finde es eher unlesbarer, if(val != 0) anstelle von if(val), weil 
man da mehr lesen und vor allem drei Ausdrücke interpretieren muss (val, 
!= und 0), statt einem.

Hab mich bei Lesen von C Code ziemlich auf Bools eingeschossen, zumal 
ich das bei Pointern immer verwende, die sind '0' oder gültig.

VG,
/th.
Gast
Jörg Wunsch schrieb:
> Ist eine Kurzform für
>
>   while ((tmp & status) != 0)
>       /* wait */;

Das wird aber so leider eine Warnung bei neueren GCCs verursachen, die 
sagt, daß man lieber geschweifte Klammern satt eines Semikolon verwenden 
soll.


> wobei ich persönlich die längere Form besser lesbar (weil offensicht-
> licher) finde.

Man kann auch eine andere Sichtweise haben: Wer die C-Regeln kennt, hat 
mit der kurzen Form auch kein Problem. Und wer sie nicht kennt, soll am 
besten gar nicht in meinen Code rumfuhrwerken.
Gast
bei solchen sachen bevorzuge ich immer die EXPLIZITE eindeutige und 
längere Variante, denn z.B.
1
if (a=b)
2
{
3
}
Es könnte  ja auch sein, dass der Programmierer auch
1
if (a==b)
2
{
3
}
meinte. IMHO sind solche Sachen fehlerträchtigt. Insbesondere wenn der 
Tag fortgeschritten ist...
Moderator Persönliche Seite
Rolf Magnus schrieb:

>>   while ((tmp & status) != 0)
>>       /* wait */;
>
> Das wird aber so leider eine Warnung bei neueren GCCs verursachen, die
> sagt, daß man lieber geschweifte Klammern satt eines Semikolon verwenden
> soll.

Seit welcher Version macht er das denn?

(Wobei es natürlich durchaus sinnvoll ist, Tippfehler dieser Art
haben wir wohl schon mehrmals hier im Forum sehen können.)

>> wobei ich persönlich die längere Form besser lesbar (weil offensicht-
>> licher) finde.
>
> Man kann auch eine andere Sichtweise haben: Wer die C-Regeln kennt, hat
> mit der kurzen Form auch kein Problem.

Das stimmt schon, ich finde nur, dass man länger hingucken muss, wenn
da gar kein Vergleichsoperator drin ist.  Aber es ist in der Tat
Geschmackssache.  Mein Geschmack ist hier möglicherweise auch durch
FreeBSD's style(9) mit modifiziert worden, welches folgende Regeln
aufstellt:

     Test pointers against NULL, e.g., use:

     (p = f()) == NULL

     not:

     !(p = f())

     Do not use ! for tests unless it is a boolean, e.g. use:

     if (*p == '\0')

     not:

     if (!*p)
Gast
Rolf:
> Das wird aber so leider eine Warnung bei neueren GCCs verursachen, die
> sagt, daß man lieber geschweifte Klammern satt eines Semikolon verwenden
> soll.

Die Klamer-Schreibweise gewöhne ich mir z.Zt. an, da ich sie in diesem 
Fall übersichtlicher finde als das einsame Semikolon
1
  while ( (tmp & status) != 0 ) {}
2

3
  while ( (tmp & status) != 0 );
Moderator Persönliche Seite
Helfer schrieb:

> Die Klammer-Schreibweise gewöhne ich mir z.Zt. an, da ich sie in diesem
> Fall übersichtlicher finde als das einsame Semikolon
>
>
1
>   while ( (tmp & status) != 0 ) {}
2
> 
3
>   while ( (tmp & status) != 0 );
4
>

Daher habe ich beim einzelnen Semikolon selbiges auch immer auf eine
Zeile für sich gesetzt und es mit einem Kommentar verziert, wie oben
gezeigt.  Allerdings kann der Compiler dort natürlich meine Absicht
nicht mehr erkennen, da ihm bereits der Präprozessor die Kommentare
geklaut hat und aufeinanderfolgende white space für ihn syntaktisch
wie ein einziger sind.  Das Klammerpaar hingegen schlägt noch im
Syntaxbaum auf.
Gast
Jörg Wunsch schrieb:
> Rolf Magnus schrieb:
>
>>>   while ((tmp & status) != 0)
>>>       /* wait */;
>>
>> Das wird aber so leider eine Warnung bei neueren GCCs verursachen, die
>> sagt, daß man lieber geschweifte Klammern satt eines Semikolon verwenden
>> soll.
>
> Seit welcher Version macht er das denn?

Hmm, gute Frage. Mir ist diese Warnung demletzt mal aufgefallen, aber 
ich kann sie gerade nicht reproduzieren. Wenn sie mir nochmal über den 
Weg läuft, sage ich bescheid.

>>> wobei ich persönlich die längere Form besser lesbar (weil offensicht-
>>> licher) finde.
>>
>> Man kann auch eine andere Sichtweise haben: Wer die C-Regeln kennt, hat
>> mit der kurzen Form auch kein Problem.
>
> Das stimmt schon, ich finde nur, dass man länger hingucken muss, wenn
> da gar kein Vergleichsoperator drin ist.  Aber es ist in der Tat
> Geschmackssache.

Ja.

>  Mein Geschmack ist hier möglicherweise auch durch
> FreeBSD's style(9) mit modifiziert worden, welches folgende Regeln
> aufstellt:
>
>      Test pointers against NULL, e.g., use:
>
>      (p = f()) == NULL
>
>      not:
>
>      !(p = f())

In diesem Fall kann ich das nachvollziehen. Wenn jetzt aber nur da 
steht:

       if (!p)

gegen

       if (p == NULL)

gefällt mir die erste Variante besser. Ich finde, sie liegt näher an 
dem, was man damit eigentlich meint ("kein Objekt"), als die zweite 
("Zeiger auf das Objekt ist gleich einem Nullzeiger).
Auch schön bei Strings:

    if (!string || !*string)

Wenn kein String oder String keinen Inhalt hat.

>      Do not use ! for tests unless it is a boolean, e.g. use:
>
>      if (*p == '\0')
>
>      not:
>
>      if (!*p)

Hier hätte ich früher immer die zweite Variante genommen, heute tendiere 
ich auch eher zur ersten.

Jörg Wunsch schrieb:
> Helfer schrieb:
>
>> Die Klammer-Schreibweise gewöhne ich mir z.Zt. an, da ich sie in diesem
>> Fall übersichtlicher finde als das einsame Semikolon
>>
>>>   while ( (tmp & status) != 0 ) {}
>>
>>   while ( (tmp & status) != 0 );
>>
> Daher habe ich beim einzelnen Semikolon selbiges auch immer auf eine
> Zeile für sich gesetzt und es mit einem Kommentar verziert, wie oben
> gezeigt.

Ich finde den Kommentar eher nicht so geschickt, weil das kleine 
Semikolon daneben etwas untergeht. Man muß zweimal hinsehen, um es zu 
finden. Wenn da wirklich ein einzelnes Semikolon mitten in der Zeile 
thront, kann man es nicht übersehen, und daß es nicht in der selben 
Zeile wie das while steht, reicht für mich, um zu erkennen, daß es 
Absicht war.

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 15 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.