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