Petite question intéressante

x étant une variable de type quelconque,

Peut-on toujours remplacer if(p-1 != 0) par if(p != 1 ) sans que le comportement du programme change ?

Dans la majorité des cas oui. En pratique non.

Si p est le plus petit entier personne ne sait ce que la première expression fait alors que la seconde sera toujours vraie. Par exemple sur un entier 8 bits signé, si p est -128, p-1 peut faire tout et n'importe alors que p!=1 sera toujours vraie.

Et avec des flottants c'est encore pire.

Le 30 avril 2020 à 23:40:33 SithisMinion a écrit :
Dans la majorité des cas oui. En pratique non.

Si p est le plus petit entier personne ne sait ce que la première expression fait alors que la seconde sera toujours vraie. Par exemple sur un entier 8 bits signé, si p est -128, p-1 peut faire tout et n'importe alors que p!=1 sera toujours vraie.

Et avec des flottants c'est encore pire.

Non, le comportement des entiers aux limites est déterminé, p-1 sera évalué à 127 Ah non je viens de tester et il est évalué à -129

Mais avec un int x initialisé à -2147483648, (x-1) est évalué à 2147483647
Mais en aucun cas ça peut être évalué à 0

Le 30 avril 2020 à 23:30:10 RipPlanCul a écrit :
Petite question intéressante

x étant une variable de type quelconque,

Peut-on toujours remplacer if(p-1 != 0) par if(p != 1 ) sans que le comportement du programme change ?

En theorie non. En pratique oui.

Dans le standard C++ (et j'imagine C) les entiers signes ont un comportement non defini au bord de leur domaine. Donc si p est un int32_t de valeur INT_MIN alors p-1 est non defini. Donc la premier version est non defini et le compilateur peut faire tout ce qu'il a envie y compris dire que INT_MIN-1 est egal a 0, ou bien envoyer une exception, ou te commander une pizza par internet. (undefined, c'est undefined).
Le deuxieme comportement ne peux pas etre non defini (en supposant que p est proprement defini). Donc le comportement du programme peut changer et la deuxieme forme est toujours preferable parcequ'elle a moins de comportement non defini.

En pratique, je ne connais pas un seul compilateur ou architecture qui n'overflow pas les entiers en fonction de leur complement a deux.

[23:50:27] <RipPlanCul>
Mais avec un int x initialisé à -2147483648, (x-1) est évalué à 2147483647
Mais en aucun cas ça peut être évalué à 0

Petit conseil, c'est pas parce que tu observes un comportement que ce comportement est une règle. Les compilateurs fonctionnent tous de manière différente et il y a plusieurs implémentations valides possibles du C, donc deux compilateurs différents respectant à 100% le standard peuvent avoir deux comportements différents dans certains cas particulier.

Donc si possible ce genre de choses doivent être vérifiées en lisant la documentation.

En pratique, je ne connais pas un seul compilateur ou architecture qui n'overflow pas les entiers en fonction de leur complement a deux.

Mais il vaut quand même mieux éviter d'avoir du code basé là dessus, rien que le fait que ça empêche d'utiliser des sanitizers pour détecter des vrais erreurs d'overflow est une raison suffisante.