www.mikrocontroller.net

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


Autor: Ben S. (theben)
Datum:

Bewertung
0 lesenswert
nicht 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:
while(tmp & status);

müsste es nich && heißen? Oder gibt es auch als einzelnes zeichen und 
was bedeutet es dann?

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Helfer (Gast)
Datum:

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

Beitrag #2079150 wurde vom Autor gelöscht.
Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist eine Kurzform für
  while ((tmp & status) != 0)
      /* wait */;

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

Autor: thorstendb (Gast)
Datum:

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

Autor: thorstendb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Allerdings schreibe ich eher Ausdrücke wie:
if(pBuf) {
  ...
}

while(val & (1<<RX));

Autor: Rolf Magnus (Gast)
Datum:

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

Autor: 2ter gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei solchen sachen bevorzuge ich immer die EXPLIZITE eindeutige und 
längere Variante, denn z.B.
if (a=b)
{
}
Es könnte  ja auch sein, dass der Programmierer auch
if (a==b)
{
}
meinte. IMHO sind solche Sachen fehlerträchtigt. Insbesondere wenn der 
Tag fortgeschritten ist...

Autor: thorstendb (Gast)
Datum:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: 2ter gast (Gast)
Datum:

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

Autor: Helfer (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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
  while ( (tmp & status) != 0 ) {}

  while ( (tmp & status) != 0 );

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Rolf Magnus (Gast)
Datum:

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

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.