it-swarm.com.de

Warum haben bitweise Operatoren eine niedrigere Priorität als Vergleiche?

Könnte jemand die Gründe erklären, warum in einer Reihe der beliebtesten Sprachen (siehe Hinweis unten) Vergleichsoperatoren (== ,! =, <,>, <=,> =) Eine höhere Priorität haben als bitweise Operatoren (&, |, ^ , ~)?

Ich glaube nicht, dass ich jemals auf eine Verwendung gestoßen bin, bei der dieser Vorrang natürlich wäre. Es ist immer so:

  if( (x & MASK) == CORRECT ) ...   // Chosen bits are in correct setting, rest unimportant

  if( (x ^ x_prev) == SET )      // only, and exactly SET bit changed

  if( (x & REQUIRED) < REQUIRED )   // Not all conditions satisfied

Die Fälle, in denen ich verwenden würde:

  flags = ( x == 6 | 2 );     // set bit 0 when x is 6, bit 1 always.

sind fast nicht vorhanden.

Was war die Motivation der Sprachdesigner, sich für einen solchen Vorrang der Operatoren zu entscheiden?


Zum Beispiel sind alle außer SQL in den Top-12-Sprachen wie folgt auf Programmiersprachen-Popularität Liste bei langpop.com: C, Java, C++, PHP, JavaScript, Python, C #, Perl, SQL, Ruby , Shell, Visual Basic.

63
SF.

Sprachen haben das von C kopiert, und für C hat Dennis Ritchie erklärt , dass es anfangs in B (und vielleicht im frühen C) nur eine Form & Gab, die je nach Kontext zutraf eine bitweise und oder eine logische. Später erhielt jede Funktion ihren Operator: & Für die bitweise und && Für die logische. Dann fährt er fort

Ihre verspätete Einführung erklärt eine Infelizität der Vorrangregeln von C. In B schreibt man

if (a == b & c) ...

um zu überprüfen, ob a gleich b ist und c ungleich Null ist; In einem solchen bedingten Ausdruck ist es besser, dass & eine niedrigere Priorität hat als ==. Bei der Konvertierung von B nach C möchte man in einer solchen Anweisung & Durch && Ersetzen. Um die Konvertierung weniger schmerzhaft zu machen, haben wir beschlossen, die Priorität des Operators & relativ zu == beizubehalten und lediglich die Priorität von && geringfügig von &. Heute scheint es vorzuziehen gewesen zu sein, die relativen Prioritäten von & Und == Zu verschieben und dadurch ein gemeinsames C-Idiom zu vereinfachen: Um einen maskierten Wert gegen einen anderen Wert zu testen, muss geschrieben werden

if ((a & mask) == b) ...

wo die inneren Klammern benötigt werden, aber leicht vergessen werden.

72
AProgrammer

Bitweise Operatoren beziehen sich sowohl konzeptionell als auch optisch auf logische Operatoren, was wahrscheinlich erklärt, warum sie in der Prioritätstabelle nahe beieinander liegen. Vielleicht könnte man sogar argumentieren, dass es für & höher sein als ==, noch && niedriger sein als ==.

Sobald ein Präzedenzfall (!) Festgelegt wurde, war es wahrscheinlich besser für andere Sprachen, ihm aus Gründen der Konsistenz zu folgen.

Ich stimme Ihnen jedoch eher zu, dass dies nicht optimal ist. In der tatsächlichen Verwendung ähneln Bitoperatoren eher mathematischen als logischen Operatoren, und es wäre besser, wenn sie vorrangig mit den mathematischen Operatoren gruppiert würden.

7
user82096