delete de pointeur

Bonjour à tous,

Je suis débutant en C++ et j'ai une question au sujet de la commande delete des pointeurs.

Ma question est la suivante. Lorsque l'on effectue un delete, on libère la mémoire référencée par ce pointeur qui peut donc à nouveau être utilisée. Le pointeur pointe toujours sur la case mémoire libérée mais toute commande qui accède au contenu de la mémoire est refusée par le compilateur

ex:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

// allocation dynamique d'un tableau de trois entiers   int * tab = new int [3] ;   // initialisation du tableau   for (int i(0); i < 3 ; i++) { *(tab + i) = 2; }   // liberation de la memoire   delete tab;   cout << tab << endl ; // OK : contient l'adresse du premier entier du tableau   cout << *tab << endl ; // NOK

---

J'ai lu sur un site que cette situation était risquée, dans la mesure ou la mémoire étant libérée et le pointeur tableau pointant toujours sur la mémoire, il fallait affecter le pointeur à 0 pour éviter tout problème ( avec l'instruction tab(0); )


Mais étant donné que je ne peux accéder aux valeurs par le pointeur après delete (cf NOK), j'ai du mal à voir où se situe le risque.

Merci de vos lumières.

Romain.

Salut

Citation:

---

Envoyé par Romain227

Bonjour à tous,

Je suis débutant en C++

---

Ca a été le cas de tous :D

Citation:

---

et j'ai une question au sujet de la commande delete des pointeurs.

---

parle plutot d'instruction, c'est plus juste :P Mais les pointeurs sont souvent la bête noir des débutants :D

Citation:

---

Ma question est la suivante. Lorsque l'on effectue un delete, on libère la mémoire référencée par ce pointeur qui peut donc à nouveau être utilisée.

---

C'est le principe, en effet...

Citation:

---

Le pointeur pointe toujours sur la case mémoire libérée

---

C'est en fait un peu plus complexe... et il me semble utile de préciser, pour être sur que tu comprenne la suite :P

Un pointeur est une variable numérique qui contient l'adresse mémoire à laquelle on trouvera (normalement) la donnée du type attendu.

Après un delete, la mémoire correspondante (à la variable du type attendu) est effectivement libérée, mais la valeur de l'adresse que l'on trouve dans le pointeur elle, n'a pas changé.

On ne peut donc absolument pas donner la moindre certitude quant à ce que l'on va trouver à cette adresse mémoire : *peut etre* (si on a un peu de chance) retrouverons nous les données que l'on y avait mise, mais peut accéderons nous à de toutes nouvelles données...

C'est ce que l'on appelle un "comportement indéfini" (on n'a aucun moyen de savoir ce qui pourra se passer si on accède au contenu de la mémoire qui se trouve à cette adresse)

Citation:

---

mais toute commande qui accède au contenu de la mémoire est refusée par le compilateur

ex:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

// allocation dynamique d'un tableau de trois entiers   int * tab = new int [3] ;   // initialisation du tableau   for (int i(0); i < 3 ; i++) { *(tab + i) = 2; }   // liberation de la memoire   delete tab;   cout << tab << endl ; // OK : contient l'adresse du premier entier du tableau   cout << *tab << endl ; // NOK

---

---

As tu essayé de compiler cet exemple (en le plaçant, par exemple, dans les accolades de la fonction main) :question:

La surprise du chef, c'est que cela compile absolument sans problème!!!

Le compilateur n'a en effet absolument pas l'intelligence pour se rendre compte qu'il ne peut pas accepter ce code qui est, syntaxiquement parlant, tout à fait valide.

Par contre, le code a beau "sembler correct", il est particulièrement risqué d'essayer de l'exécuter, pare que nous nous confronterions à ce fameux comportement indéfini dont je viens de parler:

dans le meilleur des cas, tu auras "simplement" une sortie aberrante (chez moi, j'obtiens... 8482800... mais si j'essaye demain, je pourrais très bien avoir autre chose :P)...

Dans le pire des cas, cela pourrait provoquer le plantage complet de l'ordinateur, voir transmettre un ordre de lancer des missiles intercontinentaux sur un réseau hyper secret :P (bon, là, j'admets, j'exagère un tout petit peu :D )

Citation:

---

J'ai lu sur un site que cette situation était risquée, dans la mesure ou la mémoire étant libérée et le pointeur tableau pointant toujours sur la mémoire, il fallait affecter le pointeur à 0 pour éviter tout problème ( avec l'instruction tab(0); )

