Discussion :

[tintin72]

Je viens de trouver le pb !
Au cours d'une énième compilation mon ordi à carrément planté, je préfère même pas savoir pourquoi. Bref au redémarrage, pour
plus de sécurité je vire le .exe pour refaire une compile propre.
Et là plus de pb.
J'ai recompilé plusieurs fois pour être sûr mais non, plus d'erreur.
Je sais pas ce qui a bien pu se passer dans l'exe au cours des précédentes
compiles mais c'est la 1ere fois que ça m'arrive.
En tout cas je m'en souviendrais pour la prochaine fois.

[buggen25]

1. Ça ne sert à rien ici, ça n'est pas le problème.
2. Inutile de tester NULL avant, delete[] NULL est garanti ne rien faire.
3. Par contre, tu oublies de mettre le pointeur à NULL, ce qui fait qu'il risque d'être deleté deux fois.

Ce n'est pas la peine de venir aider si c'est pour donner du code dangereux...

c'est pas du code dangeureux, Il faut faire des initialisations.
De plus je fais jamais confiance a une fonction qu'on ne peut appeler explicitement (le destructeur), alors je la laisse vide (la plupart du temps )

pour la remarque numero 3, je ne vais pas appeler delete dans le destructeur

Donc ce n'est pas aussi dangereux !
ps : sans rancune

[Médinoc]

Destructeur ou pas, si tu appelles deux fois Clear(), tu cours à la catastrophe.
Remettre un pointeur à NULL après l'avoir invalidé est un des principes de base de la programmation défensive: Même si tu crois que ça ne change rien, fais-le.

[buggen25]

Salut, c'est ça que je voulait dire, j'ai compilé et ça marche

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
#include <stdio.h>
class MaClass{
      int * pOne;
      int * pTwo;
public :
 
      MaClass(){
               pOne = new int[10];
               pTwo = new int[20];
               pOne[5]=1;
               pTwo[5]=2;
               };
      ~MaClass(){};
      void Print(){
               printf("Pointer one :%d\n",pOne[5]);
               printf("Pointer Two :%d",pTwo[5]);
               };
      void Clear(){
           if( pOne != NULL)
           delete[]pOne;
           if( pTwo != NULL)
           delete[]pTwo;
           }
      };
 
int main(int argc,char * argv[])
{
    MaClass cls;
    cls.Print();
    scanf("%d");
    cls.Clear();
    return 0;
}

[Médinoc]

Si tu avais pensé à remettre le pointeur à NULL ensuite, ce code ne serait pas buggué.

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
#include <stdio.h>
class MaClass{
      int * pOne;
      int * pTwo;
public :
 
      MaClass(){
               pOne = new int[10];
               pTwo = new int[20];
               pOne[5]=1;
               pTwo[5]=2;
               };
      ~MaClass(){};
      void Print(){
               printf("Pointer one :%d\n",pOne[5]);
               printf("Pointer Two :%d",pTwo[5]);
               };
      void Clear(){
           if( pOne != NULL)
           delete[]pOne;
           if( pTwo != NULL)
           delete[]pTwo;
           }
      };
 
void Oups(MaClass & cls)
{
    cls.Print();
    cls.Clear();
}
 
int main(int argc,char * argv[])
{
    MaClass cls;
    Oups(cls);
    { int unEntier; scanf("%d", &unEntier); }
    cls.Clear(); //Oups! J'ai appelé Clear() deux fois!
    return 0;
}

Et en plus, ce code est tout sauf exception-safe.

[buggen25]

Si tu avais pensé à remettre le pointeur à NULL ensuite, ce code ne serait pas buggué.

Code :

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

cls.Clear(); //Oups! J'ai appelé Clear() deux fois!

Et en plus, ce code est tout sauf exception-safe.

Je n'avait pas dit que j'allait l'appeler deux fois . de plus je viens juste de l'écrire avec devC++.
En ce que cocèrne l'exception-safe, je passe en mode release, ensuite je vérifie bien qu'il n'affiche pas le message "Envoyer le message a micro$oft" ou "Access viloation to adress 0x0000000".

[Médinoc]

Je n'avait pas dit que j'allait l'appeler deux fois .

Mais rien n'empêche de le faire.

Par contre, une bonne programmation défensive limite les dégâts quand c'est fait. Et tu ne comprends pas ce que c'est que l'Exception-safety, notamment parce qu'il n'y a rien dans le code qui en lance une. Sache en tout cas que ça ne se limite pas au non-plantage.

[buggen25]

Je sais ce que sa veut dire, ça ressemble aux exceptions génèrés par des classes comme CDatabase, ou CRecordSet . pour cela il faut les "catcher".Vu que ce code n'utilise pas d'API, il n'ypas de soucis, pour un projet réelle j'utiliserais pas ce genre de code.

[Médinoc]

De plus je fais jamais confiance a une fonction qu'on ne peut appeler explicitement (le destructeur), alors je la laisse vide (la plupart du temps )

Tu raisonnes à l'envers.
Un bon programmeur ne fais jamais confiance à une fonction de nettoyage qu'il risque d'oublier d'appeler.

Considère ce code:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
#include <exception>
#include <iostream>
#using namespace std;
 
class MonException : public std::exception
{ };
 
