J'ai vu les termes "IB" et "UB" utilisés à plusieurs reprises, notamment dans le contexte du C++. J'ai essayé de les googler, mais apparemment, ces combinaisons de deux lettres sont très utilisées. :P
Alors, je vous demande... qu'est-ce qu'ils signifient, quand ils sont dits comme s'ils étaient une mauvaise chose ?
IB : Comportement défini par la mise en œuvre. La norme laisse au compilateur/à la plate-forme particulière le soin de définir le comportement précis, mais exige qu'il soit défini.
L'utilisation du comportement défini par l'implémentation peut être utile, mais rend votre code moins portable.
UB : Comportement indéfini. La norme ne précise pas comment un programme invoquant un comportement non défini doit se comporter. Également connu sous le nom de "démons nasaux" car, théoriquement, il peut faire sortir des démons de votre nez.
L'utilisation d'un comportement indéfini est presque toujours une mauvaise idée. Même si cela semble fonctionner parfois, tout changement d'environnement, de compilateur ou de plate-forme peut casser votre code de manière aléatoire.
J'attends toujours qu'un démon sorte du nez de quelqu'un pour avoir utilisé un comportement indéfini en C++. Je suppose que cela arrivera lorsque les premiers compilateurs seront entièrement conformes à la nouvelle norme C++.
@OregonGhost : Je suppose que vous avez raison. J'ai vu cela se produire avec des licornes quelques fois, mais jamais avec des démons.
Thomas : J'accepterais aussi les licornes. Peu importe si elles ont une ou deux cornes, comme beaucoup de démons.
Comportement défini par l'implémentation et comportement non défini
La norme C++ est très spécifique quant aux effets de diverses constructions, et en particulier vous devriez toujours être conscient de ces catégories de problème :
Un comportement non défini signifie qu'il n'y a absolument aucune garantie donnée. Le code peut fonctionner, ou mettre le feu à votre disque dur ou à votre ordinateur. faire sortir des démons de votre nez . En ce qui concerne le langage C++, absolument tout peut arriver. En termes pratiques, cela signifie généralement que vous avez un bogue irrécupérable. Si cela arrive, vous ne pouvez pas vraiment faire confiance à tout ce qui est à propos de votre application (car l'un des effets de ce comportement indéfini pourrait simplement avoir été de perturber la mémoire utilisée par le reste de votre application). Il n'est pas nécessaire d'être cohérent, donc exécuter le programme deux fois peut donner des résultats différents. Il peut dépendre des phases de la lune, de la couleur de la chemise que vous portez, ou de n'importe quoi d'autre.
Un comportement non spécifié signifie que le programme doit faire quelque chose de sain et de cohérent, mais qu'il n'est pas obligé de document ceci.
Le comportement défini par l'implémentation est similaire à celui non spécifié, mais doit également être documenté par les auteurs du compilateur. Un exemple de ceci est le résultat d'un reinterpret_cast . généralement il change simplement le type d'un pointeur, sans modifier l'adresse, mais le mappage est en fait défini par l'implémentation, de sorte qu'un compilateur peut être amené à modifier le type d'un pointeur. pourrait à une adresse complètement différente, à condition que ce choix soit documenté. Un autre exemple est la taille d'un int. La norme C++ ne se soucie pas de savoir s'il s'agit de 2, 4 ou 8 octets. doit être documenté par le compilateur
Mais le point commun de tous ces éléments est qu'il vaut mieux les éviter. Dans la mesure du possible, adoptez un comportement qui est spécifié à 100 % par la norme C++ elle-même. De cette façon, la portabilité est garantie.
Vous devez souvent vous appuyer sur un comportement défini par l'implémentation. Cela peut être inévitable, mais vous devez tout de même y prêter attention, et être conscient que vous vous appuyez sur quelque chose qui peut changer entre différents compilateurs.
Un comportement indéfini, en revanche, devrait toujours être évitée. En général, vous devez partir du principe que cela fait exploser votre programme d'une manière ou d'une autre.
UB à éviter si vous vous souciez de la portabilité . Une implémentation particulière peut définir ce qui se passe pour un comportement non défini spécifique, et dans certains cas (notamment les pilotes de périphériques et les petits systèmes embarqués), vous devez utiliser ces choses.
@Jerry : Non, l'UB doit être évitée si elle est totalement indéfinie . Si la plate-forme/implémentation/runtime/compilateur donne des garanties supplémentaires, alors vous pouvez vous fier au comportement et perdre la portabilité. Mais alors, ce n'est plus vraiment indéfini... La plupart du temps, cependant, vous n'avez pas de telles garanties, et undefined est juste undefined, et devrait être évité à tout prix.
"cohérent" peut être une description trompeuse d'un comportement non spécifié. Il doit être cohérent avec le contexte général de l'opération, par exemple si une expression a une "valeur non spécifiée" alors le résultat doit être une valeur, si vous la stockez, la valeur stockée doit ensuite être égale à elle-même, et ainsi de suite. Mais les résultats non spécifiés ne doivent pas nécessairement être cohérents dans le temps (même sortie pour la même entrée si vous l'exécutez à nouveau), ni même déterministes.
IB : est un comportement défini par l'implémentation - le compilateur doit documenter ce qu'il fait. L'exécution d'un >> sur une valeur négative en est un exemple.
UB : comportement indéfini - le compilateur peut faire ce qu'il veut, y compris planter ou donner des résultats imprévisibles. Le déréférencement d'un pointeur nul entre dans cette catégorie, mais aussi des choses plus subtiles comme l'arithmétique des pointeurs qui sortent des limites d'un objet tableau.
Un autre terme connexe est "comportement non spécifié". Pour un comportement non spécifié, le compilateur doit faire quelque chose conformément à la norme, mais les choix exacts que la norme lui donne dépendent du compilateur et ne doivent pas être définis (ou même cohérents). Des choses comme l'ordre d'évaluation des sous-expressions entrent dans cette catégorie. Le compilateur peut les exécuter dans l'ordre qu'il souhaite, et pourrait le faire différemment dans différentes constructions ou même dans différentes exécutions de la même construction (peu probable, mais autorisé).
La version courte :
Comportement défini par la mise en œuvre (IB) : Correctement programmé mais indéterminé*
Comportement non défini (UB) : Programmée de manière incorrecte (c'est-à-dire une bogue !)
*) "indéterminée" en ce qui concerne la norme linguistique, elle sera bien sûr déterminée sur toute plate-forme fixe.
Si la norme indique qu'une action invoque un comportement défini par l'implémentation, les implémentations sont tenues de spécifier un comportement de type cohérent le comportement résultant de cette action. Malheureusement, il n'existe aucune catégorie de comportement pour laquelle une implémentation serait tenue de spécifier les conséquences possibles, mais ne serait pas tenue de faire en sorte qu'une conséquence particulière se produise systématiquement.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
9 votes
Si vous décidez d'annuler les modifications apportées par quelqu'un d'autre, assurez-vous que votre orthographe, votre ponctuation et votre grammaire sont parfaites. Il est inutile d'annuler des modifications qui constituent une amélioration substantielle du texte original.