Destructeur

pi€rre Messages postés 76 Statut Membre -  
 marvinrouge -
Salut tout le monde
je fait un programme en C++ avec tout plein d'objets.
ces objets ont des pointeurs et donc j'ai refait mes constructeurs par défaut . je voudrais savoir pourquoi dès que je met les destructeurs j'ai des problèmes d'acces memoire
A voir également:

5 réponses

Canard007 Messages postés 5931 Date d'inscription   Statut Contributeur Dernière intervention   215
 
En general c'est du a un pointeur nul ....
0
pom
 
salut Pierre, je te conseille de tester tes classes une par une et séparément bien entendu afin de cibler au mieu l'erreur.
Tu n'as pas le droit d'effacer un pointeur déjà supprimé.
Au lieu de faire delete p; je te conseille de faire :
if (p !=NULL) delete p;

Pour éviter les pointeurs fous, quand tu deletes un pointeur, réinitialise le à NULL. Peut-être que ton bug vient du faite que tu crois que ton pointeur pointe sur un objet mais peut etre qu'il pointe sur autre chose...

Regarde aussi si tu ne pointes pas un éléments d'un tableau (si tu en utilises bien entendu) hors zone. Dans ce cas tes assert ne vérifient pas toutes les conditions.

Mais teste tes classes une par une avec un super méga jeu de tests. C'est long, pénible mais après tu es sur à 100% que ca marche (sous réserve que tu aies bien testé TOUTES les situations possibles et inimaginables.

Salut
Pom
0
pi€rre Messages postés 76 Statut Membre
 
merci pour les conseils,
j'ai ajouté les tests des pointeurs nuls avant de les libérer
mais j'ai un problème:
quand j'execute le programme j'ai l'erreur suivante:
user breakpoint called at code XXXX.
au debuggeur j'ai remarqué que cette erreur se faisait à lexecution de n'importe quel free()
J'ecoute tout vos conseil
merci d'avance

@+
pierre L.
0
pom
 
Je ne sais pas utiliser le débugger et je ne sais pas ce qu'est un free(), alors je veux bien que tu m'expliques.

Sinon, pour débugger j'ai l'habitude de mettre des cout<<"\n\ntoto\n\n"; après chaque ligne pour cibler l'erreur. Et bien entendu j'affiche les résultats de chaque variable (tu vas surement me dire que le débugger fait ca mais je ne sais pas l'utiliser).

Pourrais-tu nous envoyer le morceau de prgm qui plante ?
0
Canard007 Messages postés 5931 Date d'inscription   Statut Contributeur Dernière intervention   215
 
Programmer sans debugger je sais pas moi c est comme bricoler sans outils c est possible mais put1 comment tu galére...

C'est quoi ton compilateur si je le connait je te donne quelques trucs pour le debugger ;-)
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
pom
 
oui oui je galère un peu, surtout que sur ce foru vous ne faites que parler de debugger par-ci, debugger par la

mon compilateur est celui fourni avec mandrake 9.2 (ce doit etre le gcc 3.1 ou 3.2 non ?)

merci
0
marvinrouge
 
Salut Pom

free (en C) ~ delete (en C++)

ATTENTION
on utilise free sur les objets alloués avec malloc
on utilise delete sur les objets alloués avec new

si on mix malloc/delete ou new/free ça plante ...

le débugger doit s'appeelr gdb

tapes
man gdb
+ ENTER

dans ton invite de commande
0
pi€rre Messages postés 76 Statut Membre
 
salut
si on ne mixe pas et qu'on fait malloc/fre qu que ca plante avec l'erreur dite plus haut ???
merci de m'aider
bon courrage a tous

@+
pierre L.
0
pom > marvinrouge
 
Salut marvinrouge

man gdb me donne des explications pourtant claires mais je n'arrive pas à utiliser toutes les options.

Quand je tape run (après avoir tapé gdb out, où out est mon exécutable) il m'exécute tout le prgm donc pas d'intéret.

J'ai essayé break tir_multiple.h tir_multiple (la c'est ma fonction qui s'appelle tir_multiple) mais rien de concluant.

Je voudrais afficher étape par étape (d'ou le step ou next si j'ai bien compris) et afficher à chaque fois la pile et le tas.

Peux-tu me donner une exemple d'utilisaton de gdb s'il te plait ?

merci
pom
0
marvinrouge > pi€rre Messages postés 76 Statut Membre
 
Salut Pierre,

envoies ton code et on le corrige
0
marvinrouge > pom
 
c'est très loin mes souvenirs de gdb

et gros il faut compiler avec une option qui dit "on utilisera un débugger après"

gcc <option> ...

puis n débuggue

gdb <optionsq> a.out

(à vérifier ...)
0