|
Anzeige
|
zuweisung mit Vergleichsoperator
Gast
#6414111
Hallo in die Runde, Frage zu diesem Code-Segment:
Die Zeile mit der Zuweisung an n verstehe ich nicht. Die Funktion canix_rxq_size() ist so definiert, dass sie ein uint8_t zurück gibt. Also wir dieser Rückgabewert an n zugewiesen. Aber welche Auswirkung hat "> 0" in dieser Zeile? Viele Grüße, Uli
Gast
#6414122
In n steht das Ergebnis des bool’schen Vergleichs von canix_rxq_size() > 0
Gast
#6414146
Erst wird der Ausdruck auf der rechten Seite ausgewertet, und dann das Ergebnis zugewiesen. Ich schreibe da auch gern mal:
Gast
#6414160
Uli schrieb: > bool can_message_available(void) > { > uint8_t n; > > cli(); > n = canix_rxq_size() > 0; > sei(); > > return n; > } Wer so etwas schreibt, ist doppelt blöd: erstens ist 'n' für diesen Zweck ziemlich ungeschickt, da denkt man automatisch an eine Zahl. Zweitens, und das ist eine unmittelbare Konsequenz, kommt man dadurch bei der Zuweisung ins Schleudern, man fragt sich sofort, ob '(n = canix_rxq_size()) > 0;' oder 'n = (canix_rxq_size() > 0);' gemeint ist. Wesentlich geschickter wäre: bool can_message_available(void) { uint8_t is_available; cli(); is_available = (canix_rxq_size() > 0); sei(); return is_available; } Das mehr an Tipparbeit rentiert sich auf lange Sicht, denn wenn man ein paar Wochen später noch mal dahin schaut, muss man bei der urspr. Variante selbst erst man überlegen, was für einen Murks man da angerichtet hat.
Gast
#6414183
es sei noch angemerkt, dass der Typ bool ja existiert und durchaus für n oder is_available verwendet werden kann. Selbst wenn das nicht so performant sein mag, weil bool 16 oder 32 Bit ist. Wenn man es nicht gemessen hat, ist es zweifelhaft, dass es langsamer ist. Und wenn man es gemessen hat, sollte man das im Kommentar berücksichtigen (Achtung: uint8_t weil es 4 Takte länger sind in der Version 1.0 des Kompilers und die Routine pro Sekunde 11 mal aufgarufen wird!)
Gast
#6414308
Danke für eure Info. Es ist mir jetzt klar, allerdings war die Schreibweise für mich eher unübersichtlich. Uli Uli schrieb: > Es ist mir jetzt klar, allerdings war die Schreibweise für mich eher > unübersichtlich. Diese Schreibweise hätte den gleichen Effekt:
Wenn Du das lesbarer findest (ich persönlich sehe das so), dann benutze das. Der resultierende Assembler-Code dürfte derselbe sein. P.S. Ähnlich sähe es aus, wenn man n wirklich als Bool definiert, welches ja auch der Typ des Rückgabewertes der Funktion ist. Hier könnte man dann 0 und 1 durch die entsprechenden Wahrheitswerte austauschen. Unter C hat jeder Ausdruck einen Wert. Man kann ihn daher einer Variablen zuweisen oder mit if, while, for direkt testen ob der Wert nicht 0 ist. Implizit lautet ein if ausgeschrieben:
Gast
#6414433
A. B. schrieb: > Zweitens, und das ist eine unmittelbare Konsequenz, kommt man dadurch > bei der Zuweisung ins Schleudern, man fragt sich sofort, ob '(n = > canix_rxq_size()) > 0;' oder 'n = (canix_rxq_size() > 0);' gemeint ist. Was sollte denn (n = canix_rxq_size()) > 0; bewirken? Dann hätte man einen Vergleich, dessen Ergebnis nicht ausgewertet wird. Damit wäre der Vergleich unsinnig. Persönlich mag ich diese Schreibweise, weil sie so schön Nerd/Hacker-mäßig aussieht, aber in der praktischen Anwendung würde ich die nicht empfehlen. n = canix_rxq_size() ? 1:0; (Könnt aber die längste Variante sein!?) Was spricht eigentlich gegen n = (bool) canix_rxq_size(); ?
Gast
#6414472
Teo D. schrieb: > Was spricht eigentlich gegen > n = (bool) canix_rxq_size(); Es muss nicht sein, dass bool binär ist. Es kann auch ein int oder uint8 oder sonstwas in einer C-Version ohne bool sein und liefert dann nicht 0 oder 1 zurück. Alternativ (wenn ggf negativ auch true ist) n=!!canix_rxq_size(); Uli schrieb: > Es ist mir jetzt klar, allerdings war die > Schreibweise für mich eher unübersichtlich. Rechts vom "=" steht ein Ausdruck, und dessen Wert wird n zugewiesen. Ob das unübersichtlich ist, ist eine Frage der Gewohnheit. Ich persönlich bevorzuge die platzsparende Alternative gegenüber dem länglichen if-else. Sinnvoller als der Einsatz wie im Beispiel ist bei komplexeren Abfragen wie
In dem Fall sind Klammern um die Bedingungen erforderlich. Bei einer einzigen Bedingung Klammern für bessere Übersichtlichkeit zu setzen kann man machen; aber wie oben mangelnde Sprachkenntnis als Begründung für Klammersetzung anzuführen ist einer der schlechtesten Argumente überhaupt. Und ob man bei meinem Beispiel über eine Zwischenvariable geht oder
verwendet, ist natürlich dem Coding Style überlassen. Wenn die Bedingungen komplexer sind, kann man auch auf mehrere Zeilen aufteilen:
Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
