Por que os operadores bit a bit têm menor prioridade que as comparações?

Question

Por que os operadores bit a bit têm menor prioridade que as comparações?

#1 resposta do (69 votos)
#2 resposta do (7 votos)

61

Alguém poderia explicar a lógica, porque em um monte de linguagens mais populares (veja nota abaixo) os operadores de comparação (==,! =, & lt ;, & gt ;, < =, > =) têm maior prioridade do que bit a bit operadores (& amp ;, |, ^, ~)?

Acho que nunca encontrei um uso em que essa precedência fosse natural. É sempre coisas como:

  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

Os casos em que eu usaria:

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

estão quase inexistentes.

Qual foi a motivação dos designers de linguagem para decidir sobre tal precedência de operadores?

_{Por exemplo, todos, exceto o SQL nos 12 idiomas principais, são semelhantes à lista de Popularidade da Linguagem de Programação em langpop.com : C, Java, C ++, PHP, JavaScript, Python, C #, Perl, SQL, Ruby, Shell, Visual Basic.}

syntax language-design operators operator-precedence bitwise-operators

por SF. 11.04.2013 / 10:13

fonte

2 respostas

7

Operadores bitwise estão relacionados a operadores lógicos tanto conceitualmente quanto na aparência, o que provavelmente explica por que eles estão próximos um do outro na tabela de precedência. Talvez alguém possa argumentar que seria confuso para & ser maior que == , ainda que && seja menor que == .

Uma vez que um precedente de precedência (!) foi definido, provavelmente seria melhor que outras linguagens o seguissem por questões de consistência.

No entanto, eu costumo concordar com você que isso não é o ideal. No uso real, os operadores de bits são mais parecidos com operadores matemáticos do que lógicos, e seria melhor se eles fossem agrupados com os operadores matemáticos em precedência.

por 11.04.2013 / 10:50

fonte

Tags syntax language-design operators operator-precedence bitwise-operators

Quais estressores os programadores encontram no trabalho e como você lida com eles? [fechadas] Crie meu próprio sistema de banco de dados [fechado]

score 69 · Accepted Answer

Idiomas copiaram isso de C, e para C, Dennis Ritchie explica que inicialmente, em B (e talvez no início C), havia apenas uma forma & que, dependendo do contexto, era bit a bit e / ou lógica. Posteriormente, cada função obteve seu operador: & para o bit a bit e && para o um lógico. Então ele continua

Their tardy introduction explains an infelicity of C's precedence rules. In B one writes
if (a == b & c) ...
to check whether a equals b and c is non-zero; in such a conditional expression it is better that & have lower precedence than ==. In converting from B to C, one wants to replace & by && in such a statement; to make the conversion less painful, we decided to keep the precedence of the & operator the same relative to ==, and merely split the precedence of && slightly from &. Today, it seems that it would have been preferable to move the relative precedences of & and ==, and thereby simplify a common C idiom: to test a masked value against another value, one must write
if ((a & mask) == b) ...
where the inner parentheses are required but easily forgotten.