Quelle est la règle du « comme si »?
Le " comme si règle » définit essentiellement les transformations qu'une implémentation est autorisée à effectuer sur un programme C ++ légal. En bref, toutes les transformations qui n'affectent pas le " comportement observable d' un programme (voir ci-dessous pour une définition précise) sont autorisées.
Le but est de donner aux implémentations la liberté d'effectuer des optimisations tant que le comportement du programme reste conforme à la sémantique spécifiée par le standard C ++ en termes de machine abstraite.
Où la norme introduit-elle cette règle?
La norme C ++ 11 introduit la règle " comme si " au paragraphe 1.9 / 1:
Les descriptions sémantiques de la présente Norme internationale définissent une machine abstraite paramétrée non déterministe. La présente Norme internationale n'impose aucune exigence sur la structure des implémentations conformes. En particulier, ils n'ont pas besoin de copier ou d'émuler la structure de la machine abstraite. Au contraire, des implémentations conformes sont nécessaires pour émuler (uniquement) le comportement observable de la machine abstraite comme expliqué ci-dessous.
En outre, une note explicative ajoute:
Cette disposition est parfois appelée la règle du «comme si» , car une mise en œuvre est libre de ne pas tenir compte de toute exigence de la présente Norme internationale tant que le résultat est comme si l'exigence avait été respectée, dans la mesure où cela peut être déterminé à partir du comportement observable du programme. Par exemple, une implémentation réelle n'a pas besoin d'évaluer une partie d'une expression si elle peut en déduire que sa valeur n'est pas utilisée et qu'aucun effet secondaire affectant le comportement observable du programme n'est produit.
Que prescrit la règle exactement?
Le paragraphe 1.9 / 5 précise en outre:
Une implémentation conforme exécutant un programme bien formé produira le même comportement observable que l'une des exécutions possibles de l'instance correspondante de la machine abstraite avec le même programme et la même entrée . Cependant, si une telle exécution contient une opération indéfinie, la présente Norme internationale n'impose aucune exigence sur l'implémentation exécutant ce programme avec cette entrée (pas même en ce qui concerne les opérations précédant la première opération non définie).
Il vaut la peine de souligner que cette contrainte s'applique uniquement lors de "l'exécution d'un programme bien formé" , et que les résultats possibles de l'exécution d'un programme qui contient un comportement non défini ne sont pas contraints. Ceci est également expliqué au paragraphe 1.9 / 4:
Certaines autres opérations sont décrites dans la présente Norme internationale comme non définies (par exemple, l'effet de la tentative de modification d'un objet const). [Remarque: La présente Norme internationale n'impose aucune exigence sur le comportement des programmes qui contiennent un comportement indéfini . —End note]
Enfin, concernant la définition du " comportement observable ", le paragraphe 1.9 / 8 se lit comme suit:
Les moindres exigences sur une implémentation conforme sont:
- L'accès aux objets volatils est évalué strictement selon les règles de la machine abstraite.
- A la fin du programme, toutes les données écrites dans des fichiers doivent être identiques à l'un des résultats possibles que l'exécution du programme selon la sémantique abstraite aurait produit.
- La dynamique d'entrée et de sortie des dispositifs interactifs doit avoir lieu de manière à ce que la sortie d'invite soit effectivement délivrée avant qu'un programme n'attende une entrée. Ce qui constitue un dispositif interactif est défini par l'implémentation.
Celles-ci sont désignées collectivement sous le nom de comportement observable du programme . [ Note : Des correspondances plus strictes entre la sémantique abstraite et réelle peuvent être définies par chaque implémentation. - note de fin ]
Y a-t-il des situations où cette règle ne s'applique pas?
Au meilleur de ma connaissance, la seule exception à la règle " as-if " est l'élision de copie / déplacement, qui est autorisée même si le constructeur de copie, le constructeur de déplacement ou le destructeur d'une classe ont des effets secondaires. Les conditions exactes à cet effet sont spécifiées au paragraphe 12.8 / 31:
Lorsque certains critères sont remplis, une implémentation est autorisée à omettre la construction copier / déplacer d'un objet de classe, même si le constructeur sélectionné pour l'opération de copie / déplacement et / ou le destructeur de l'objet ont des effets secondaires . [...]