Suppression d'une instance de classe avec patron

Bonjour,

Je découvre avec joie les patrons de classe. J'ai dans l'idée de créer un patron de maillon pour liste. La conception, c'est ok, mais la suppression c'est pas opérationnel.
Je m'explique...

Je crée un maillon générique du genre:

template <class T> class Maillon {
   public:
      T Objet;
};

Puis une classe de mon imagination pour l'encapsuler dans mon maillon:

class MaClasse {
   public:
      int info;
};

Ensuite, lorsque je suis dans mon programme, je crée une nouvelle instance (dynamique) avec le patron Maillon dans lequel j'encapsule MaClasse:

Maillon<MaClasse> * monPointeur = new Maillon<MaClasse>;

Jusque là tout se déroule à merveille. Puis, lorsque l'idée me viens de supprimer l'instance dynamique, j'utilise le mot clé delete.

delete monPointeur;

Ce qui ne génère aucune erreur de compilation, et ne semble pas générer d'erreur d'exécution. Seulement, voilà, je suis maniaque et je teste si mon instance existe toujours et là horreur, l'objet dynamique existe toujours et on peut le manipuler correctement. Ce qui a le mérite de m'énerver un peu beaucoup !!!

Comment fait-on pour supprimer cette instance dynamique ? J'ai déjà cherché sur Internet sans trouver de réponse concluante.

Il y a quelque chose de que je dois ignorer et que j'espère l'un de vous sait...

Merci d'avance pour vos futures réponses.

Landercy Jean

Essaie sans les partons et tu verra que tu auras le même problème. Cela dit je n'explique pas non plus cela. Voila un exemple complet qui montre le problème:

[code]
#include <iostream>
using namespace std;

template <class T> class Maillon {
  int n;
public:
  void f();
  Maillon();
  ~Maillon();
};

template<class T> Maillon<T>::Maillon()
{
  n = -12;
}

template<class T> Maillon<T>::~Maillon()
{
  cout << "destroy" << endl;
}

template<class T> void Maillon<T>::f()
{
  n++;
}

int main()
{
  Maillon<int>* m = new Maillon<int>;
  delete m;
  m->f();
  return 0;
}
[/code]

Après le delete, on a toujours le droit de modifier m->n (qui chez moi à été modifié pendant le delete).

Bonsoir,

Je dois avouer que c'est la première fois que j'ai ce genre problème avec delete. Jusqu'ici, il s'est toujours contenté de supprimer l'objet. Faut-il comprendre qu'il n'est pas possible de détruire un objet dynamique d'une classe patron ? Ou bien existe-t-il une autre méthode ???

Je reste perplexe...

Merci quand même pour l'éclaircissement.

Jean Landercy
 

Apres un delete, la mémoire est libérée. Utiliser le pointeur apres un delete ne peut être empéché ni pendant  la compilation ni pendant l'exécution. L'objet existe toujours en mémoire parce qu'il n'a pas été écrasé par une nouvelle allocation.

Cordialement,
Xterminhate.

Bonsoir,

Merci pour cette réponse.
C'est bien ainsi que je conçois la suppression d'objet dans le tas.
Ce qui m'intrigue dans cette histoire, c'est que, d'habitude, lorsque j'utilise un pointeur vers un objet supprimé, j'ai toujours eu une erreur d'exécution, du genre ma console qui plante. Dans le cas actuel, je supprime le maillon, et si je le désire, je peux le remettre dans la liste en modifiant ses données membres (next et prev).
Je trouve ça suspect pour un objet supprimé !!!

Merci encore, je vais pousser plus loins mes investigations...

Jean Landercy

Rebonsoir,

Ca m'énerve tellement que je vous envoye un code, je viens de l'écrire et illustre formidablement bien mon problème. Je précise que je développe sur win xp, avec un éditeur texte et le compilateur borland 5 (mais je doute que cela change quelque chose à la nature même de mon problème).

Voici le listing du code "foireux":

--------------------------------------------------------------------------------

#include <iostream>
using namespace std;

template <class T> class Maillon {
 public:
  T Objet;
  int data;
  Maillon<T>() {
  }
  ~Maillon<T>() {
  }
};

class MaClasse {
 public:
  int data;
  MaClasse() {}
  ~MaClasse() {}
};

int main() {

 // Création d'une instance dynamique:
 Maillon<MaClasse> * pMMC = new Maillon<MaClasse>;
 
 // Modifications des variables membres:
 pMMC->Objet.data=1;
 pMMC->data=3;
 
 // Affichage:
 cout << pMMC->data << " " << pMMC->Objet.data << endl;
 
 // En théorie une suppression:
 delete pMMC;
 
 // Re modifications des variables membres:
 pMMC->Objet.data=2;
 pMMC->data = 9;
 
 // Affichage:
 cout << pMMC->data << " " << pMMC->Objet.data << endl;
 
 // Re-suppression (si, si je vous jure, ça fait même pas un erreur à l'exécution !!!)
 delete pMMC;
 
 // Re-re-modification... etc...
 pMMC->Objet.data=1;
 
 cout << pMMC->data << " " << pMMC->Objet.data << endl;

 system("PAUSE");
 return 0;
}

-----------------------------------------------------------------------------------------

Tout ça, ça me dépasse. Moi qui croyait que j'avais comrpis quelque chose. Snif !!!

Merci d'avances pour vos réponses.

Jean Landercy

Quel est le problème ?

Tu as écrit des données en mémoire.... et tu démontres, en bricolant avec les adresses, qu'en l'absence de réutilisation de cette mémoire, les données y sont encore intactes. Ok, tu as vérifié que le processus de rafraichissement de tes barettes de SDRAM fonctionne bien.

La pérénité des données stockées dans un espace mémoire désalloué n'est pas assurée. Le comportement est indeterminé dans le temps. Même si tes données sont ré-utilisables immédiatement apres le delete, a court terme elles finiront par être écrasées par de nouvelles allocations et provoquer une erreur grave dans l'execution...

Insère quelques new / delete juste apres ton delete pMMC et on en reparle....

Cordialement,
Xterminhate.

Oui il n'y a aucun problemes, delete detruit l'objet et libere la memoire, apres le pointeur contient une adresse invalide.
Sur la meme idée que xterminhate, réaloue le mème objet juste apres (normalement l'allocateur devrais reservé le meme emplacement mémoire).

Normalement une zone qui a été désalouée n'est plus accessible par le programme. Je suis d'accord avec jeandelercy, il y a un vrai problème.

Je ne vois pas en quoi, accéder au tas qui est réservé au process, est illégale. L'organisation interne du tas n'est pas contrôlé par le système d'exploitation... Le segfault intervient lorsque le process tente d'accéder à une zone mémoire autre que son propre tas.

Cordialement,
Xterminhate.