Discussion :

[Romain227]

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 :

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

[koala01]

Salut

Bonjour à tous,

Je suis débutant en C++

Ca a été le cas de tous

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

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

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

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

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)

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

ex:

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

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

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 (bon, là, j'admets, j'exagère un tout petit peu )

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 )

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 ), il te sera possible (et nous t'encourageons grandement à le faire ) 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"

[Romain227]

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

[oodini]

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

[Steph_ng8]

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

[ptyxs]

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

[koala01]

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

"Tout vient à point à qui sait attendre"

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

[Emmanuel Deloget]

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

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

[Mat.M]

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

si tu alloues un tableau par exemple avec

Code :

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

int *tab=new int[10]

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

Code :

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

delete [] tab

et non

Code :

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

delete tab

il me semble

[ptyxs]

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

[Médinoc]

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

Code C++ :

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

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

[Steph_ng8]

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

si tu alloues un tableau par exemple avec

Code :

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

int *tab=new int[10]

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

Code :

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

delete [] tab

et non

Code :

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

delete tab

il me semble

Oui, en effet.

[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 :

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

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

[Jean-Marc.Bourguet]

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 :

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

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.

[vinceouille]

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

Code :

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

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.

[Jean-Marc.Bourguet]

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

[cob59]

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.

[Jean-Marc.Bourguet]

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.