Discussion :

[koala01]

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 :

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

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"

[vinceouille]

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 :

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(); //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 :

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

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

[cob59]

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

[Médinoc]

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

[Jean-Marc.Bourguet]

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.

[vinceouille]

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.

[Médinoc]

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

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

[cob59]

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.

[Jean-Marc.Bourguet]

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.

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.

[cob59]

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.

[Arzar]

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 :

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

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