Résultat inattendu, opérateur ternaire dans Gnu C

La préséance de l’opérateur ternaire en C sur l’opérateur me semble donc vraiment bizarre. Exemple:

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

Cela semble similaire à la question ici:
C ++ ternary conditionnel et priorité d’opérateur d’affectation
Ordre d’évaluation d’opérateur ternaire

Par souci de clarté, je comprends que les parenthèses permettent de l’utiliser, comme indiqué dans les commentaires que j’avais formulés dans mon message original …

Je me demande simplement pourquoi les auteurs de langage choisiraient une méthode d’évaluation susceptible de tromper les gens, alors que la première déclaration semble pouvoir être formatée pour le compilateur pour être valide.

Mais cette question concerne les opérateurs du côté gauche ou au sein des membres du groupe, où ce comportement étrange se produit sur le RHS.

Qu’est-ce qui est bizarre ici? La première partie est interprétée comme:

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

et le second est interprété comme

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

La première est due aux règles de priorité (l’arithmétique binary a une priorité supérieure à celle de l’opérateur ternaire) et la seconde contourne les règles de priorité en regroupant l’expression avec une parenthèse.

Votre modification demande les raisons et on ne peut généralement les deviner que si un membre du comité C qui était présent à ce moment-là vient pour aider. À mon avis, il est beaucoup plus courant d’utiliser une expression complexe et de demander sa valeur de vérité que d’utiliser l’opérateur ternaire pour déterminer la valeur d’une expression en arithmétique. Quelque chose comme ça vient à l’esprit:

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

si cela serait interprété comme un return (froble() + 3) == 5; Je serais vraiment choqué.

Il faut choisir une priorité très élevée ou très faible, et l’un ou l’autre sera surprenant pour une personne qui formule une hypothèse erronée.

Une raison utile de choisir une faible priorité est que cela signifie que l’opérateur fonctionne comme une construction if .. then .. else .. sans accolade, ce qui pourrait signifier moins de travail pour les auteurs de compilateur (qui pourraient utiliser le même code pour gérer les deux) , et une refactorisation directe par des codeurs qui comprennent la priorité.

En pratique, le langage normalisé probablement quelle que soit sa priorité était l’utilisation la plus courante du code écrit à l’ère de la pré-normalisation.