référence sur variable locale

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:

---

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:

---

1 2 3 4 5 6 7 8

class A{ public: A(int o):l(o){ n=0; } ~A(){ delete n; }

---

merci

Non ça ne fait rien.

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:

---

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:

---

1 2 3 4 5 6 7

A::~A() { if(ptr) delete ptr->membre1; /* pour faire bonne mesure :D */ delete ptr; }

---

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

Citation:

---

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

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?

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 ;)

Citation:

---

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

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:

---

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:

---

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 ;)

Salut,

Citation:

---

Envoyé par deubelte

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.

Citation:

---

Envoyé par deubelte

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é.