---

Non pas avec tab(0), mais avec tab=0; ou, de manière plus explicite avec tab=NULL ( tab(0) est éventuellement admis, mais uniquement lors de la déclaration de la variable tab ;) )

Citation:

---

Mais étant donné que je ne peux accéder aux valeurs par le pointeur après delete (cf NOK), j'ai du mal à voir où se situe le risque.

---

Justement, c'est là qu'est l'astuce : tu ne peux pas (comprend : il ne faut pas que tu essaye d') y accéder parce qu'il y a un risque à le faire, mais les outils dont on dispose n'ont aucun moyen de t'en empêcher, et accepteront sans rechigner le fait que tu essaye de le faire...

Il faut donc, veiller, lorsque tu travailles avec des pointeurs, que tu leur donnes une valeur que tu pourras identifier comme étant invalide, que ce soit avant que tu ne leur affecte une adresse valide (avant de leur affecter le résultat de new)ou après avoir invalidé l'adresse qui leur est affectée (après avoir libéré la mémoire avec delete).

La seule adresse que tu peux identifier comme étant invalide sans risque de te tromper, c'est.... l'adresse 0 (ou NULL) qui, de plus, est évaluée à false lorsqu'il y a conversion implicite en booléen.

Si tu respecte cette recommandation (faite avec moultes insistance :D ), il te sera possible (et nous t'encourageons grandement à le faire :D ) de vérifier si l'adresse pointée par le pointeur est bel et bien valide avant toute tentative d'accéder à "ce qui est pointé par le pointeur" ;)

Bonjour,

ton explication est très claire, merci beaucoup. L'idée à retenir est donc d'affecter le pointeur à une adresse non valide après un delete pour couper l'accès à la mémoire libérée, et ce en dépit du fait que le compilateur le tolère.

Bonne journée.

Romain

Le rôle de l'affectation à 0, NULL, ou nullptr, est de pouvoir effectuer un test sur la valeur du pointeur.

Si au moment du test, on suppose que tout delete est suivi d'une affectation à 0, on sait ce qu'il en est quant à la validité du pointeur.

Si on ne fait pas cette affectation, on peut toujours tester, mais on peut difficilement en déduire quelque chose...

Bonjour,

Le fait d'affecter NULL à un pointeur qui ne pointe pas/plus sur une zone mémoire allouée a un autre intérêt.
Cela permet d'éviter de tenter de libérer plusieurs fois une même zone mémoire.

Dis comme ça, ça peut paraître idiot.
Mais ce cas peut tout de même arriver, et de manière assez vicieuse, donc difficile à contrôler.

Par exemple, dans une boucle, on peut revenir plusieurs fois au même endroit sans s'en rendre compte.
Ou alors si la libération d'une ressource peut avoir lieu dans plusieurs endroits du programme.

Puisqu'un delete sur NULL est parfaitement valide (voir la F.A.Q.), on gagne en sûreté.

Noter qu'en C++2011 on affecterait dans ce cas le pointeur invalide plutôt à
nullptr
qu'à
NULL

Citation:

---

Envoyé par ptyxs

Noter qu'en C++2011 on affecterait dans ce cas le pointeur invalide plutôt à
nullptr
qu'à
NULL

---

Oui, mais C++2011 vient "à peine" d'être voté, et son support actuel est encore particulièrement parcellaire (tous compilateurs confondus).

C'est à tel point que le support de cette nouvelle norme doit être explicitement demandé à la compilation, et que c'est la norme de 2003 qui est supportée par défaut!

On peut donc citer le fait que, bientôt, nous disposerons d'un terme clairement explicite, mais je ne suis pas sur que ce soit primordial dans le cadre de cette discussion, où l'on essaye déjà d'expliquer "simplement" le fonctionnement et les dangers des pointeurs à quelqu'un qui débute :P

"Tout vient à point à qui sait attendre" :D

nullptr est reconnu par les dernières versions des principaux compilateurs (g++, Visual C++, Intel C++). Il n'est donc pas incongru de l'évoquer.

Citation:

---

Envoyé par oodini

nullptr est reconnu par les dernières versions des principaux compilateurs (g++, Visual C++, Intel C++). Il n'est donc pas incongru de l'évoquer.

---

g++ nécessite quand même d'utiliser -std=c++0x pour pouvoir avoir accès aux nouveautés du C++11. Tant que ce standard n'est pas pris par défaut par g++, il est sensé de parler d'abord des fonctionnalités de C++03 :)

Ceci dit, nullptr ayant des avantages non négligeables par rapport à NULL, il est très justifié d'appeler à son utilisation. J'eut aimé que NULL soit une macro sur nullptr dans C++11, ce n'est pas le cas - tant pis :)

Le problème est que ce n'est pas possible : Ça casserait bien trop de code.

Certes, 95% au moins du code qui serait cassé est du code qui mérite d'être cassé (et j'espère qu'à termes les compilateurs fourniront un flag de compilation qui rend NULL égal à null_ptr), mais tout de même. A ce sujet, on peut trouver sur le net une présentation de null_ptr par Stefan T Lavavej (est-ce celle-ci ?) qui décrit une expérience où il a recompilé Windows avec cette modification de la macro NULL, et où il parle des problèmes qu'il a rencontré.

bonjour il me semble qu'il y a une erreur dans le code:

si tu alloues un tableau par exemple avec

Code:

---

int *tab=new int[10]

---

pour effacer le tableau au complet il faudrait déclarer ceci

Code:

---

delete [] tab

---

et non

Code:

---

delete tab

---

il me semble

Citation:

---

Envoyé par JolyLoic

Le problème est que ce n'est pas possible : Ça casserait bien trop de code.

Certes, 95% au moins du code qui serait cassé est du code qui mérite d'être cassé (et j'espère qu'à termes les compilateurs fourniront un flag de compilation qui rend NULL égal à null_ptr), mais tout de même. A ce sujet, on peut trouver sur le net une présentation de null_ptr par Stefan T Lavavej (est-ce celle-ci ?) qui décrit une expérience où il a recompilé Windows avec cette modification de la macro NULL, et où il parle des problèmes qu'il a rencontré.

---

Avec null_ptr on est sûr de tout casser, vu que c'est nullptr...:mrgreen:

En fait, le but de NULL/nullptr par rapport à laisser le pointeur tel quel, c'est pouvoir faire ceci:

Code:

---

1 2 3 4

if(ptr != nullptr) { ... }

---

Pour le coup d'une macro NULL, j'en ai déjà utilisée une sous Windows, mais je suis tombé sur quelques problèmes avec MFC notamment:

• Certaines fonctions passent NULL en tant que LPARAM et WPARAM, d'où nécessité de supporter ces casts
• Certaines fonctions COM utilisent __uuidof(NULL), la classe doit donc être déclarée avec __declspec(uuid("00000000-0000-0000-0000-000000000000"))

Citation:

---

Envoyé par Mat.M

bonjour il me semble qu'il y a une erreur dans le code:

si tu alloues un tableau par exemple avec

Code:

---

int *tab=new int[10]

---

pour effacer le tableau au complet il faudrait déclarer ceci

Code:

---

delete [] tab

---

et non

Code:

---

delete tab

---

il me semble

---

Oui, en effet.

Bonjour,

Je me permet de réactiver ce sujet car je me pose une question sur l'allocation dynamique :

Par hasard, je me suis rendu compte qu'après avoir fait un delete sur un objet, et un new juste après pour créer un objet de même classe, l'adresse alouer était exactement la même que l'adresse du premier objet. De cette façon, je pouvait utiliser le pointeur qui a fait l'objet du delete sans problème. Un exemple en code :

Code:

---

1 2 3 4 5 6 7 8 9 10

Objet *adr; Objet *bdr; adr=new Objet();   delete adr;   bdr=new Objet();   adr->fonction();

---

L'appel de la fonction de Objet fonctionne parfaitement. Mais il n'y a qu'un seul objet pointé à la fois par adr et bdr.

Est-ce que cela est normale ou seulement le fait du hasard que la création d'un nouvel objet renvoie exactement la même adresse qu'un objet supprimer juste avant ??

Est-que l'on peut se servir de cette particularité sans risque ? Par exemple en voulant réinitialiser un objet par un delete puis un new sans changer son adresse ...

Citation:

---

Envoyé par vinceouille

Bonjour,

Je me permet de réactiver ce sujet car je me pose une question sur l'allocation dynamique :

Par hasard, je me suis rendu compte qu'après avoir fait un delete sur un objet, et un new juste après pour créer un objet de même classe, l'adresse alouer était exactement la même que l'adresse du premier objet. De cette façon, je pouvait utiliser le pointeur qui a fait l'objet du delete sans problème. Un exemple en code :

Code:

---

1 2 3 4 5 6 7 8 9 10

Objet *adr; Objet *bdr; adr=new Objet();   delete adr;   bdr=new Objet();   adr->fonction();

---

L'appel de la fonction de Objet fonctionne parfaitement. Mais il n'y a qu'un seul objet pointé à la fois par adr et bdr.

Est-ce que cela est normale ou seulement le fait du hasard que la création d'un nouvel objet renvoie exactement la même adresse qu'un objet supprimer juste avant ??

Est-que l'on peut se servir de cette particularité sans risque ? Par exemple en voulant réinitialiser un objet par un delete puis un new sans changer son adresse ...

---

Pur hasard. Alloue deux objets liberes-les, realloue un objet. Si tu as bien la meme adresse que le dernier, change l'ordre de liberation, je parie que tu n'auras plus la meme adresse.

Et bien de plus en plus étrange, avec ce petit changement :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

Objet *adr; Objet *bdr; adr=new Objet(); bdr=new Objet();   delete bdr delete adr;   bdr=new Objet();   adr->fonction();

---

la fonction marche toujours et adr et bdr pointe tout les deux sur la même adresse. J'ai suivi avec le debugger et le fait de realouer "bdr" affecte une adresse à "bdr" (ça c'est normale) mais également la même adresse à "adr" !!!

