Forum: Compiler & IDEs was bedeutet: while(tmp & status);


von Ben S. (theben)


Lesenswert?

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?

von Peter (Gast)


Lesenswert?


von Helfer (Gast)


Lesenswert?

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.

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


Lesenswert?

Ist eine Kurzform für
1
  while ((tmp & status) != 0)
2
      /* wait */;

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

von thorstendb (Gast)


Lesenswert?

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.

von thorstendb (Gast)


Lesenswert?

Allerdings schreibe ich eher Ausdrücke wie:
1
if(pBuf) {
2
  ...
3
}
4
5
while(val & (1<<RX));

von Rolf Magnus (Gast)


Lesenswert?

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.

von 2ter gast (Gast)


Lesenswert?

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...

von thorstendb (Gast)


Lesenswert?

2ter gast schrieb:
> bei solchen sachen bevorzuge ich immer die EXPLIZITE eindeutige und
> längere Variante, denn z.B.if (a=b)
> {
> }

so was macht man nicht :-)

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


Lesenswert?

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)

von 2ter gast (Gast)


Lesenswert?

thorstendb schrieb:
> so was macht man nicht :-)

Ich hab schon vieles gesehen, was gemacht wird aber nicht nett ist.

hauptsache man gestaltet den programmcode lesbar, egal wie...

von Helfer (Gast)


Lesenswert?

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 );

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


Lesenswert?

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.

von Rolf Magnus (Gast)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.