La norme C23 est dans les cartons

Découvrez ce que réserve cette nouvelle mouture de la norme

a marqué ce sujet comme résolu.

Bonjour à tous,

Cela fait déjà quelque temps que le brouillon de la future norme C23 (ou plutôt C24, probablement) est fixé. il y a déjà eu quelques articles sur le sujet, notamment un de linuxfr.org. Cet article vise à aller un peu plus dans le détail et à profiter du support partiel des compilateurs pour donner davantage d’exemples.

Il manque encore l’un ou l’autre points, par exemple la possibilité de changer la classe de stockage des littéraux agrégats ou la présentation des flottants décimaux, mais le but est d’avoir déjà un premier retour. :)

+4 -0

Salut,

J’ai lu rapidement et je suis très heureux d’apprendre que C bénéficie de pleins de petites améliorations qui ont déjà été éprouvées par d’autres langages avant lui.

J’ai juste une remarque anecdotique.

Dans le cas de l’expression 3.0/2.0, le problème vient du fait que les calculs flottants peuvent avoir lieu avec une précision plus grande que celle induite par leur type. Dit autrement, même si les deux opérandes sont de type double, le calcul pourrait s’effectuer avec la précision du type long double, pour ensuite être converti vers le type double. Cette conversion peut induire un changement de valeur.

C’est vrai en général, mais ça n’arrive jamais dans le cas donné, à moins que l’implémentation ne soit pas conforme à IEEE-754. L’exemple en perd de sa force. Pour certaines opérations simples, dont la division de deux nombres fait partie, le résultat doit être tel que tout se passe comme si le calcul était fait en précision infinie puis arrondi.

Dans les implémentations conformes, le phénomène qu’ils cherchent à éviter arrive quand on combine plusieurs opérations dans la même expression et où effectivement certaines implémentations peuvent faire des calculs intermédiaires en précision étendue, ce qui change parfois le résultat. J’en touche deux mots dans ce tutoriel.

Merci pour ta relecture et ton retour @Aabu. :)

L’exemple que je donne est tiré de la norme C23 et vise probablement les problèmes de portabilité dans le cas où une machine ne respecte pas la norme IEEE-754. Ceci dit je n’en suis pas certain et ne connais pas assez la norme IEEE-754 dans le détail.

Est-ce qu’une opération supplémentaire suffit à rendre l’exemple valable suivant la norme IEEE-754, par exemple comme ceci ?

constexpr double f = 3. / 2. + .5;
+0 -0

T’auras jamais de problème de précision avec 3.0 / 2.0 + 0.5 parce que tout est représenté exactement, même en réordonnant. Si tu prends des nombres qui ne sont pas représentables exactement, comme 0.1 + 3.0 - 0.7, là tu peux avoir des soucis de précision différente suivant l’ordre des calculs. Tu peux aussi avoir des problèmes lorsque tu prends des nombres de magnitudes très différentes à la limite de la précision (du genre 1.0 + 1e17 + 1.0). Dans une veine similaire, et qui touche tous les langages, tu peux aussi avoir un comportement différent entre la même expression évaluée au runtime vs au compile time (parce que ton compilo ne se comporte pas forcément pareil que le FPU cible). Notamment, Rust a des soucis avec ça..

Ce sujet est verrouillé.