Je précise que je travaille sur QtCreator et windows 7.

Faire delete ptr ne change pas la representation de ptr, ca la rend juste invalide.

Je ne vois pas ce qu'il y a de choquant à ce que la nouvelle adresse de bdr soit l'ancienne adresse de adr. Par contre, ce qui est choquant, c'est que tu ne mettes pas adr et bdr à NULL (ou nullptr) après l'appel des 2 delete.

Citation:

---

Envoyé par cob59

Par contre, ce qui est choquant, c'est que tu ne mettes pas adr et bdr à NULL (ou nullptr) après l'appel des 2 delete.

---

Pourquoi? Normalement ca sort immediatement du scope.

il faut comprendre que l'adresse à laquelle va se trouver un objet que tu crées avec new va exclusivement dépendre des disponibilités du système, entre autres, au niveau de l'espace contigu dont il faut disposer en mémoire pour y placer l'ensemble des données.

Bien sur, si tu viens d'indiquer au système qu'un espace X peut etre considéré comme disponible, il y a des chances, si tu demande au système de te fourni un espace mémoire identique, pour qu'il te renvoie l'espace mémoire que tu viens juste d'indiquer comme dispo, tout comme il y a cependant exactement le même nombre de chance pour qu'il t'envoie un espace mémoire contigu suffisant à n'importe quelle autre adresse.

