Discussion :

[TheSamFrom1984]

Bonjour,

Je cherche à coder une classe fournissant la strong guarantee en matière d'exception safety pour toutes ses opérations.
En postulant que l'opérateur d'affectation de la classe à laquelle appartient cette méthode fournit déjà la strong guarantee, je me suis dit qu'il suffisait de faire ça dans chaque méthode pour que la classe entière fournisse cette garantie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
MaCLasse Moi = *this; // n'a aucun incidence sur this
//...    
// code qui modifie Moi et qui:
// - ne modifie aucun objet externe (que ce soit par paramètre de la fonction ou par singleton)
// - suit l'idiôme RAII pour qu'il n'y ait pas de fuite
//...
*this = Moi; // strong guarantee de l'opérateur '=', donc soit ça throw et c'est comme si rien ne s'était passé, soit ça passe

Ca m'a l'air ok (ou pas ?), mais je voulais savoir si c'était une pratique courante, ou si au contraire ça ne se fait jamais.
Votre avis ?

Merci.

PS: j'ai du mal à faire des recherches sur le sujet, car je tombe toujours sur des généralités ou sur l'écriture d'un opérateur d'affectation fournissant la strong guarantee (ce qui n'est pas le sujet).

[3DArchi]

Bonjour,
Si j'ai bien compris, tu veux que dans chaque fonction de ta classe soit elle réussie et l'objet change d'état, soit elle échoue et alors l'état est restauré tel qu'à l'appel. Pour cela tu travailles sur une copie temporaire et tu bascule ton état global à la fin. Pourquoi pas. Je vois 3 inconvénients : tu dois supporter la copie et éventuellement son coût. Et si ta fonction appelle une autre fonction, qui appelle, etc... tu multiplies les copies. Enfin, dans un cadre polymorphe (mais tu n'aurais probablement pas de sémantique de copie alors), tu perds le type effectif.
Il y a aussi Boost.Scoop Exit qui peut t'aider à insérer des points de restauration.

[Lavock]

Etrangement, j'aurais essayait "fragmenté" l'affaire autant que possible. i.e. Plutôt de copier this, ce qui peut être super lourd, j'aurais copier/cloner les attributs sur lequel je ferai des opérations.

Après, je crois que BS sort un truc comme quoi la strong guaranty ne devrait pas faire de back-up. Trop couteux.

D'ailleurs :

[2] Strong guarantee: If an exception is thrown, any container being manipulated remains in
the state in which it was before the standard-library operation started.
{...}
Alternative [2] is unacceptable
because it imposes the cost of roll-back semantics on every individual standard-library operation.
{...}
Strong guarantee for key operations: In addition to providing the basic guarantee, either
the operation succeeds, or has no effects.

B. Stroustrup, The C++ Programing Language, Appendix E2.

[edit] Bon après c'est pour les conteneur, un cas extrême, mais la philosophie et là.

[Sylvain Togni]

Oui c'est un idiome connu et utilisé, à ceci près qu'on utilisera swap() plutôt que l'opérateur de copie pour valider les changements à la fin de la fonction, c'est moins couteux.

A noter que les fonctions swap() sont généralement très utiles en terme d'exception safety car elles sont souvent simples à implémenter, rapides et nothrow.

[TheSamFrom1984]

@Lavock j'ai bien un conteneur, mais en pratique le nombre d'éléments ne dépassera pas la dizaine.

si ta fonction appelle une autre fonction, qui appelle, etc... tu multiplies les copies

Very good point. Ce n'est pas mon cas pour mon code mais comme je voulais un avis généralisé, c'est vrai que c'est tellement évident que je n'y avais pas pensé. D'ailleurs, l'opérateur d'affectation fait lui aussi une copie (puis un swap), ça commence déjà à faire beaucoup

Merci à vous trois, j'y vois plus clair
Il ne s'agit pas de code critique, mais je voulais avoir quelques avis extérieurs.
Je mettrai résolu s'il n'y a pas d'autres avis