Oui, j’ai examiné les normes C ++ que je pouvais trouver (ou les brouillons), mais je ne trouve aucune des garanties d’exception fournies par les conteneurs STL. Tout ce que je peux trouver, ce sont des sections occasionnelles avec des descriptions incomplètes de certaines fonctions pour certains types. Ou peut-être que c’est là, mais je ne trouve tout simplement pas, je ne sais pas.
Remarque: je ne demande pas une liste de toutes les garanties auxquelles les gens peuvent penser, ce qui est essentiellement dans cette question .
Je cherche la source faisant autorité de cette information elle-même – ou de préférence, une version gratuite de la source (par exemple un brouillon de la norme) où je peux plus ou moins me considérer comme officielle.
Lire le standard peut être effrayant (revenons au standard), mais Bjarne Stroustrup a écrit une très belle annexe à ce sujet dans son livre ‘Le langage de programmation C ++’. Il a posté cette annexe à
http://www.stroustrup.com/3rd_safe0.html , à l’ adresse http://www.stroustrup.com/3rd_safe.pdf
C’est assez long et détaillé (et bien écrit). Vous pouvez par exemple trouver la section E.4 intéressante, citation:
E.4 Garanties standard sur les conteneurs
Si une opération de bibliothèque génère elle-même une exception, elle peut – et s’assure – que les objects sur lesquels elle opère restnt dans un état bien défini. Par exemple, at () jeter out_of_range pour un vecteur (§16.3.3) ne pose pas de problème de sécurité pour les exceptions. Le rédacteur de at () n’a aucun problème à s’assurer qu’un vecteur est dans un état bien défini avant de lancer.
En outre, la section E.4.1 indique
Outre la garantie de base, la bibliothèque standard offre la garantie forte de quelques opérations d’insertion ou de suppression d’éléments.
jetez un coup d’œil à la page 956. Il contient un tableau des garanties pour diverses opérations de vector, deque, list et map. En résumé, toutes les opérations effectuées sur ces conteneurs ne sont ni légitimes ni fortes, à l’exception de l’ insertion d’éléments N dans la carte qui offre les garanties de base.
Remarque: le texte ci-dessus est ancien et ne traite pas de C ++ 11, mais doit néanmoins être suffisamment correct pour la plupart des objectives.
les premiers états standard, à propos du array, deque, forward_list, list, vector, map, set, unordered_map, unordered_set, queue,stack
conteneurs array, deque, forward_list, list, vector, map, set, unordered_map, unordered_set, queue,stack
: à
23.2.1 / 10 :
Sauf indication contraire (voir 23.2.4.1, 23.2.5.1, 23.3.3.4 et 23.3.6.5), tous les types de conteneur définis dans le présent paragraphe satisfont aux exigences supplémentaires suivantes:
– si une exception est levée par une fonction insert () ou emplace () lors de l’insertion d’un seul élément, cette fonction est sans effet.
– si une exception est levée par une fonction push_back () ou push_front (), cette fonction est sans effet.
– aucune fonction erase (), clear (), pop_back () ou pop_front () ne lève une exception.
– aucun constructeur de copie ni opérateur d’assignation d’un iterator retourné ne lève une exception.
– pas de fonction swap () lève une exception.
– aucune fonction swap () n’invalide les références, pointeurs ou iterators faisant référence aux éléments des conteneurs en cours d’échange.
Les bizarreries soulignées dans les sections respectives mentionnées ci-dessus (chacune appelée garanties de sécurité d’exception) concernent principalement des cas spéciaux contre le mur, comme lorsqu’il s’agit de traiter des exceptions du hachage des types contenus, des opérations de comparaison ainsi que des opérations d’échange et de lancement. opérations.
Sauf indication contraire (voir 23.2.4.1, 23.2.5.1, 23.3.3.4 et 23.3.6.5), tous les types de conteneur définis dans le présent paragraphe satisfont aux exigences supplémentaires suivantes:
– si une exception est levée par une fonction insert () ou emplace () lors de l’insertion d’un seul élément, cette fonction est sans effet.
– si une exception est levée par une fonction push_back () ou push_front (), cette fonction est sans effet.
– aucune fonction erase (), clear (), pop_back () ou pop_front () ne lève une exception.
– aucun constructeur de copie ni opérateur d’assignation d’un iterator retourné ne lève une exception.
– pas de fonction swap () lève une exception.
– aucune fonction swap () n’invalide les références, pointeurs ou iterators faisant référence aux éléments des conteneurs en cours d’échange.
[Remarque: l’iterator end () ne fait référence à aucun élément et peut donc être invalidé. —Endnote]
1 Pour les conteneurs associatifs, aucune fonction clear () ne lève une exception. erase (k) ne lève pas d’exception sauf si cette exception est levée par l’object Compare du conteneur (le cas échéant).
2 Pour les conteneurs associatifs, si une exception est générée par une opération depuis une fonction insert ou emplace insérant un seul élément, l’insertion n’a aucun effet.
3 Pour les conteneurs associatifs, aucune fonction de swap ne lève une exception à moins que cette exception ne soit levée par le swap de l’object Compare du conteneur (le cas échéant).
1 Pour les conteneurs associatifs non ordonnés, aucune fonction clear () ne lève une exception. erase (k) ne lève pas d’exception à moins que cette exception ne soit levée par l’object Hash ou Pred du conteneur (le cas échéant).
2 Pour les conteneurs associatifs non ordonnés, si une exception est générée par une opération autre que la fonction de hachage du conteneur à partir d’une fonction insert ou emplace insérant un seul élément, l’insertion n’a aucun effet.
3 Pour les conteneurs associatifs non ordonnés, aucune fonction de swap ne lève une exception, sauf si cette exception est levée par le swap de l’object Hash ou Pred du conteneur (le cas échéant).
4 Pour les conteneurs associatifs non ordonnés, si une exception est levée depuis une fonction rehash () autre que par la fonction de hachage ou la fonction de comparaison du conteneur, la fonction rehash () n’a aucun effet.
Remarques: Si une exception est levée autrement que par le constructeur de copie, le constructeur de déplacement, l’opérateur d’opération ou l’opérateur de affectation de déplacement de T, il n’y a aucun effet. Si une exception est levée par le constructeur de déplacement d’un T non-CopyInsertable, les effets ne sont pas spécifiés.
Lance: Rien, sauf si une exception est levée par le constructeur de copie, le constructeur de déplacement, l’opérateur d’opération ou l’opérateur de affectation de déplacement de T.
Si une exception est levée par le constructeur de déplacement d’un T non-CopyInsertable, les effets ne sont pas spécifiés.
Lance: Rien, sauf si une exception est levée par le constructeur de copie, le constructeur de déplacement, l’opérateur d’opération ou l’opérateur de affectation de déplacement de T.
Le document auquel vous avez accédé, le projet de norme n3337, peut être considéré comme officiel. C’est la norme C ++ 11 plus des modifications rédactionnelles mineures.
Vous devez juste apprendre à lire la norme, ce qui est compréhensible car elle n’est pas destinée à être une lecture facile.
Pour rechercher les garanties d’exception pour une opération de bibliothèque particulière, vérifiez la spécification de cette opération pour les remarques et commentaires sur les exceptions. Si la fonction est une fonction membre, vérifiez si la spécification du type contient des commentaires sur la sécurité des exceptions et sur les exigences à remplir. Ensuite, vérifiez les conditions remplies pour les garanties d’exception qui doivent être faites par les objects pour remplir ces conditions.
Pour les types génériques et les algorithmes, vérifiez également les exigences imposées aux parameters de modèle afin de déterminer celles auxquelles ces types doivent satisfaire pour que toutes les garanties d’exception définies par le type, l’algorithme ou la fonction membre soient respectées (si les parameters de modèle ne sont pas pris en compte). t répondent aux exigences spécifiées puis utiliser le modèle avec ces parameters a un comportement indéfini et aucune des spécifications du modèle ne s’applique).