Bonjour
 
comme l'indique le titre, j'ai un problème d'erreur de segmentation que je ne comprends pas:
 
ça, c'est unité.cpp, c'est à ce moment qu'il va y avoir l'erreur

actions est un vector de Action*
 
 
ça, c'est le constructeur de ActionAVANCER:

 
et ça, c'est le constructeur de Action, la classe abstraite mère de ActionAVANCER:

 
 
donc quand ça marche (oui parceque des fois ça marche... mais c'est plutôt aléatoire)
j'ai comme résultat dans ma console:
 
on avance
x: 45.86    y: 21.26     z: 0
Création d'une action
création d'une actionAVANCER
je suis: commandeur  et je vais: x: 45.86    y: 21.26     z: 0
 
normal...
 
quand ça bloque j'ai:
on avance
x: 43.7    y: 16.58     z: 0
Fatal signal: Segmentation Fault (SDL Parachute Deployed)
 
donc on dirait que le constructeur n'est jamais appelé puisqu'il n'affiche même pas les phrases de test...
 
si vous avez une idée pour me débloquer, merci d'avance...

c'est louche, ça... Qu'est-ce que tu voulais faire exactement ? Que sont catégorie et BATIMENT ?
 
Sinon, tu devrais faire tes impressions de debug avec cerr plutôt que cout

On dirait des flags, tout simplement .... du genre, en C :

 
Donc apres tu fais un "ou" logique pour appliquer le flag, et un "et" logique pour le tester. Si ca n'est pas clair, convertit les constantes ci dessus en binaire et tu comprendras
 
 
Quant a la segfault, tu devrais initialiser la SDL comme ca :

 
Et apres tu recuperes l'erreur avec gdb ou visual studio, et tu nous indique la ligne exacte qui fait planter.

Pour ce qui est de ma catégorie, c'est exactement ce que j'ai fait, en fait je ne vois pas d'autres moyens de le faire. Ca permet de savoir si une unité est mobile ou non, si elle peut en construire d'autres, en réparer, attaquer...
 
Bon sinon je vais initialiser la SDL comme Ace17 me l'a dit, d'autant plus que je ne sais pas ce que c'est le parachute de la sdl.
 
Je ne sais pas non plus ce que sont gdb et visual studio.
je suis sous linux (debian sarge), ca  peut être utile de le préciser.
 
Oui je devrais utiliser cerr, mais l'habitude de taper cout... dsl

un enum ?

Bon alors j'explique pour gdb. C'est tout simplement un debogueur sous Linux. Son emploi te permettra de trouver la ligne qui a génere la segfault. Sinon tu peux également farcir ton programme de cout/printf pour essayer de trouver ou elle se trouve, mais avec gdb c'est plus rapide et plus simple.
 
En gros, voici comment se servir de gdb :
gdb ./monprogramme
run
Et maintenant, pour peu que tu aies compile ton code avec l'information de deboguage (-g3 pour gcc) gdb t'affiche la ligne qui pose probleme.
 
Le parachute SDL maintenant. C'est un mecanisme qui récupere les exceptions au lieu de les renvoyer a l'OS. Ce qui fait que si tu le laisses ce mecanisme actif, les exceptions ne remonteront pas jusqu'a gdb et donc tu ne pourras pas trouver la segfault aussi facilement que decrit ci-dessus.
 
 
Tu ne nous donne pas assez de code pour pouvoir déterminer ce qui y pose probleme. Deja, trouve le moment exact ou ca plante. Ensuite on remontera jusqu'a l'erreur, si besoin.

ok je vais essayer merci!
 
Le problème c'est que en enlevant le parachute et en recompilant, mon bug a lieu beaucoup moins souvent. Je n'y comprends vraiment rien... Il apparait vraiment sans raison apparente une fois de temps en temps...

je suppose qu'il vaut mieux enlever ces informations de deboguage pour la version finale du programme... Ca ralentit non?

Eh bien fais donc l'essai :-)
Et balance nous plus de code si tu veux qu'on t'aide.

Bon je vais continuer mes tests mais comme je suis pas là pendant les vacances, ça risque d'attendre début janvier.
C'est bien gentil de vouloir plus de code, mais je vous ai filé ce qui plante (d'après mes cout), sinon, la commande
cat -b *pp
m'indique que j'ai 3912 lignes de code... Alors je ne sais pas trop quoi vous donner.

 
oué enfin si tu fais :
cout "toto" ;
int i = 42;
cout "toto2";
et que ca segfault entre les 2 cout, tu ne peux absolument pas conclure que ca vient du "int i = 42". Un débuggeur t'indiquera ce qui merde vraiment

ah ouais?
ça a toujours marché pour moi. Mais c'est vrai qu'avant, quand je développais sous windows, j'avais toujours un debuggeur et c'est vraiment pratique. Je ne connaissait pas gdb, je n'avais que strace qui n'indique que les appels aux fonctions système. J'avoue que ça manque cruellement de recherche cette histoire de debugger!
J'ai plus qu'a bosser le man!

C'est bien ce que j'avais compris, mais je préfère poser la question quand même : il est ultra courant de voir de gens confondre && et & en C ou C++
 
 
+1 pour gdb.
 
Si tu as l'habitude d'utiliser emacs, il y a un mode gdb qui te permet de visualiser en parallèle le code exécuté et la fenêtre gdb. Pour ça, plutôt que de taper directement "gdb prog" en ligne de commande, tu ouvres un emacs et tu tapes "M-x gdb".

 
parfait

 
Exemple amusant :
 

 
Pourquoi ce code plante-t-il? C'est un exemple de code ou l'erreur n'est pas du tout au meme endroit que la ou ca plante... En gros ca va foirer pendant le deuxieme appel a Maximum, mais l'erreur n'est pas du tout la...puisque Maximum ne fait rien - ou presque.

C'est peut-être un exemple un peu subtil pour un débutant, non ?

Tu as raison, je me suis emballé. C'était pour montrer que ce n'est pas forcément la ligne ou ca plante qu'il faut corriger.