Il ne faut donc en aucun cas considérer, si tu écris un code proche de

Code:

---

1 2 3 4 5 6 7

int main() { Type *ptr = new Type; /* ... */ delete ptr; Type * other = new type; }

---

que ptr et other contiendront la même adresse mémoire...

Au mieux, avec beaucoup de chance, ce n'est qu'une particularité d'un compilateur particulier, qu'une liberté prise par celui-ci pour éviter d'avoir à relancer le processus, malgré tout relativement couteux, d'une allocation dynamique par le système.

Tu prendrais donc un énorme risque à considérer ce comportement comme "normal" ;)

Rien ne me choque dans tout cela(il en faut plus ...), j'essaye juste de comprendre la logique, je prend conscience que tout ça n'est pas très rigoureux mais ça permet de mieux comprendre ce qui se passe dans la machine .. Je crois avoir compris (commentaire dans le code):

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

Objet *adr; Objet *bdr; adr=new Objet(); bdr=new Objet();   delete bdr; delete adr;   bdr=new Objet(); //aloue une adresse à "bdr" qui est "par hasard" la même que "adr" (mais le hasard se produit à chaque fois... )   adr->fonction(); // le fait qu'un objet ait été aloué à l'ancienne adresse pointé par "adr" fait que adr, qui possèdent toujours la valeur l'adresse initial, peut être utilisé.

