Discussion :

[NainTernaute]

Bonsoir à tous,

J'ai un comportement assez étrange avec delete, c'est pourquoi je me tourne vers vous ce soir ; en effet, je possède une classe contenant une variable membre de type pointeur, que j'alloue dynamiquement. (m_machin = new Machin() )Dans le destructeur de la classe en question, je détruis cette objet avec un simple delete m_machin ; j'ai en effet pu lire ici et là que delete s'occupait de vérifier l'existence du pointeur. Seulement, quand je fais simplement un delete m_machin, j'ai l'erreur suivante :

Code :

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

1
2
malloc: *** error for object 0x2: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Pourtant, mon objet a bien été alloué dynamiquement, j'ai fais des tests.. En remplaçant par un

Code :

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

1
2
if (m_machin)
  delete m_machin

Ça marche mieux, ce qui semble logique ; mais je ne comprends pas pourquoi mon objet a été désalloué _avant_ que je ne fasse l'appel au delete ? Je précise que ma classe ne fait rien d'autre, c'est juste une classe de test toute vide là. ^^

Si vous avez une idée du pourquoi du comment !

Merci d'avance

[ZiGoM@r]

j'ai en effet pu lire ici et là que delete s'occupait de vérifier l'existence du pointeur.

Il vérifie seulement si il est différent de NULL, exactement comme tu le fais toi même.

Envois le code, on ne sait jamais.

[kessoufi]

Salut

j'ai deux pistes pour toi :

- si le pointeur n'est pas initialisé à null lors de la construction : si tu ne passe pas par le new, à la destruction ça peut planter

- est ce que tu interdis la génération du copy constructor et de l'opérateur =
si tu ne le fais pas et que le compilateur le génère pour toi, alors ta classe ayant un pointeur, ce dernier sera partagé entre les copies et il sera 'deleted' autant de fois, et au deuxième delete ça plantera, ça arrive typiquement quand tu utilise un std::vector<TaClasse>

Cdt

[NainTernaute]

En fait, ma classe héritait d'une RenderWindow de la SFML, et je pense que c'est ça qui posait problème ; au moment de l'appel à

Code :

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

Close()

les objets dynamiques devaient probablement être déjà détruits, ou quelque chose du genre.
Maintenant que ce n'est plus un héritage direct, pas de soucis.