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?

[koala01]

En deux mots: on ne renvoie jamais une référence sur un objet temporaire à la fonction.

Qu'il s'agisse d'un type défini par l'utilisateur ou d'un type primitif ne change strictement rien: toute variable définie sans avoir recours à l'allocation dynamique dans une fonction sera systématiquement détruite en sortie de fonction.

Tu ne peux donc envisager de renvoyer une référence que:

• si tu veux renvoyer un membre d'une classe
• si tu veux renvoyer l'objet courent (ce qui est pointé par this)

Dans tous les autres cas, renvoie une valeur, et non une référence

[deubelte]

si tu veux renvoyer un membre d'une classe

je comprends l'autre point, mais pas celui-là. Peux tu stp me donner un exemple?
merci

[koala01]

Tu peux renvoyer une référence uniquement si l'élément renvoyé existe en dehors de la fonction.

Soit, tu veux en réalité récupérer l'objet courent:

Code :

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

1
2
3
4
5
6
7
8
9
class A
{
    public:
        A & foo()
        {
            /* ... */
            return *this;
        }
};

Soit, tu renvoies un membre de la classe:

Code :

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

1
2
3
4
5
6
7
8
9
10
class A
{
    public:
        Type & foo()
        {
            return t;
        }
    private:
        Type t;
};

Si tu n'es pas dans une de ces configurations, tu renvoie une valeur

[EDIT]Nota: l'idéal, dans la deuxième solution reste toujours de renvoyer une référence constante et de rendre la fonction constante, histoire d'éviter toute modification "extérieure" inopportune

[3DArchi]

Salut,

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

Une approche pertinente est alors de travailler sur tes propres enveloppes RAII pour la gestion des pointeurs afin d'en comprendre les raisons, les variétés et les choix d'implémentations possibles etc.

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?

Avoir une référence ou un pointeur sur un objet détruit est un comportement indéterminé que l'objet soit un type natif ou un type complexe. Tout simplement car les environnements sont susceptibles de réutiliser l'espace libéré qu'il soit sur la pile ou sur le tas dès qu'il est libéré.