Discussion :

[h3llmo]

Bonsoir.
J'ai un petit souci lors de la libération de pointeurs, le programme a un comportement différent sous Builder C++ (Windows) et sous Kdevelop (Linux).
J'ai une classe ce qu'il y a de plus simple, mais qui contient un pointeur à l'interieur.

Code :

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

1
2
3
4
5
6
7
8
9
10
class Essai{
private:
	int *pt;
public:
	Essai();
	~Essai();
 
	void setPt ( int theValue ){*pt = theValue;}
	int getPt() const	{return *pt;}
};

Dans le constructeur, on fait un new Int sur le pointeur;
Dans le destructeur, on fait un delete pt

Dans mon main, je crée dynamiquement deux pointeurs, mais j'envoie le contenu du premier dans le deuxième:

Code :

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

1
2
3
4
Essai *essai1 = new Essai(); 
Essai *essai2 = new Essai();
 
*essai2 = *essai1;

Les deux objets ont donc maintenant un pointeur (pt) qui pointe vers la même zone mémoire.

Si je fait essai1->setPt(5); alors *pt de essai2 aura aussi 5.
Jusque là on est d'accord.

Mais si maintenant je fait un delete essai1, la zone mémoire est normalement libéré non?

Pourtant sous KDevelop si je fait juste après un essai2->setPt(3); , aucun problème, et dans le debugger on voit la zone mémoire de pt recevoir 3 aussi bien sur essai2 que sur feu essai1.

Code :

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

1
2
3
4
 
essai1->setPt(5);
delete essai1;
essai2->setPt(3); //ne devrait pas marcher

A savoir que sur Builder C++ celui-ci n'accepte pas l'affectation et sort un joli message d'erreur.

Alors, est-ce un comportement propre à Linux, ou bien ça plante mais sans que je le sache?
Si quelqu'un à une réponse à cela, merci d'avance.

[Médinoc]

Libérer une zone mémoire dans le tas ne signifie pas nécessairement rendre toute la page mémoire au système d'exploitation.
Une segfault se fait à l'échelle de la page mémoire, pas à l'échelle de huit octets.

PS: Tu connais la parade à ce problème dans le code: Soit redéfinir le constructeur de copie et l'opérateur d'affectation, soit les interdire.
Si tu les interdits, je te conseille d'implémenter quand même au minimum une fonction de swap.

[h3llmo]

Oui, c'est d'ailleurs dans l'étude des constructeurs de copie que j'ai relevé ça.

Mais faut dire que Konsole me sortait (jusqu'a présent) toujours une série de massage a la moindre écriture en zone désalloué, très sensible, contrairement a Borlan C++ sous windows dont on réperait l'erreur que lors d'une sortie inattendue.

Dans ce cas-ci, rien, comme si tout était normal. Alors comme il parait que d'autres langages ne rendent pas totalement la zone mémoire lorsqu'un pointeur pointe encore dessus je me suis dit que ça pourrait être un comportement normal, propre au compilateur gnu. Mais je penche également pour un segfault invisible.

Ca me rassure dans un sens, ou la compatibilité du code entre les deux plateformes est encore de mise.

Merci pour la réponse.

[koala01]

Salut, et bienvenue sur le forum.

A vrai dire, lorsque tu va manipuler une adresse mémoire qui a été libérée, tu occasionne un comportement indéterminé.

Cela signifie que ça peut "passer" en apparence mais faire "planter" ton application des heures plus tard, ou lancer le café ou... une bombe nucléaire.

Lors de tes tests, ca a (par malchance) passé, mais il n'est pas impossible que, si tu recompile le code maintenant et que tu réessaye il t'enverra pas une erreur de segmentation

Les compilateurs ont beau être de plus en plus efficaces et en mesure de repérer de plus en plus de comportements "à risque", il reste vrai qu'il reste assez difficile de "tracer" correctement les libération de mémoire, surtout si le delete ne se trouve pas dans la même portée que la tentative d'accès à la mémoire ou, si la même mémoire est utilisée par deux pointeurs différents, dans le cas où tu libère la mémoire allouée à l'une et que tu essaye d'accéder à l'autre...

Ceci dit, il existe une "parade" à ce problème... Peut être pourrais tu envisager l'utilisation de "pointeurs intelligents"