---

Par contre si on code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

Objet *adr; Objet *bdr; adr=new Objet(); bdr=new Objet();   delete bdr; delete adr; adr=NULL; //"efface" la valeur de l'adresse dans "adr"   bdr=new Objet(); //aloue une adresse à "bdr" qui est "par hasard" (mais le hasard se produit à chaque fois) la même que l'ancienne "adr"   adr->fonction(); // ne marche plus car adr ne contient plus d'adresse

---

Je m'interroge juste sur ce hasard qui se produit à chaque qui affecte la même adresse. Cela se produira-t-il vraiment à chaque fois si on fait le new juste après le delete ?

Edit : koala01 a répondu à mes interrogations. Merci beaucoup, je me sens moins idiot maintenant !!!!

Citation:

---

Envoyé par Jean-Marc.Bourguet

Pourquoi? Normalement ca sort immediatement du scope.

---

Pas compris... qu'est-ce qui sort du scope ?

@vinceouille
Il ne faut pas y voir du "hasard".
Peut-être que dans ce contexte précis le gestionnaire de mémoire décide de gérer le tas comme une pile LIFO...

Pour ce qui est d'obtenir une erreur quand on pointe sur un objet détruit, il existe une façon qui devrait être plus reproductible qu'un simple "je delete et j'espère que la page mémoire a été rendue": Les redéfinitions de fonctions virtuelles pures

Citation:

---

Envoyé par cob59

Pas compris... qu'est-ce qui sort du scope ?

---

La variable que tu veux mettre a NULL. C'est aussi sense que de remettre a 0 des variables entieres apres les avoir utilisees.

Citation:

---

Envoyé par Jean-Marc.Bourguet

La variable que tu veux mettre a NULL. C'est aussi sense que de remettre a 0 des variables entieres apres les avoir utilisees.

---

Peut être que cela permet de ce prémunir d'appel à partir de pointeur non valide (et donc d'une erreur) en utilisant "if (ptr!=NULL) " avant l'appel.

Là n'est pas la question: La question est pourquoi faire ça à la fin du bloc qui contient leur déclaration.

Ok, d'accord avec toi, si le pointeur est définis dans le bloc OK. Mais dans le cas d'un pointeur définis et utilisé ailleurs c'est quand même utile ...

Citation:

---

Envoyé par Médinoc

Là n'est pas la question: La question est pourquoi faire ça à la fin du bloc qui contient leur déclaration.

