une commande qui change tout!

Salut a tous,

je suis actuellement sur un projet développé en C++ avec SDL et certains j'ai quelques soucis d'exécution... mon programme plante! toute fois j'ai remarqué au cours de mes test pour trouver l'erreur, qu'il suffisait de rajouter une ligne de code pour résoudre le problème:

Code:

system("PAUSE");

par exemple, une fonction qui charge un fichier mais qui fait tout planter:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 //on ouvre le fichier passé en parametre ifstream fichier(_adresse_fichier.c_str(), ios::in); //si le fichier est bien ouvert if(fichier!=NULL){ //on creer des variables temporaires int identifiant; string adresse_image; int nombre_collonne; int nombre_ligne; Sprite* p_sprite = NULL; //tant qu'on est pas a la fin du fichier while(!fichier.eof()){ //on lit le fichier fichier >> identifiant >> adresse_image >> nombre_collonne >> nombre_ligne; //création du sprite creer_sprite(); //on cherche le sprite p_sprite = avoir_p_sprite(-1); //modification du sprite p_sprite->charger_image(adresse_image.c_str(),nombre_collonne,nombre_ligne); //assignation de l'identifiant p_sprite->modifier_identifiant(identifiant); } //fermeture du fichier fichier.close(); }
et la meme mais avec la ptite commande 'magique' qui ne plante pas:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 //on ouvre le fichier passé en parametre ifstream fichier(_adresse_fichier.c_str(), ios::in); //si le fichier est bien ouvert if(fichier!=NULL){ //on creer des variables temporaires int identifiant; string adresse_image; int nombre_collonne; int nombre_ligne; Sprite* p_sprite = NULL; //tant qu'on est pas a la fin du fichier while(!fichier.eof()){ //on lit le fichier fichier >> identifiant >> adresse_image >> nombre_collonne >> nombre_ligne; //création du sprite creer_sprite(); //Copperfield en action! system("PAUSE"); //on cherche le sprite p_sprite = avoir_p_sprite(-1); //modification du sprite p_sprite->charger_image(adresse_image.c_str(),nombre_collonne,nombre_ligne); //assignation de l'identifiant p_sprite->modifier_identifiant(identifiant); } //fermeture du fichier fichier.close(); }
bref, tout ça c'est génial... a part que je ne sait toujours pas d'où vient le problème et que j'ai une jolie fenêtre de console qui me demande d'appuyer sur une touche pour continuer à chaque fois... bref je ne comprend pas comment cette simple commande peut tout changer comme ça (à signaler que je n'utilise pas de thread dans ce projet). d'autant plus qu'avant, toujours sur le même projet, j'avais trouver le moyen de résoudre un bug qui faisait planter le programme au début de l'exécution simplement (ou pas) en ajoutant un

Code:

printf("youhou...");

à la fin du code, juste avant le dernier return 0;

peut être est-ce juste une erreur de conception... mon programme est surement bourré de problème mais là je ne comprend pas. ou peu être est-ce un problème avec le compil? je suis sous CodeBlocks...

quelqu'un aurais t'il une idée du pourquoi du comment? je peut donner le code si quelqu'un a le courage de se plonger dedans pour comprendre...

C'est peut-être des erreurs d'accès mémoire à comportement indéfini (libérer deux fois un même pointeur, ...)

En tout cas compile ton projet en mode débug et utilise le débugger pour voir exactement où et suite à quels appels ça plante.

Dans ton projet avec les fichiers, deux choses ne vont pas:

Code:

if(fichier!=NULL)

Un fichier, contrairement au C, n'est PAS un POINTEUR.

Ca marche, mais tu devrais avoir un warning, et la bonne écriture est:

Code:

if(fichier)

Ensuite:

Code:

while(!fichier.eof())

Ca ne teste que si la fin du fichier a été atteinte et qu'on a essayé de lire plus loin, mais il peut y avoir d'autres problèmes (erreurs, etc) donc il vaut mieux faire:

Code:

while(fichier)

Ensuite:
Code:

1 2 3 4 //on lit le fichier fichier >> identifiant >> adresse_image >> nombre_collonne >> nombre_ligne; //création du sprite ....
Là tu auras de gros problèmes si la lecture a échoué (c'est peut-être là d'où vient ton plantage) car les variable auront des valeurs inchangées.

il vaut mieux toujours tester:
Code:

1 2 3 4 5 6 //on lit le fichier if (fichier >> identifiant >> adresse_image >> nombre_collonne >> nombre_ligne) { //création du sprite .... }
Si tu te demandes comment on peut faire des tests 'if (fichier)' alors que ce n'est ni un pointeur ni un booléen mais un objet, c'est parceque il y a un opérateur de conversion implicite d'un objet fstream en bool.

ok, merci coyotte!

c'est le premier projet dans lequel j'utilise le C++ pour lire un fichier avant j'utilisai encore le C mais j'ai voulu passer au C++ et j'ai donc repiquer le code de quelqu'un pour cette fonction, ce qui explique ces erreurs.

en effet le problème vient peut être de là, mais je e m'explique toujours pas pourquoi un simple printf ou une pause agit comme ça.

bref, je vai déjà corriger les erreurs que tu m'a cité, encore merci.

j'ai une autre fonction :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 void Conteneur_affichable::charger_fichier(string _adresse_fichier){ //on ouvre le fichier passé en parametre ifstream fichier(_adresse_fichier.c_str(), ios::in); //si le fichier est bien ouvert if(fichier){ //fermeture du fichier fichier.close(); } }
qui semble faire planter aussi (quand je la met en commentaire il n'y a plus d'erreur... pour le moment). elle n'est pas fini, ce n'est qu'un squelette pour l'instant mais je ne vois pas ou est le problème, peut tu m'aider?

Là je ne vois pas d'erreur...

Tu n'as pas besoin de "fichier.close", ça se fait automatiquement quand le destructeur est appelé.

En fait un printf peut changer l'état de la mémoire à un endroit, et si après tu crées un pointeur non initialisé il y a des chances pour qu'il prenne le même emplacement mémoire, et donc si tu fais par exemple un delete dessus tu auras un problème (alors que si par chance la mémoire vaut 0 à cet endroit, tu n'en auras pas). Ca explique des erreurs aléatoires.

Un autre cas de figure, encore avec un pointeur non initialisé: s'il vaut NULL par malchance et que tu le déréférence, tu auras une segfault, et si par chance il pointe vers une zone allouée au programme tu peux ne pas planter.