class MaClass {
	int * pOne;
	int * pTwo;
public :
	MaClass() : pOne(NULL), pTwo(NULL) {
		pOne = new int[10];
		pTwo = new int[20];
		pOne[5]=1;
		pTwo[5]=2;
	};
	~MaClass(){ };
	void Print() const {
		cout << "Pointer one : " << pOne[5] << endl;
		cout << "Pointer two : " << pTwo[5] << endl;
	};
	void Clear() {
		delete[] pOne, pOne=NULL;
		delete[] pTwo, pTwo=NULL;
	}
};
 
void FonctionQuiLanceUneException(void) {
	//... blablabla, du code
	if( /* un truc */ )
		throw MonException;
	//... blablabla, du code
}
 
void UneFonction(void) {
	MaClass monObjet;
	monObjet.Print();
 
	FonctionQuiLanceUneException();
 
	monObjet.Clear(); //Oups! Cette fonction ne sera pas appelée!
	                  //Quel dommage que je n'aie pas donné un bon
	                  //destructeur à ma classe!
}
 
int main(void) {
	try {
		UneFonction();
	} catch(MonException const & e) {
		cout << "Exception attrapee." << endl;
	}
	return 0;
}

Avec ça, si la fonction lance son exception, la fonction Clear() ne sera pas appelée. Tu sais, les destructeurs ont une raison d'être: Celle d'être appelé même en cas d'exception...

PS: Le simple opérateur new lève une exception en cas d'échec, sur tout système un tant soi peu conforme à la norme (e.g, gcc, Visual 2005 Pro et supérieur). C'est plus pratique et moins contraignant que de tester à chaque fois le retour de malloc().
Donc si tu fais des new, tu dois apprendre à faire du code exception-safe.
Pareil si tu fais des dynamic_cast<> avec des références.

[3DArchi]

Tu raisonnes à l'envers.
Un bon programmeur ne fais jamais confiance à une fonction de nettoyage qu'il risque d'oublier d'appeler.

++++

J'ai lu en diagonale, mais je partage cet avis. Un destructeur c'est fait pour ça!

[Profman]

Pourquoi avez-vous écrit tous les deux : MaClasse(MaClasse const &) ?
Y a t-il une différence avec l'usuel: MaClasse(const MaClasse&) ?

C'est la même chose en fait

[loufoque]

Par contre, tu oublies de mettre le pointeur à NULL, ce qui fait qu'il risque d'être deleté deux fois.

Ce qui ne sert strictement à rien dans un destructeur.

[Médinoc]

Ce qui ne sert strictement à rien dans un destructeur.

Mais justement, ce n'est pas dans le destructeur qu'il l'a fait...

[Profman]

Mais justement, ce n'est pas dans le destructeur qu'il l'a fait...

Mettre le pointeur à NULL dans le destructeur est une pratique courante et utile (en cas de sur libération !).

A bientôt

[Médinoc]

Quand j'ai des craintes de double-destruction, j'ai plutôt tendance à rajouter un booléen bDestroyed (ou plus sûr, une valeur magique) et mettre une assertion dessus...

[loufoque]

Dans le code du premier message, le seul delete que je vois est dans le destructeur.

[Médinoc]

En effet, mais c'était surtout le "conseil" de buggen25 que je critiquais.

[buggen25]

Tu raisonnes à l'envers.
Un bon programmeur ne fais jamais confiance à une fonction de nettoyage qu'il risque d'oublier d'appeler.

Oui je réflechit à l'envers. mais il y a une chose dont je suis sure utliser le destructeur pour desallouer quelque chose n'est pas tout le temps la solution miracle.

Code :

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

1
2
3
 
if ( bTheDatabeiseConnected )
pRows = new Row[iHugeNumberOfRows];

Il faut attendre que le destructeur le fasse. et surtout quand on a besoin de réutiliser pRows. c'est un autre problème
Pour les exceptions, il y a toujours une exception qui confirme la règle.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
#include <stdio.h>
#include <limits.h>
struct LimitException{
       };
char ToChar(int ii)
{
     char ch;
     if( ii > UCHAR_MAX || ii < 0  )
     throw LimitException();
     else
     return ii;
}
 
int main(int argc, char * argv[])
{   
    try 
    {
        printf("C'est le caractère : %c\n",ToChar(-500));
    }
    catch(LimitException& X)
    {
     printf("Exception, plage de valeurs");                      
    }
    int AnIntegerPlease;
    scanf("%d",AnIntegerPlease);
    return 0;
}

[3DArchi]

Je penses que tu confond le fait qu'un pointeur peut avoir une durée de vie inférieur à l'objet qui le contient et la libération de l'adresse dans le destructeur. Moi je pense qu'il faut toujours libérer la mémoire dans le destructeur (c'est fait pour ça!), mais rien ne t'empêche d'avoir d'autres endroits où la mémoire est libérée selon tes besoins. L'un n'empêche pas l'autre.

[buggen25]

Je penses que tu confond le fait qu'un pointeur peut avoir une durée de vie inférieur à l'objet qui le contient et la libération de l'adresse dans le destructeur. Moi je pense qu'il faut toujours libérer la mémoire dans le destructeur (c'est fait pour ça!), mais rien ne t'empêche d'avoir d'autres endroits où la mémoire est libérée selon tes besoins. L'un n'empêche pas l'autre.

Je suis tout a fait d'accord avec toi (c'est une première), l'un n'empèche pas l'autre. Si tu alloue dynamiquement un membre de cette classe dans le constructeur, et que le cycle de vie d'un membre de l'objet est conçu pour s'arreter a la destruction de l'objet, on laisse le destructeur faire son travail. et c'est tout .