Discussion :

[ramzy05]

zuttttt, je ne saisie pas bien le code la , bon je vais envoyer le code pour mes structures de donnees:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#define filiere_char 10000
 
    typedef struct {
        char NOM[200];
        char PRENOM[200]; 
        int NCIN;
        int AGE;
    }Candidat;
    typedef struct {
        int NCIN;
        char SERIEBACC[5];
        float MOYENNE;
        float NOTEMATH;
        float NOTEPHY;
        }Bacc;
        typedef struct {
        int NCIN;
        char choix2[filiere_char];
        char choix3[filiere_char];
        }Choix;

[kaitlyn]

Ce n'est pas du code, c'est du pseudocode (conf. wikipedia), ça décrit des étapes et ça se lit comme du texte.
Par exemple, "ouvrir_fichiers()" ça veut dire ouvrir les fichiers, c'est-à-dire FILE* var_1= fopen(fichier_1, ...) avec fichier_1 qui représente le nom du fichier à ouvrir, var_1 le nom de la variable dans laquelle sera enregistré le retour de fopen(). etc.
"si erreur", ça veut dire qu'il faut verifier var_1, var_2... suivant le nombre de fichiers. etc.

[hurukan]

Perso moi j'afficherais les valeurs après le sscanf()... et avant le "write" sur le fichier où tout semble remis à zéro.
Vu qu'il n'y a aucune raison que les valeurs sauvegardées soient remises à zéro pendant l'écriture sur le fichier.

En gros j'afficherais ligne2 juste après le fgets, et puis juste après le sscanf.

[hurukan]

Je fais cela avec mes élèves, afin d'avancer étape par étape, on aura beau avoir un superbe pseudocode, une analyse de 54845 pages, certaines fonctions nous surprendront par rapport aux résultats attendus, et pas seulement en C...
C'est pour cela qu'il existe des codes d'erreur, des "try-catch blocs" et des mécanismes d'exceptions... parce qu'on est jamais certain du contenu des données que l'on manipule et du résultat de l'exécution d'une fonction... les imprévus en informatique ça existe.
C'est pour cela aussi que l'on teste les applications et que même après 10.000 heures de tests il y a des bugs qui se révèlent et qu'il faudra corriger, ou du moins, contourner.

Code :

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

1
2
3
#ifdef DEBUG
		printf("%-16s\n",ConvertToBin(ProduitPartiel));
#endif

Il y a aussi la possibilité de mettre en place un mécanisme de "journalisation" en écrivant dans un fichier au lieu d'afficher les données à l'écran (notamment pour les applications graphiques).

Une fois que tu auras une application qui propose des résultats encourageants, tu pourras soit retirer le #define DEBUG au début de ton programme, soit ne plus compiler avec l'option -DDEBUG.
Ou carrément, virer les "blocs" #ifdef #endif concernant DEBUG (moi je ne le fais pas je reviens sur des codes sources des années après et je suis bien content d'avoir conservé ces "balises").

[kaitlyn]

bon je vais envoyer le code pour mes structures de donnees:

Ce qu'il faut c'est un code complet minimal (exemple complet minimal), pas plus, pas moins.

exemple:

fichier_1

Code :

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

1
2
3
...
ici le contenu du fichier, quelques lignes suffisent.
...

Programme qui utilise le ou les fichiers:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include...
 
//declarations
 
//fonction qui pose problème
int fonction() 
{
    //....
}
 
int main()
{
    fonction();
}

Le code doit pouvoir être compilé et reproduire le problème.

[hurukan]

sous Linux la commande "tail -f <fichier à surveiller>" fait des miracles si on a rien en place pour la journalisation/log.
tu peux suivre pas par pas aussi à l'aide d'un debugger... ça aide à savoir exactement à partir de quel moment ton programme "part en sucette" ^^

Un debugger comme gdbgui (sous linux) est une pure merveille.
Sinon gdb seul est déjà très bien mais pour avoir une "vue globale" il faut déjà bien le maîtriser.