¿Por qué los operadores bitwise tienen menor prioridad que las comparaciones?

Navega tus respuestas
61

¿Podría alguien explicar la razón, por qué en un grupo de los idiomas más populares (vea la nota a continuación) los operadores de comparación (==,! =, & lt ;, & gt ;, < =, > =) tienen mayor prioridad que bit a bit operadores (& amp ;, |, ^, ~)?

No creo que haya encontrado un uso donde esta precedencia sea natural. Siempre son cosas 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

Los casos en los que usaría: 

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

están cerca de ser inexistentes.

¿Cuál fue la motivación de los diseñadores de idiomas para decidir sobre la precedencia de los operadores?

Por ejemplo, todos excepto SQL en los 12 idiomas principales son así en la lista de popularidad del lenguaje de programación en langpop.com : C, Java, C ++, PHP, JavaScript, Python, C #, Perl, SQL, Ruby, Shell, Visual Basic.

    
pregunta SF. 11.04.2013 - 10:13

2 respuestas

69

Los lenguajes han copiado eso de C, y para C, Dennis Ritchie explica que inicialmente, en B (y quizás en la temprana C), solo había una forma & que, según el contexto, era bit a bit o lógica. Más tarde, cada función obtuvo su operador: & para bitwise y && for para lógico. Luego continúa

  

Su introducción tardía explica una infelicidad de las reglas de precedencia de C. En B se escribe 

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

para verificar si a es igual a b y c no es cero; en tal expresión condicional es mejor que & tenga una prioridad más baja que == . En la conversión de B a C, uno quiere reemplazar & por && en dicha declaración; para que la conversión sea menos dolorosa, decidimos mantener la precedencia del operador & de la misma manera que == , y simplemente dividir la precedencia de && ligeramente desde & . Hoy en día, parece que hubiera sido preferible mover las precedentes relativas de & y == , y así simplificar un lenguaje C común: para probar un valor enmascarado contra otro valor, uno debe escribir 

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

donde se requieren los paréntesis internos pero se olvidan fácilmente.

    
respondido por el AProgrammer 11.04.2013 - 13:21
7

Los operadores bitwise están relacionados con los operadores lógicos tanto conceptualmente como en apariencia, lo que probablemente explica por qué están cerca uno del otro en la tabla de precedencia. Quizás incluso se podría argumentar que sería confuso que & sea mayor que == , pero que && sea menor que == .

Una vez que se estableció un precedente (!), probablemente fue mejor que otros idiomas lo sigan por coherencia.

Sin embargo, tiendo a estar de acuerdo contigo en que esto no es óptimo. En uso real, los operadores de bits son más como operadores matemáticos que lógicos, y sería mejor si se agruparan con los operadores matemáticos en prioridad.

    
respondido por el user82096 11.04.2013 - 10:50

Lea otras preguntas en las etiquetas

¿Cuál es la historia del uso de "foo" y "barra" en los ejemplos de código fuente? ¿Qué tipo de problemas resuelve MapReduce?