Discussion :

[feidaykin]

Bonjour,

J'ai été assez étonné de lire dans le livre "Mieux programmer en C++" a la page 30:

http://dut.proced90.com/Documentatio...20en%20c++.pdf

2.
Il n’y a pas de risque de fuites mémoires.
Détaillons en effet ce qui se passe en cas
de génération d’exception : si l’opérateur
new()
lance une exception
bad_alloc
, comme
le tableau d’objets
T
n’a pas encore été alloué, il n’y a donc pas de risque de fuite ; si la
construction d’un des objets
T
alloué échoue, le destructeur de
Stack
est automatique-
ment appelé (du fait qu’une exception a été générée au cours de l’exécution de
Stack::Stack
), ce qui a pour effet d’exécuter l’instruction
delete[]
, laquelle effectue
correctement la destruction et la désallocation des objets
T
ayant déjà été alloués.

Hors lorsqu'une exception est lancé dans un constructeur l'objet n'est pas construit et le destucteur ne peu pas être appelé...
Je ne comprend pas ce que l'auteur a voulu dire?

[therwald]

Il me semble que quand une exception est lancée au cours d'un constructeur, les membres dont le constructeur est déjà appelé ont leur destructeur appelé (dans l'ordre inverse des constructeurs).
Par contre, concernant l'allocation dynamique, il faut gérer soit-même vu qu'en effet le destructeur n'est pas appelé
c'est décrit dans la FAQ ici.

[Klaim]

Oui il ne faut pas oublier que si un objet est construit, alors son destructeur sera appele, meme si c'est un objet membre d'un autre objet!

Donc en gros

class K
{
A a;
B b;
C c;
K() { throw 42; }
};



Au moment du throw, a b et c sont construits donc ils seront deconstruits. C'est K qui n'est pas construit au moment du throw. Si a ou b ou c a alloue quelque chose, il sera desalloue.

[koala01]

Salut,

En gros, il faut savoir que le risque de fuite de mémoire survient lorsqu'on a recours à l'allocation dynamique de celle-ci.

Lorsque tu déclares un membre par valeur (pour vsize_ ou pour vused_ dans l'exemple), il n'y a strictement aucune raison qu'une exception ne soit lancée.

Le seul moment où il y a effectivement un risque qu'une exception soit lancée survient au moment du

Code :

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

 v_ = new T[vsize_]; // Allocation initiale

il y aura alors une exception de type std::bad_alloc qui sera lancée, si et uniquement si... l'allocation dynamique de la mémoire échoue.

Tel que le code est présenté, il n'y aurait donc en effet strictement aucun risque de fuite mémoire, parce qu'il n'y a aucune raison d'invoquer un delete sur le résultat d'une allocation dynamique qui a échoué

Par contre, là où tu aurais un grand risque de fuite mémoire, c'est si le constructeur venait à faire plus d'une allocation dynamique.

Par exemple, une classe proche de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
class MaClass{
    public:
        MaClass(int i, int j):i(i),j(j){
             first = new int[i]; // peut échouer!!!(*)
             second = new int[j]; // peut aussi échouer!!!(**)
       }
    private:
        int i;
        int j;
        int * first;
        int * second;
}

Ou, pire encore une classe proche de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Matrix{
    public:
        Matrix(int lines, int columns):lines(lines),columns(columns){
             data = new int *[lines]; // peut échouer (*)
             for(int i = 0;i<lines;++i){
                 data[i]=new int[columns]; //peut aussi échouer (à chaque passage 
                                           // dans la boucle!!!) (**)
             }
        }
    private:
        int lines;
        int columns;
        int ** data;
};

vont potentiellement poser problème.

Non pas au moment de la première allocation de mémoire (*) car, si elle échoue, l'exception bad_alloc est lancée, et, comme il n'y a pas eu d'allocation dynamique avant, il n'y a rien qui nécessite le recours à delete ou à delete[], mais bien au niveau de la deuxième allocation dynamique (**):

En effet, si la deuxième allocation dynamique (**) échoue, il faut, avant de quitter le constructeur, veiller à libérer le résultat de la première (*), voir (dans le cas de la classe Matrix ) de toutes les exécutions de la boucles pour lesquelles l'allocation dynamique a réussi avant qu'une (qui peut etre tout aussi bien la première que la dernière... ou n'importe laquelle entre les deux ) ne vienne à rater, sans oublier, toujours, de libérer le résultat de la première(*)

Enfin, bref, pour arriver à gérer correctement tous les cas, cela devient beaucoup plus compliqué

[therwald]

Je suppose qu'on peut solutionner une partie du problème (une fois qu'on a envisagé les solutions pour restreindre l'allocation dynamique) en wrappant les pointeurs individuels dans des smart pointers, et les objets créés en masse dans des containers, ou le cas échéant dans des containers de smart-pointers?
Dans ce cas on se ramène à des membres déclarés par valeur

[Médinoc]

En effet. Tant que la classe ne gère pas manuellement la durée de vie de ces ressources, elle devrait être exception-safe.

[feidaykin]

Effectivement alors lorsque l'allocation d'un tableau de classe avec new[] lance une exception std::bad_alloc les éléments déjà allouée du tableau sont libéré par la fonction new[]!

Cependant le destructeur des éléments du tableau est appelé pour les éléments déjà construit mais pas le destructeur de la classe Stack!

La fonction delete[] n'est au final jamais appelé dans l'exemple...