Risultato imprevisto, operatore ternario in Gnu C - c, condizionale, operatore ternario, ternario, ordine delle operazioni

Quindi la precedenza dell'operatore dell'operatore ternario in C sembra davvero bizzarro per me. Caso in questione:

#include <stdio.h>

int main ()
{
int i=5;
int j=6;
int k=7;
printf("A: %dn", i+j+(k!=7)?1:11); //prints 1
printf("B: %dn", i+j+((k!=7)?1:11)); //prints 22
return 0;
}

Questo sembra simile alla domanda qui:
C ++ Condizionatore ternario e precedenza dell'operatore di assegnazione
Ordine di valutazione dell'operatore ternario

Come chiarimento, capisco che le parentesi lo fanno funzionare, come i miei commenti nel mio post originale indicato ...

Mi chiedo semplicemente perché gli autori del linguaggio sceglierebbero un metodo di valutazione che è così incline a ingannare le persone, quando la prima affermazione sembra che possa essere formattata per essere valida dal punto di vista del compilatore.

Ma quelle domande riguardano gli operatori sul lato sinistro o all'interno dei membri della classe, dove questo strano comportamento si verifica sul RHS.

risposte:

6 per risposta № 1

Cos'è strano qui? La prima parte è interpretata come:

(11 + (k != 7)) ? 1 : 11

e il secondo è interpretato come

 11 + ((k !=7) ? 1 :11)

Il primo è causato dalle regole di precedenza(l'aritmetica binaria ha una precedenza maggiore rispetto all'operatore ternario) e la seconda circoscrive le regole di precedenza raggruppando l'espressione con parentesi.

La tua modifica richiede i motivi e si puòdi solito solo indovinare quelli a meno che qualcuno del comitato C che era presente al momento venga in aiuto. La mia ipotesi sarebbe che è molto più comune usare un'espressione complessa e chiedere il suo valore di verità piuttosto che usare l'operatore ternario per determinare il valore di un'espressione in aritmetica. Mi viene in mente qualcosa del genere:

return (froble() + 3) == 0 ? 23 : 5; // parens for sanity but works without

se questo sarebbe interpretato come return (froble() + 3) == 5; Sarei davvero scioccato.

---

0 per risposta № 2

Si dovrebbe scegliere una precedenza molto alta o molto bassa, e l'una o l'altra sarà sorprendente per qualcuno che fa l'ipotesi sbagliata.

Una ragione utile per la scelta della precedenza è bassaciò significa che l'operatore funziona come un if se .. allora .. else .. costruisce senza parentesi, il che potrebbe significare meno lavoro per i compilatori di compilatori (che potrebbero usare lo stesso codice per gestirli entrambi) e un refactoring semplice da parte dei programmatori che capiscono la precedenza.

In pratica, la lingua probabilmente standardizzava qualsiasi precedente fosse l'uso più popolare nel codice scritto nell'era della pre-standardizzazione.

---