Discussion :

[deubelte]

Bonjour

je voudrais savoir si c'est dangereux de faire un delete sur un pointeur assign� � NULL?
Comme dans le cas pr�sent o� on fait un delete sur un pointeur dans un destructeur.

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
class B{
	B(){};
	B(int o):a(o){};
private:
	int a;
};
 
class A{
public:
	A(int o):l(o){
		n=0;
	}
	~A(){
		delete n;
	}
private:
	B *n;
	int l;
};
 
int main()
{
 
	{
		A a(4);
	}

En revanche, y a t il un risque si on fait ceci:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
class A{
public:
	A(int o):l(o){
		n=0;
	}
	~A(){
		delete n;
	}

merci

[Goten]

Non �a ne fait rien.

[koala01]

Salut,

Pour �tre un peu plus complet: NULL est la seule adresse (en attendant null_ptr de la prochaine norme) connue pour �tre invalide.

Delete "sait" donc qu'il n'a rien � faire sur cette adresse

Il faut cependant faire attention aux indirections qui se rajoutent:

Tu devra obligatoirement tester l'adresse affect�e � ton pointeur si tu essaye de d�sallouer la m�moire d'un membre de celui-ci:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
A::~A()
{
    delete ptr->membre1;
}

posera effectivement probl�me si ptr vaut NULL et devra donc prendre la forme de

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
A::~A()
{
    if(ptr)
        delete ptr->membre1;
    /* pour faire bonne mesure :D */
    delete ptr;
}

[3DArchi]

Non, mais la meilleur solution consiste encore � encapsuler ton pointeur dans une classe qui s'en occupe sp�cifiquement ... un pointeur intelligent quoi !

[deubelte]

Non, mais la meilleur solution consiste encore � encapsuler ton pointeur dans une classe qui s'en occupe sp�cifiquement ... un pointeur intelligent quoi !

Avant de vouloir utiliser des shared pointeur,il faut je pense savoir parfaitement manipuler les pointeurs normaux

[deubelte]

j'ai une autre question, c'est sur le renvoie par r�f�rence d'une variable locale. Je le vois souvent.
Et il me semble que c'est une tr�s grosse erreur, car comportement ind�fini.
Par exemple:

int& f(){
int a=3;
return a;
}

En effet, il se trouve que l'objet a va �tre d�truit, et donc la r�f�rence va �tre un alias d'un objet qui n'existe plus.

En fait ca ne pose pas de pb pour des build in types, mais pour des objets plus complexes, qui ont entre autre de la m�moire allou�e dynamiquement, ca peut poser probl�me. En fait, il faut �viter a tout pris de renvoyer des build in types, sauf pour l'op�rateur = ou il faut renvoyer une r�f�rence sur this.
Vous �tes ok?