---

Je ne crois pas qu'il ait précisé où débutait ni où finissait son scope dans ses exemples de code. Apparemment il continue d'utiliser adr et bdr après leur delete, donc il me semble préférable de les mettre à NULL, pour que l'appel de adr->fonction(); fasse ce qu'il est censé faire : planter.

Citation:

---

Envoyé par vinceouille

Ok, d'accord avec toi, si le pointeur est définis dans le bloc OK. Mais dans le cas d'un pointeur définis et utilisé ailleurs c'est quand même utile ...

---

Les delete, c'est quand meme rare, c'est souvent gere par des classes faites pour ca (voir smart pointer). Meme sans les utiliser, dans la plupart des cas, on est en fin de vie de l'objet et assigner NULL ne sert a rien. Dans la plupart des cas restant, on va assigner tres rapidement un pointeur valide vers un autre objet. Les cas ou assigner NULL est sense existent, mais sont rares. Suffisemment rare pour qu'en faire une pratique systematique me semble tenir d'un culte du cargo.

Citation:

---

Envoyé par cob59

Je ne crois pas qu'il ait précisé où débutait ni où finissait son scope dans ses exemples de code. Apparemment il continue d'utiliser adr et bdr après leur delete, donc il me semble préférable de les mettre à NULL, pour que l'appel de adr->fonction(); fasse ce qu'il est censé faire : planter.

---

Il fait des essais pour chercher a comprendre (ce qui peut aider, mais il faut faire attention a faire la part de hasard, de specifique a l'implementation et de garanti, ce qui n'est pas facile), c'est le genre de contextes ou les conseils de style ne sont pas particulierement pertinents.

Ce n'est pas qu'un conseil de style, puisqu'on facilite le debug en transformant un comportement indéterminé (déréférencement d'un pointeur désalloué) en un plantage pur et simple.

Après, que cette situation soit occasionnelle ou non, ce n'est pas la question ; je n'ai rien voulu généraliser.

Citation:

---

Envoyé par vinceouille

Edit : koala01 a répondu à mes interrogations. Merci beaucoup, je me sens moins idiot maintenant !!!!

---

Pour finir de se convaincre, une preuve supplémentaire, avec du code, que se reposer sur ce comportement est dangereux :

(windows 7, visual studio 2012)

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 27 28 29 30 31 32 33 34

#include <iostream> #include <string>   struct Objet { std::string toto; };   int main() { Objet *adr; Objet *bdr; int i = 0; while(1) { adr=new Objet();   delete adr;   bdr=new Objet();   if(adr != bdr) break;   delete bdr; i++; }   std::cout << "numero iteration " << i << std::endl; std::cout << adr << std::endl; std::cout << bdr << std::endl; system("PAUSE"); }

---

Ce code affiche :

Citation:

---

numero iteration 2046
000B8258
000B9C58
Press any key to continue . . .

---

Paf, 2045 fois durant bdr s'est retrouvé à la même adresse que adr comme tu l'as observé, sauf que manque de bol à la 2046ème fois, les adresses sont différentes ! :D
Pourquoi 2046 , va savoir ! 2046, c'est très proche de 2048, qui ressemble a une limite classique qu'on rencontre souvent en informatique. Peut être que l'allocateur maintient en interne une sorte de liste de taille max 2048 et une fois la limite atteinte change de stratégie ? Ou peut être pas du tout, on ne sait pas, l'allocateur est une boite noire...

il faut aussi noter que chez moi ce même code lancé depuis visual studio avec le debuggeur attaché (F5) semble rester indéfiniment dans le while, donc bdr se retrouve toujours à la même adresse que adr. Il faut le lancer sans le debuggeur (ctrl+F5) pour voir le comportement que j'ai montré plus haut. Donc là aussi on constate que le comportement de l'allocateur peut changer d'une manière assez imprévisible, en fonction d'un paramètre extérieur qui semble à première vue ne rien à voir avec tout ça.