Nel linguaggio di programmazione C, perché gli operatori bit a bit (& e |) hanno precedenza inferiore rispetto all'operatore di uguaglianza (==)? Non ha senso per me.Precedenza dell'operatore (bit a bit '&' inferiore a '==')
Devi chiedere a Brian Kernighan oa Dennis Ritchie.
da questo forum: http://bytes.com/topic/c/answers/167377-operator-precedence
Il & & e || gli operatori sono stati aggiunti in seguito per il loro comportamento di "cortocircuito". Dennis Ritchie ammette in in retrospettiva che la precedenza degli operatori bit a bit dovrebbe essere stata modificata quando gli operatori logici sono stati aggiunti. Ma con diverse centinaia di kilobyte di codice sorgente C esistenti in quel punto e una base installata di tre computer, Dennis pensato che sarebbe stato troppo grande di un cambiamento nel linguaggio C ...
Quindi, quella potrebbe essere una ragione? Immagino perché ci sono diversi livelli di precarietà a bit (a differenza dei confronti relazionali) che è cruft che esiste da ... per sempre ... e non è mai stato corretto.
Dannato. Condannata dalla pigrizia :( –
Quella citazione è in realtà citata erroneamente, Dennis Ritchie lo spiega nel suo articolo "Chistory", che [puoi leggere qui] (http://cm.bell-labs.co/who/dmr/chist. html). A mio parere, la formulazione di Ritchie è molto meglio.Ritchie si è rammaricato di avere la precedenza in quanto tale, ma è stato fatto in modo da avere un minimo attrito di conversione dal linguaggio B, il predecessore di C, quando stava per la prima volta formando il linguaggio C. B supportava solo '&' sulle celle e non aveva un operatore booleano esplicito a causa della mancanza di un sistema di tipi di B. Questo spiega anche perché "true" significa "non 0" - bit a bit E non sempre produce un perfetto 1. – Qix
Ma '==' non è un operatore di cortocircuito, quindi perché questo risponde alla domanda? Tuttavia, grazie @Qix, perché il tuo commento spiega anche perché gli operatori bit a bit hanno tutte delle precedenze differenti (apparentemente arbitrarie) - sono da B come si vede nel _ [B Tutorial Appendice D] (https: //www.bell- labs.com/usr/dmr/www/btut.html)_ (una domanda che mi ha tormentato). (E suppongo che B l'abbia fatto in quel modo per nessun altro motivo se non che è facile scrivere un parser di discendenza ricorsiva con quel tipo di grammatica delle espressioni.) – davidbak
Non ho una risposta autorevole sul motivo per cui K & R ha scelto la precedenza che hanno fatto. Un esempio che effettua una buona dose di senso sarebbe questo:
if (x == 1 & y == 0) {
/* ... */
}
Poiché questo è il bit operatore utilizza un non-cortocircuito modalità di valutazione, come
if (x == 1 | y == 0) {
/* ... */
}
userà la operatore OR non cortocircuito. Questo è probabilmente il motivo per cui hanno scelto di avere il gruppo di precedenza in questo modo, ma sono d'accordo con te che a posteriori non sembra una buona idea.
Questo non ha alcun senso. Perché dovresti usare l'operatore bit a bit invece di uno logico in questo caso? –
@Nathan Fellman- La risposta di Caladain sembra colpire questo in testa. – templatetypedef
Giusto. La precedenza di '&' e '|' ha perfettamente senso come operatori logici, ma poco senso come operatori bit a bit. – dan04
Non ha senso nemmeno Dennis Ritchie, in retrospettiva.
http://www.lysator.liu.se/c/dmr-on-or.html
& & e || sono stati aggiunti alla lingua dopo | e & e la precedenza è stata mantenuta per motivi di compatibilità.
Perché è così che l'hanno progettato. Inoltre, le parentesi sono economiche. – CanSpice
Perché non ha senso per te? – peoro
Sono stato colto quando uso l'espressione if (a & b == c), mi ci è voluto un po 'per capire perché non funzionava. – poida