En el lenguaje de programación C, ¿por qué los operadores bit a bit (& y |) tienen menor prioridad que el operador de igualdad (==)? No tiene sentido para mí.Prioridad del operador (bit a bit 'y' menor que '==')
Necesitas preguntarle a Brian Kernighan o Dennis Ritchie.
Desde este foro: http://bytes.com/topic/c/answers/167377-operator-precedence
El & & y || los operadores se agregaron más tarde por su comportamiento de "cortocircuito". Dennis Ritchie admite en que la precedencia de los operadores bit a bit debería tener cambiado cuando se agregaron los operadores lógicos. Sin embargo, con varios cientos de kilobytes de código fuente C en existencia en ese punto y una base instalada de tres ordenadores, Dennis pensó que sería demasiado grande de un cambio en el lenguaje C ...
Por lo tanto, esa podría ser una razón? Supongo que, dado que hay varias capas de precendencia bit a bit (a diferencia de las comparaciones relacionales), es un error que existió desde ... para siempre ... y simplemente nunca fue corregido.
Maldito. Perdido por la pereza: ( –
) Esa cita está mal citada. Dennis Ritchie lo explica en su artículo "Chistory", que [puede leer aquí] (http://cm.bell-labs.co/who/dmr/chist. html). En mi opinión, la redacción de Ritchie es mucho mejor.Ritchie se arrepintió de tener la precedencia como tal, pero fue hecho para tener una mínima fricción de conversión del lenguaje B, el predecesor de C, cuando estaba formando el lenguaje C. B solo admitía '&' en las celdas y no tenía un operador booleano explícito debido a la falta de un sistema de tipo B. Esto también explica por qué "verdadero" significa "no 0" - a nivel de bits Y no siempre produce un perfecto 1. – Qix
Pero '==' no es un operador de cortocircuito, entonces ¿por qué responde esto la pregunta? Sin embargo, gracias @Qix, porque tu comentario también explica por qué todos los operadores bit a bit tienen diferentes precedencias (aparentemente arbitrarias) - son de B como se ve en el _ [B Tutorial Apéndice D] (https: //www.bell- labs.com/usr/dmr/www/btut.html)_ (una pregunta que me molestaba). (Y mi suposición es que B lo hizo de esa manera solo por que es fácil escribir un analizador de descenso recursivo con ese tipo de gramática de expresiones). – davidbak
No tengo una respuesta autorizada sobre por qué K & R eligió la precedencia que lo hicieron. Un ejemplo que hace que una buena cantidad de sentido sería éste:
if (x == 1 & y == 0) {
/* ... */
}
Dado que este es el operador AND se utiliza un no-cortocircuitando el modo de evaluación, al igual que
if (x == 1 | y == 0) {
/* ... */
}
utilizar el operador OR sin cortocircuito. Esta es probablemente la razón por la que eligieron tener el grupo de precedencia de esta manera, pero estoy de acuerdo con usted en retrospectiva, no parece una buena idea.
Esto no tiene ningún sentido. ¿Por qué usaría el operador bit a bit en lugar de uno lógico en este caso? –
@Nathan Fellman- La respuesta de Caladain parece golpear esta en la cabeza. – templatetypedef
Derecha. La precedencia de '&' y '|' tiene perfecto sentido como operadores lógicos, pero poco sentido como operadores bit a bit. – dan04
No tiene sentido para Dennis Ritchie, en retrospectiva.
http://www.lysator.liu.se/c/dmr-on-or.html
& & y || se agregaron al idioma después | y &, y se mantuvo la precedencia por razones de compatibilidad.
Porque así es como lo diseñaron. Además, los paréntesis son baratos. – CanSpice
¿Por qué no tiene sentido para usted? – peoro
Me sorprendió usar la expresión if (a & b == c), me llevó un tiempo averiguar por qué no funcionaba. – poida