On 14 mar, 14:14, (Marc Espie) wrote:In article <C5E16B98.E4589%,
Eric Levenez wrote:>Quel serait ton conseil alors ?
Ignorer l'avertissement et envoyer gcc se faire cuire un oeuf.
Impossible dans un projet industriel. Les messages 'ignorés' sont bel
et bien présents dans la liste et peuvent empêcher de voir des
messages importants signalant de vrais problèmes...
On 14 mar, 14:14, es...@lain.home (Marc Espie) wrote:
In article <C5E16B98.E4589%use...@levenez.com>,
Eric Levenez <use...@levenez.com> wrote:
>Quel serait ton conseil alors ?
Ignorer l'avertissement et envoyer gcc se faire cuire un oeuf.
Impossible dans un projet industriel. Les messages 'ignorés' sont bel
et bien présents dans la liste et peuvent empêcher de voir des
messages importants signalant de vrais problèmes...
On 14 mar, 14:14, (Marc Espie) wrote:In article <C5E16B98.E4589%,
Eric Levenez wrote:>Quel serait ton conseil alors ?
Ignorer l'avertissement et envoyer gcc se faire cuire un oeuf.
Impossible dans un projet industriel. Les messages 'ignorés' sont bel
et bien présents dans la liste et peuvent empêcher de voir des
messages importants signalant de vrais problèmes...
Impossible dans un projet industriel. Les messages 'ignorés' sont bel
et bien présents dans la liste et peuvent empêcher de voir des
messages importants signalant de vrais problèmes...
Impossible dans un projet industriel. Les messages 'ignorés' sont bel
et bien présents dans la liste et peuvent empêcher de voir des
messages importants signalant de vrais problèmes...
Impossible dans un projet industriel. Les messages 'ignorés' sont bel
et bien présents dans la liste et peuvent empêcher de voir des
messages importants signalant de vrais problèmes...
-ed- a écrit :Impossible dans un projet industriel. Les messages 'ignorés' sont bel
et bien présents dans la liste et peuvent empêcher de voir des
messages importants signalant de vrais problèmes...
Je conseille de mon côté "dans un projet industriel" l'utilisation de
-Werror (ou ses équivalents): tout avertissement entraine l'échec de la
compilation.
-ed- a écrit :
Impossible dans un projet industriel. Les messages 'ignorés' sont bel
et bien présents dans la liste et peuvent empêcher de voir des
messages importants signalant de vrais problèmes...
Je conseille de mon côté "dans un projet industriel" l'utilisation de
-Werror (ou ses équivalents): tout avertissement entraine l'échec de la
compilation.
-ed- a écrit :Impossible dans un projet industriel. Les messages 'ignorés' sont bel
et bien présents dans la liste et peuvent empêcher de voir des
messages importants signalant de vrais problèmes...
Je conseille de mon côté "dans un projet industriel" l'utilisation de
-Werror (ou ses équivalents): tout avertissement entraine l'échec de la
compilation.
Tes fonctions sont trop longues, tu peux decouper plus.
Typiquement, ca se voit bien dans la fonction main(), ou tu
initialises 3 tonnes de variables qui ne te servent pas,
puis passe sur une boucle qui reinitialise les memes variables:
une bonne partie de la boucle devrait etre dans d'autres fonctions.
Il y a des commentaires inutiles, je pense en particulier a
/* Declaration des variables */
ou le tres inutile:
/* on retourne le choix du joueur */
return (choix_rejouer);
Regle d'or: un commentaire a une valeur ajoutee. Si tu paraphrases
ce que fait le code, sans explication supplementaire, un commentaire
ne sert a rien !
- c'est dommage de limiter les mots possibles a 10 caracteres, ca me
parait un peu arbitraire.
- attention a l'utilisation de fgets() avec un tampon... ca ne marche pas
du tout comme tu penses. le fgets(saisie, sizeof(saisie), stdin) va te
peter a la gueule, surtout avec un tableau de 4 caracteres.
(fgets lit une ligne complete, ou jusqu'a remplir le tableau... elle
ne lit PAS le reste de la ligne... donc si je tape:
34123131311
sur mon clavier, ben je vais me retrouver avec 341 dans mon tampon... et
13131311 en attente sur mon entree standard.
l'utilisation de fgets "propre" est compliquee... :(
- attention aux entrees-sorties sur lignes non completes. printf ne
fonctionne de maniere correcte et garantie QUE si tu affiches une
ligne complete, sinon il peut garder les choses en memoire.
Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
pour etre sur d'afficher avant une entree.
Ton programme marche peut-etre par accident (il y a pas mal de systemes
qui font aussi du C++, et donc qui "attachent" stdin et stdout ensemble),
mais il n'y a rien de garanti.
- dans les trucs anecdotiques,
#endif // PENDU_H_INCLUDED
peut poser des soucis. Il faut que tu aies un preprocesseur recent pour
que ca marche, les commentaires en // sont issus du C++. Ils sont reconnus
en C maintenant, mais parfois, le preprocesseur n'a pas suivi.
il y a quelques lourdeurs algorithmiques. Lorsque tu regardes le mot
en cours pour y trouver la lettre jouee... ben tu vois combien d'instances
tu en trouves: tu ne devrais pas avoir a compter les etoiles restantes,
parce que c'est quelque chose que tu peux garder en memoire.
Pareil pour le fichier de mots possibles, tu ne devrais pas avoir a le
relire totalement pour savoir combien il contient de mots.
- les parentheses de:
((etat_rejouer == REJOUER_MENU) || (etat_rejouer == REJOUER_NORMAL ))
sont inutiles.
J'ai vu moi-aussi ces avertissements, je ne suis pas sur que les corriger
soit une excellente chose. Ici, c'est tout betement lie a des:
if (indice_tableau < strlen(motSecret))
Le source devrait s'appeler pendu.c
int nb_coup_restant = 0;
int nb_coup_joue = 0;
int nb_coup_max = 0;
Vous allez dire que je suis vieux jeu, mais en français, le qualifiant
d'un compteur doit être au pluriel; donc on préférera nb_coups_resta nts,
etc.
Avec nb_coup_restant, il est possible d'hésiter entre un compteur et un
indice dont le premier terme serait impropre.
char lettre;
Un variable de type char est le plus souvent mal typée. En C, une
constante caractère (comme 'a') a pour type int, et ce devrait être le
cas pour les variables qui contiennent des choses similaires. Il y a de
très bonnes raisons (en particulier de pouvoir coder EOF, et de ne pas
perdre bêtement les caractères accentués pour des questions de signe )
pour cela, et le fait d'utiliser char n'a aucun intérêt pratique (cela
ne gagne rien).
/* Le jeu se deroule tant que le joueur veut rejouer */
do {
...
else if (choix_menu == 3) {
affichage(...);
return (0);
...
}
while((etat_rejouer == REJOUER_MENU) ...
return 0;
Cette boucle est beaucoup trop longue. De plus, la logique de sortie est
trop complexe, c'est en partie lié à l'existence de deux variables,
etat_rejouer et choix_menu. En fait, le return(0) est assez horrible,
c'est un saut déguisé, qui montre un problème de conception géné ral de
l'algorithme qui n'a pas été assez poussée.
/* Affichage du menu global : */
/* Ce menu permet de : */
/* 1 - lancer le jeu */
/* 2 - ajouter un nouveau mot mystere a la liste disponible */
/* 3 - quitter */
Ce commentaire devrait apparaître devant la fonction et dans le fichier
.h, pas là où elle appelée.
choix_menu = affichage(AFF_GENERAL, nb_coup_joue, ...
Autre utilisation très discutable : la fonction affichage renvoit une
valeur qui n'est jamais utilisée sauf cette fois-là ;
motJoue = malloc(strlen(motSecret));
En dehors de la valeur de l'argument (cf. ta première remarque), il faut
utiliser sizeof plutôt que strlen() ici, et calloc() plutôt que
malloc(); voire allouer motJoue en même temps et de la même manière que
motSecret,
while (motJoue[indice_tableau] != ' ') {
printf(" %c", motJoue[indice_tableau]);
indice_tableau++;
}
En C, cela s'écrit
printf(" %s", motJoue);
Permettre 4 caractères est une intéressante initiative
(en effet, des lettres comme ou Ç peuvent occuper plusieurs bytes;
mais on préferera MBLEN_MAX), mais elle est n'est pas exploitée par la
suite ; l'utilisation de sscanf est sujette à erreur, par exemple ici si
l'utilisateur tape un espace au début cela va être utilisé comme
proposition...
char saisie[4];
Il n'est pas logique, et potentiellement dangereux, d'utiliser des types
différents pour deux variables qui ont le même nom et à peu près l a même
utilisation.
case 1 : choix_niveau = 10;
NON. Il faut écrire
case 1 : choix_niveau = COUPS_FACILE;
printf( "nt Vous avez perdu. Le mot a trouver etait : %s",
On peut utiliser sans souci les accents dans les messages (sauf si on
s'appelle Marc E. et que l'on travaille sur des terminaux zarbi), c'est
quand même plus lisible.
/* On ajoute le nouveau mot */
fprintf(fichier, "%sn", saisie);
Cas typique où il est bon de vérifier la valeur renvoyée par fprintf ().
3ème exemple :
------------------------------------------------------------
Il vous reste 2 coups a jouer
Quel est le mot secret? * * E *
Proposez une lettre : U
Il vous reste 1 coup a jouer
Quel est le mot secret? * * E U
Proposez une lettre : b
Le caractere saisi n'est pas une lettre. Seuls
les lettres de l'alphabet sont autorisees.
------------------------------------------------------------
Commentaire : La lettre b minuscule m'a été refusée.
*) (détail) Fichier d'en-tête assez artificiel ici
*) (détail) return toto; au lieu de return (toto);
*) (peut poser pb) ligne_choisie = (rand() % (nb_mots_disponible - 1) );
*) (à vérifier) Tu es sûr que :
motJoue[indice_tableau] = ' ';
n'entraîne jamais un débordement ?
*) Je trouve ceci curieux :
if (fichier != NULL) {
/* le fichier est bien ouvert */
}
else {
printf( "nt Le fichier dico.txt n'a pu etre ouvert."
"nt Verifiez la presence ou l'intitule du fichier.");
exit(0);
}
Surtout l'accolade vide !! Et exit(0) équivaut à return 0 et c'est la marque
d'une terminaison correcte du programme ("status successful termination" d it la
Norme), or si on n'a pas pu ouvrir le fichier ... Idem plus haut dans ton code
avec le retour de malloc()
Je suis d'accord avec ce qui précède. Je rajouterai qu'il manque aussi
des commentaires. Il faudrait un commentaire en début de fichier pour
expliquer ce que fait le programme, qui l'a écrit, quand, etc. P.ex:
/*
* programme du Jeu de pendu
*
* auteur: Beware
* date: mars 2009
* version: 0.1
*/
Je suis aussi d'accord avec ça. Ainsi, beaucoup de boucle while()
pourraient être avantageusement remplacer par des boucles for(;;)
Tes fonctions sont trop longues, tu peux decouper plus.
Typiquement, ca se voit bien dans la fonction main(), ou tu
initialises 3 tonnes de variables qui ne te servent pas,
puis passe sur une boucle qui reinitialise les memes variables:
une bonne partie de la boucle devrait etre dans d'autres fonctions.
Il y a des commentaires inutiles, je pense en particulier a
/* Declaration des variables */
ou le tres inutile:
/* on retourne le choix du joueur */
return (choix_rejouer);
Regle d'or: un commentaire a une valeur ajoutee. Si tu paraphrases
ce que fait le code, sans explication supplementaire, un commentaire
ne sert a rien !
- c'est dommage de limiter les mots possibles a 10 caracteres, ca me
parait un peu arbitraire.
- attention a l'utilisation de fgets() avec un tampon... ca ne marche pas
du tout comme tu penses. le fgets(saisie, sizeof(saisie), stdin) va te
peter a la gueule, surtout avec un tableau de 4 caracteres.
(fgets lit une ligne complete, ou jusqu'a remplir le tableau... elle
ne lit PAS le reste de la ligne... donc si je tape:
34123131311
sur mon clavier, ben je vais me retrouver avec 341 dans mon tampon... et
13131311 en attente sur mon entree standard.
l'utilisation de fgets "propre" est compliquee... :(
- attention aux entrees-sorties sur lignes non completes. printf ne
fonctionne de maniere correcte et garantie QUE si tu affiches une
ligne complete, sinon il peut garder les choses en memoire.
Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
pour etre sur d'afficher avant une entree.
Ton programme marche peut-etre par accident (il y a pas mal de systemes
qui font aussi du C++, et donc qui "attachent" stdin et stdout ensemble),
mais il n'y a rien de garanti.
- dans les trucs anecdotiques,
#endif // PENDU_H_INCLUDED
peut poser des soucis. Il faut que tu aies un preprocesseur recent pour
que ca marche, les commentaires en // sont issus du C++. Ils sont reconnus
en C maintenant, mais parfois, le preprocesseur n'a pas suivi.
il y a quelques lourdeurs algorithmiques. Lorsque tu regardes le mot
en cours pour y trouver la lettre jouee... ben tu vois combien d'instances
tu en trouves: tu ne devrais pas avoir a compter les etoiles restantes,
parce que c'est quelque chose que tu peux garder en memoire.
Pareil pour le fichier de mots possibles, tu ne devrais pas avoir a le
relire totalement pour savoir combien il contient de mots.
- les parentheses de:
((etat_rejouer == REJOUER_MENU) || (etat_rejouer == REJOUER_NORMAL ))
sont inutiles.
J'ai vu moi-aussi ces avertissements, je ne suis pas sur que les corriger
soit une excellente chose. Ici, c'est tout betement lie a des:
if (indice_tableau < strlen(motSecret))
Le source devrait s'appeler pendu.c
int nb_coup_restant = 0;
int nb_coup_joue = 0;
int nb_coup_max = 0;
Vous allez dire que je suis vieux jeu, mais en français, le qualifiant
d'un compteur doit être au pluriel; donc on préférera nb_coups_resta nts,
etc.
Avec nb_coup_restant, il est possible d'hésiter entre un compteur et un
indice dont le premier terme serait impropre.
char lettre;
Un variable de type char est le plus souvent mal typée. En C, une
constante caractère (comme 'a') a pour type int, et ce devrait être le
cas pour les variables qui contiennent des choses similaires. Il y a de
très bonnes raisons (en particulier de pouvoir coder EOF, et de ne pas
perdre bêtement les caractères accentués pour des questions de signe )
pour cela, et le fait d'utiliser char n'a aucun intérêt pratique (cela
ne gagne rien).
/* Le jeu se deroule tant que le joueur veut rejouer */
do {
...
else if (choix_menu == 3) {
affichage(...);
return (0);
...
}
while((etat_rejouer == REJOUER_MENU) ...
return 0;
Cette boucle est beaucoup trop longue. De plus, la logique de sortie est
trop complexe, c'est en partie lié à l'existence de deux variables,
etat_rejouer et choix_menu. En fait, le return(0) est assez horrible,
c'est un saut déguisé, qui montre un problème de conception géné ral de
l'algorithme qui n'a pas été assez poussée.
/* Affichage du menu global : */
/* Ce menu permet de : */
/* 1 - lancer le jeu */
/* 2 - ajouter un nouveau mot mystere a la liste disponible */
/* 3 - quitter */
Ce commentaire devrait apparaître devant la fonction et dans le fichier
.h, pas là où elle appelée.
choix_menu = affichage(AFF_GENERAL, nb_coup_joue, ...
Autre utilisation très discutable : la fonction affichage renvoit une
valeur qui n'est jamais utilisée sauf cette fois-là ;
motJoue = malloc(strlen(motSecret));
En dehors de la valeur de l'argument (cf. ta première remarque), il faut
utiliser sizeof plutôt que strlen() ici, et calloc() plutôt que
malloc(); voire allouer motJoue en même temps et de la même manière que
motSecret,
while (motJoue[indice_tableau] != ' ') {
printf(" %c", motJoue[indice_tableau]);
indice_tableau++;
}
En C, cela s'écrit
printf(" %s", motJoue);
Permettre 4 caractères est une intéressante initiative
(en effet, des lettres comme ou Ç peuvent occuper plusieurs bytes;
mais on préferera MBLEN_MAX), mais elle est n'est pas exploitée par la
suite ; l'utilisation de sscanf est sujette à erreur, par exemple ici si
l'utilisateur tape un espace au début cela va être utilisé comme
proposition...
char saisie[4];
Il n'est pas logique, et potentiellement dangereux, d'utiliser des types
différents pour deux variables qui ont le même nom et à peu près l a même
utilisation.
case 1 : choix_niveau = 10;
NON. Il faut écrire
case 1 : choix_niveau = COUPS_FACILE;
printf( "nt Vous avez perdu. Le mot a trouver etait : %s",
On peut utiliser sans souci les accents dans les messages (sauf si on
s'appelle Marc E. et que l'on travaille sur des terminaux zarbi), c'est
quand même plus lisible.
/* On ajoute le nouveau mot */
fprintf(fichier, "%sn", saisie);
Cas typique où il est bon de vérifier la valeur renvoyée par fprintf ().
3ème exemple :
------------------------------------------------------------
Il vous reste 2 coups a jouer
Quel est le mot secret? * * E *
Proposez une lettre : U
Il vous reste 1 coup a jouer
Quel est le mot secret? * * E U
Proposez une lettre : b
Le caractere saisi n'est pas une lettre. Seuls
les lettres de l'alphabet sont autorisees.
------------------------------------------------------------
Commentaire : La lettre b minuscule m'a été refusée.
*) (détail) Fichier d'en-tête assez artificiel ici
*) (détail) return toto; au lieu de return (toto);
*) (peut poser pb) ligne_choisie = (rand() % (nb_mots_disponible - 1) );
*) (à vérifier) Tu es sûr que :
motJoue[indice_tableau] = ' ';
n'entraîne jamais un débordement ?
*) Je trouve ceci curieux :
if (fichier != NULL) {
/* le fichier est bien ouvert */
}
else {
printf( "nt Le fichier dico.txt n'a pu etre ouvert."
"nt Verifiez la presence ou l'intitule du fichier.");
exit(0);
}
Surtout l'accolade vide !! Et exit(0) équivaut à return 0 et c'est la marque
d'une terminaison correcte du programme ("status successful termination" d it la
Norme), or si on n'a pas pu ouvrir le fichier ... Idem plus haut dans ton code
avec le retour de malloc()
Je suis d'accord avec ce qui précède. Je rajouterai qu'il manque aussi
des commentaires. Il faudrait un commentaire en début de fichier pour
expliquer ce que fait le programme, qui l'a écrit, quand, etc. P.ex:
/*
* programme du Jeu de pendu
*
* auteur: Beware
* date: mars 2009
* version: 0.1
*/
Je suis aussi d'accord avec ça. Ainsi, beaucoup de boucle while()
pourraient être avantageusement remplacer par des boucles for(;;)
Tes fonctions sont trop longues, tu peux decouper plus.
Typiquement, ca se voit bien dans la fonction main(), ou tu
initialises 3 tonnes de variables qui ne te servent pas,
puis passe sur une boucle qui reinitialise les memes variables:
une bonne partie de la boucle devrait etre dans d'autres fonctions.
Il y a des commentaires inutiles, je pense en particulier a
/* Declaration des variables */
ou le tres inutile:
/* on retourne le choix du joueur */
return (choix_rejouer);
Regle d'or: un commentaire a une valeur ajoutee. Si tu paraphrases
ce que fait le code, sans explication supplementaire, un commentaire
ne sert a rien !
- c'est dommage de limiter les mots possibles a 10 caracteres, ca me
parait un peu arbitraire.
- attention a l'utilisation de fgets() avec un tampon... ca ne marche pas
du tout comme tu penses. le fgets(saisie, sizeof(saisie), stdin) va te
peter a la gueule, surtout avec un tableau de 4 caracteres.
(fgets lit une ligne complete, ou jusqu'a remplir le tableau... elle
ne lit PAS le reste de la ligne... donc si je tape:
34123131311
sur mon clavier, ben je vais me retrouver avec 341 dans mon tampon... et
13131311 en attente sur mon entree standard.
l'utilisation de fgets "propre" est compliquee... :(
- attention aux entrees-sorties sur lignes non completes. printf ne
fonctionne de maniere correcte et garantie QUE si tu affiches une
ligne complete, sinon il peut garder les choses en memoire.
Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
pour etre sur d'afficher avant une entree.
Ton programme marche peut-etre par accident (il y a pas mal de systemes
qui font aussi du C++, et donc qui "attachent" stdin et stdout ensemble),
mais il n'y a rien de garanti.
- dans les trucs anecdotiques,
#endif // PENDU_H_INCLUDED
peut poser des soucis. Il faut que tu aies un preprocesseur recent pour
que ca marche, les commentaires en // sont issus du C++. Ils sont reconnus
en C maintenant, mais parfois, le preprocesseur n'a pas suivi.
il y a quelques lourdeurs algorithmiques. Lorsque tu regardes le mot
en cours pour y trouver la lettre jouee... ben tu vois combien d'instances
tu en trouves: tu ne devrais pas avoir a compter les etoiles restantes,
parce que c'est quelque chose que tu peux garder en memoire.
Pareil pour le fichier de mots possibles, tu ne devrais pas avoir a le
relire totalement pour savoir combien il contient de mots.
- les parentheses de:
((etat_rejouer == REJOUER_MENU) || (etat_rejouer == REJOUER_NORMAL ))
sont inutiles.
J'ai vu moi-aussi ces avertissements, je ne suis pas sur que les corriger
soit une excellente chose. Ici, c'est tout betement lie a des:
if (indice_tableau < strlen(motSecret))
Le source devrait s'appeler pendu.c
int nb_coup_restant = 0;
int nb_coup_joue = 0;
int nb_coup_max = 0;
Vous allez dire que je suis vieux jeu, mais en français, le qualifiant
d'un compteur doit être au pluriel; donc on préférera nb_coups_resta nts,
etc.
Avec nb_coup_restant, il est possible d'hésiter entre un compteur et un
indice dont le premier terme serait impropre.
char lettre;
Un variable de type char est le plus souvent mal typée. En C, une
constante caractère (comme 'a') a pour type int, et ce devrait être le
cas pour les variables qui contiennent des choses similaires. Il y a de
très bonnes raisons (en particulier de pouvoir coder EOF, et de ne pas
perdre bêtement les caractères accentués pour des questions de signe )
pour cela, et le fait d'utiliser char n'a aucun intérêt pratique (cela
ne gagne rien).
/* Le jeu se deroule tant que le joueur veut rejouer */
do {
...
else if (choix_menu == 3) {
affichage(...);
return (0);
...
}
while((etat_rejouer == REJOUER_MENU) ...
return 0;
Cette boucle est beaucoup trop longue. De plus, la logique de sortie est
trop complexe, c'est en partie lié à l'existence de deux variables,
etat_rejouer et choix_menu. En fait, le return(0) est assez horrible,
c'est un saut déguisé, qui montre un problème de conception géné ral de
l'algorithme qui n'a pas été assez poussée.
/* Affichage du menu global : */
/* Ce menu permet de : */
/* 1 - lancer le jeu */
/* 2 - ajouter un nouveau mot mystere a la liste disponible */
/* 3 - quitter */
Ce commentaire devrait apparaître devant la fonction et dans le fichier
.h, pas là où elle appelée.
choix_menu = affichage(AFF_GENERAL, nb_coup_joue, ...
Autre utilisation très discutable : la fonction affichage renvoit une
valeur qui n'est jamais utilisée sauf cette fois-là ;
motJoue = malloc(strlen(motSecret));
En dehors de la valeur de l'argument (cf. ta première remarque), il faut
utiliser sizeof plutôt que strlen() ici, et calloc() plutôt que
malloc(); voire allouer motJoue en même temps et de la même manière que
motSecret,
while (motJoue[indice_tableau] != ' ') {
printf(" %c", motJoue[indice_tableau]);
indice_tableau++;
}
En C, cela s'écrit
printf(" %s", motJoue);
Permettre 4 caractères est une intéressante initiative
(en effet, des lettres comme ou Ç peuvent occuper plusieurs bytes;
mais on préferera MBLEN_MAX), mais elle est n'est pas exploitée par la
suite ; l'utilisation de sscanf est sujette à erreur, par exemple ici si
l'utilisateur tape un espace au début cela va être utilisé comme
proposition...
char saisie[4];
Il n'est pas logique, et potentiellement dangereux, d'utiliser des types
différents pour deux variables qui ont le même nom et à peu près l a même
utilisation.
case 1 : choix_niveau = 10;
NON. Il faut écrire
case 1 : choix_niveau = COUPS_FACILE;
printf( "nt Vous avez perdu. Le mot a trouver etait : %s",
On peut utiliser sans souci les accents dans les messages (sauf si on
s'appelle Marc E. et que l'on travaille sur des terminaux zarbi), c'est
quand même plus lisible.
/* On ajoute le nouveau mot */
fprintf(fichier, "%sn", saisie);
Cas typique où il est bon de vérifier la valeur renvoyée par fprintf ().
3ème exemple :
------------------------------------------------------------
Il vous reste 2 coups a jouer
Quel est le mot secret? * * E *
Proposez une lettre : U
Il vous reste 1 coup a jouer
Quel est le mot secret? * * E U
Proposez une lettre : b
Le caractere saisi n'est pas une lettre. Seuls
les lettres de l'alphabet sont autorisees.
------------------------------------------------------------
Commentaire : La lettre b minuscule m'a été refusée.
*) (détail) Fichier d'en-tête assez artificiel ici
*) (détail) return toto; au lieu de return (toto);
*) (peut poser pb) ligne_choisie = (rand() % (nb_mots_disponible - 1) );
*) (à vérifier) Tu es sûr que :
motJoue[indice_tableau] = ' ';
n'entraîne jamais un débordement ?
*) Je trouve ceci curieux :
if (fichier != NULL) {
/* le fichier est bien ouvert */
}
else {
printf( "nt Le fichier dico.txt n'a pu etre ouvert."
"nt Verifiez la presence ou l'intitule du fichier.");
exit(0);
}
Surtout l'accolade vide !! Et exit(0) équivaut à return 0 et c'est la marque
d'une terminaison correcte du programme ("status successful termination" d it la
Norme), or si on n'a pas pu ouvrir le fichier ... Idem plus haut dans ton code
avec le retour de malloc()
Je suis d'accord avec ce qui précède. Je rajouterai qu'il manque aussi
des commentaires. Il faudrait un commentaire en début de fichier pour
expliquer ce que fait le programme, qui l'a écrit, quand, etc. P.ex:
/*
* programme du Jeu de pendu
*
* auteur: Beware
* date: mars 2009
* version: 0.1
*/
Je suis aussi d'accord avec ça. Ainsi, beaucoup de boucle while()
pourraient être avantageusement remplacer par des boucles for(;;)
- attention aux entrees-sorties sur lignes non completes. printf ne
fonctionne de maniere correcte et garantie QUE si tu affiches une
ligne complete, sinon il peut garder les choses en memoire.
Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
pour etre sur d'afficher avant une entree.
Ton programme marche peut-etre par accident (il y a pas mal de systemes
qui font aussi du C++, et donc qui "attachent" stdin et stdout ensemble),
mais il n'y a rien de garanti.
Sur cette remarque la, j'aurais besoin d'explication parce que je vois
pas
exactement ce que tu veut dire.
- les parentheses de:
((etat_rejouer == REJOUER_MENU) || (etat_rejouer == REJOUER_NORMAL))
sont inutiles.
Tu as raison, c'est peut etre bete, mais je vois mieux les conditions
comme ca.
Je suis d'accord avec ce qui précède. Je rajouterai qu'il manque aussi
des commentaires. Il faudrait un commentaire en début de fichier pour
expliquer ce que fait le programme, qui l'a écrit, quand, etc. P.ex:
/*
* programme du Jeu de pendu
*
* auteur: Beware
* date: mars 2009
* version: 0.1
*/
Corrigé, merci.
- attention aux entrees-sorties sur lignes non completes. printf ne
fonctionne de maniere correcte et garantie QUE si tu affiches une
ligne complete, sinon il peut garder les choses en memoire.
Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
pour etre sur d'afficher avant une entree.
Ton programme marche peut-etre par accident (il y a pas mal de systemes
qui font aussi du C++, et donc qui "attachent" stdin et stdout ensemble),
mais il n'y a rien de garanti.
Sur cette remarque la, j'aurais besoin d'explication parce que je vois
pas
exactement ce que tu veut dire.
- les parentheses de:
((etat_rejouer == REJOUER_MENU) || (etat_rejouer == REJOUER_NORMAL))
sont inutiles.
Tu as raison, c'est peut etre bete, mais je vois mieux les conditions
comme ca.
Je suis d'accord avec ce qui précède. Je rajouterai qu'il manque aussi
des commentaires. Il faudrait un commentaire en début de fichier pour
expliquer ce que fait le programme, qui l'a écrit, quand, etc. P.ex:
/*
* programme du Jeu de pendu
*
* auteur: Beware
* date: mars 2009
* version: 0.1
*/
Corrigé, merci.
- attention aux entrees-sorties sur lignes non completes. printf ne
fonctionne de maniere correcte et garantie QUE si tu affiches une
ligne complete, sinon il peut garder les choses en memoire.
Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
pour etre sur d'afficher avant une entree.
Ton programme marche peut-etre par accident (il y a pas mal de systemes
qui font aussi du C++, et donc qui "attachent" stdin et stdout ensemble),
mais il n'y a rien de garanti.
Sur cette remarque la, j'aurais besoin d'explication parce que je vois
pas
exactement ce que tu veut dire.
- les parentheses de:
((etat_rejouer == REJOUER_MENU) || (etat_rejouer == REJOUER_NORMAL))
sont inutiles.
Tu as raison, c'est peut etre bete, mais je vois mieux les conditions
comme ca.
Je suis d'accord avec ce qui précède. Je rajouterai qu'il manque aussi
des commentaires. Il faudrait un commentaire en début de fichier pour
expliquer ce que fait le programme, qui l'a écrit, quand, etc. P.ex:
/*
* programme du Jeu de pendu
*
* auteur: Beware
* date: mars 2009
* version: 0.1
*/
Corrigé, merci.
In article .com>,
Beware wrote:
>>- attention aux entrees-sorties sur lignes non completes. printf ne
>>fonctionne de maniere correcte et garantie QUE si tu affiches une
>>ligne complete, sinon il peut garder les choses en memoire.
>>Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
>>pour etre sur d'afficher avant une entree.
>>Ton programme marche peut-etre par accident (il y a pas mal de systemes
>>qui font aussi du C++, et donc qui "attachent" stdin et stdout ensemble ),
>>mais il n'y a rien de garanti.
>Sur cette remarque la, j'aurais besoin d'explication parce que je vois
>pas
>exactement ce que tu veut dire.
Ma faute, trop de details pas assez de contexte.
Un
printf("Entrez votre valeur: ");
ne va pas forcement afficher quoi que ce soit.
Sur une grosse partie des systemes, les entrees-sorties sont bufferisees pour
eviter d'avoir trop d'appel-systemes, et peuvent se faire "en differe".
La strategie standard pour stdout, c'est de n'afficher reellement quelque
chose qu'en presence d'un retour a la ligne.
Si tu veux afficher des lignes incompletes, il faut rajouter un appel a
fflush:
printf("Entrez votre valeur: ");
fflush(stdout);
>>- les parentheses de:
>>((etat_rejouer == REJOUER_MENU) || (etat_rejouer == REJOUER_NOR MAL))
>>sont inutiles.
>Tu as raison, c'est peut etre bete, mais je vois mieux les conditions
>comme ca.
Manque d'habitude. En tout cas le resultat est peu idiomatique. Il faut
t'habituer a l'idee qu'on ecrit souvent du code de facon standard, et que
tout programmeur C normalement constitue saura le lire sans les parenthes es
supplementaires !
>>Je suis d'accord avec ce qui précède. Je rajouterai qu'il manque au ssi
>>des commentaires. Il faudrait un commentaire en début de fichier pour
>>expliquer ce que fait le programme, qui l'a écrit, quand, etc. P.ex:
>>/*
>> * programme du Jeu de pendu
>> *
>> * auteur: Beware
>> * date: mars 2009
>> * version: 0.1
>> */
>Corrigé, merci.
En fait, ca serait encore mieux si tu mettais ton vrai nom, et que tu
mettais une vraie licence d'utilisation sur ton code. Il faudra a un
moment ou un autre te renseigner sur le droit d'auteur et son applicabili te
au code (le vrai nom n'est pas indispensable, c'est juste utile pour evit er
toute contestation).
Pas de remarque sur le nouveau code, j'essaierai d'y jeter un oeil biento t.
Il y a des choses bien, mais c'est encore largement perfectible. ;-)
In article <021dbeee-39d7-4596-8ffb-c0011b7f6...@w35g2000yqm.googlegroups .com>,
Beware <mathieu.hed...@gmail.com> wrote:
>>- attention aux entrees-sorties sur lignes non completes. printf ne
>>fonctionne de maniere correcte et garantie QUE si tu affiches une
>>ligne complete, sinon il peut garder les choses en memoire.
>>Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
>>pour etre sur d'afficher avant une entree.
>>Ton programme marche peut-etre par accident (il y a pas mal de systemes
>>qui font aussi du C++, et donc qui "attachent" stdin et stdout ensemble ),
>>mais il n'y a rien de garanti.
>Sur cette remarque la, j'aurais besoin d'explication parce que je vois
>pas
>exactement ce que tu veut dire.
Ma faute, trop de details pas assez de contexte.
Un
printf("Entrez votre valeur: ");
ne va pas forcement afficher quoi que ce soit.
Sur une grosse partie des systemes, les entrees-sorties sont bufferisees pour
eviter d'avoir trop d'appel-systemes, et peuvent se faire "en differe".
La strategie standard pour stdout, c'est de n'afficher reellement quelque
chose qu'en presence d'un retour a la ligne.
Si tu veux afficher des lignes incompletes, il faut rajouter un appel a
fflush:
printf("Entrez votre valeur: ");
fflush(stdout);
>>- les parentheses de:
>>((etat_rejouer == REJOUER_MENU) || (etat_rejouer == REJOUER_NOR MAL))
>>sont inutiles.
>Tu as raison, c'est peut etre bete, mais je vois mieux les conditions
>comme ca.
Manque d'habitude. En tout cas le resultat est peu idiomatique. Il faut
t'habituer a l'idee qu'on ecrit souvent du code de facon standard, et que
tout programmeur C normalement constitue saura le lire sans les parenthes es
supplementaires !
>>Je suis d'accord avec ce qui précède. Je rajouterai qu'il manque au ssi
>>des commentaires. Il faudrait un commentaire en début de fichier pour
>>expliquer ce que fait le programme, qui l'a écrit, quand, etc. P.ex:
>>/*
>> * programme du Jeu de pendu
>> *
>> * auteur: Beware
>> * date: mars 2009
>> * version: 0.1
>> */
>Corrigé, merci.
En fait, ca serait encore mieux si tu mettais ton vrai nom, et que tu
mettais une vraie licence d'utilisation sur ton code. Il faudra a un
moment ou un autre te renseigner sur le droit d'auteur et son applicabili te
au code (le vrai nom n'est pas indispensable, c'est juste utile pour evit er
toute contestation).
Pas de remarque sur le nouveau code, j'essaierai d'y jeter un oeil biento t.
Il y a des choses bien, mais c'est encore largement perfectible. ;-)
In article .com>,
Beware wrote:
>>- attention aux entrees-sorties sur lignes non completes. printf ne
>>fonctionne de maniere correcte et garantie QUE si tu affiches une
>>ligne complete, sinon il peut garder les choses en memoire.
>>Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
>>pour etre sur d'afficher avant une entree.
>>Ton programme marche peut-etre par accident (il y a pas mal de systemes
>>qui font aussi du C++, et donc qui "attachent" stdin et stdout ensemble ),
>>mais il n'y a rien de garanti.
>Sur cette remarque la, j'aurais besoin d'explication parce que je vois
>pas
>exactement ce que tu veut dire.
Ma faute, trop de details pas assez de contexte.
Un
printf("Entrez votre valeur: ");
ne va pas forcement afficher quoi que ce soit.
Sur une grosse partie des systemes, les entrees-sorties sont bufferisees pour
eviter d'avoir trop d'appel-systemes, et peuvent se faire "en differe".
La strategie standard pour stdout, c'est de n'afficher reellement quelque
chose qu'en presence d'un retour a la ligne.
Si tu veux afficher des lignes incompletes, il faut rajouter un appel a
fflush:
printf("Entrez votre valeur: ");
fflush(stdout);
>>- les parentheses de:
>>((etat_rejouer == REJOUER_MENU) || (etat_rejouer == REJOUER_NOR MAL))
>>sont inutiles.
>Tu as raison, c'est peut etre bete, mais je vois mieux les conditions
>comme ca.
Manque d'habitude. En tout cas le resultat est peu idiomatique. Il faut
t'habituer a l'idee qu'on ecrit souvent du code de facon standard, et que
tout programmeur C normalement constitue saura le lire sans les parenthes es
supplementaires !
>>Je suis d'accord avec ce qui précède. Je rajouterai qu'il manque au ssi
>>des commentaires. Il faudrait un commentaire en début de fichier pour
>>expliquer ce que fait le programme, qui l'a écrit, quand, etc. P.ex:
>>/*
>> * programme du Jeu de pendu
>> *
>> * auteur: Beware
>> * date: mars 2009
>> * version: 0.1
>> */
>Corrigé, merci.
En fait, ca serait encore mieux si tu mettais ton vrai nom, et que tu
mettais une vraie licence d'utilisation sur ton code. Il faudra a un
moment ou un autre te renseigner sur le droit d'auteur et son applicabili te
au code (le vrai nom n'est pas indispensable, c'est juste utile pour evit er
toute contestation).
Pas de remarque sur le nouveau code, j'essaierai d'y jeter un oeil biento t.
Il y a des choses bien, mais c'est encore largement perfectible. ;-)
On 15 mar, 17:35, (Marc Espie) wrote:In article
,
Beware wrote:
>>- attention aux entrees-sorties sur lignes non completes. printf ne
>>fonctionne de maniere correcte et garantie QUE si tu affiches une
>>ligne complete, sinon il peut garder les choses en memoire.
>>Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
>>pour etre sur d'afficher avant une entree.
>>Ton programme marche peut-etre par accident (il y a pas mal de systemes
>>qui font aussi du C++, et donc qui "attachent" stdin et stdout ensemble),
>>mais il n'y a rien de garanti.
>Sur cette remarque la, j'aurais besoin d'explication parce que je vois
>pas
>exactement ce que tu veut dire.
Ma faute, trop de details pas assez de contexte.
Un
printf("Entrez votre valeur: ");
ne va pas forcement afficher quoi que ce soit.
Sur une grosse partie des systemes, les entrees-sorties sont bufferisees pour
eviter d'avoir trop d'appel-systemes, et peuvent se faire "en differe".
La strategie standard pour stdout, c'est de n'afficher reellement quelque
chose qu'en presence d'un retour a la ligne.
Si tu veux afficher des lignes incompletes, il faut rajouter un appel a
fflush:
printf("Entrez votre valeur: ");
fflush(stdout);
Donc, si je comprends bien. Je peut continuer a utiliser printf() si
il y a un 'n' dans la chaine (enfin ce qu'il y a entre "") ? C'est
bien ca?
Et si c'est exact faut-il que l'emplacement 'n' soit en fin de chaine
ou pas?
On 15 mar, 17:35, es...@lain.home (Marc Espie) wrote:
In article
<021dbeee-39d7-4596-8ffb-c0011b7f6...@w35g2000yqm.googlegroups.com>,
Beware <mathieu.hed...@gmail.com> wrote:
>>- attention aux entrees-sorties sur lignes non completes. printf ne
>>fonctionne de maniere correcte et garantie QUE si tu affiches une
>>ligne complete, sinon il peut garder les choses en memoire.
>>Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
>>pour etre sur d'afficher avant une entree.
>>Ton programme marche peut-etre par accident (il y a pas mal de systemes
>>qui font aussi du C++, et donc qui "attachent" stdin et stdout ensemble),
>>mais il n'y a rien de garanti.
>Sur cette remarque la, j'aurais besoin d'explication parce que je vois
>pas
>exactement ce que tu veut dire.
Ma faute, trop de details pas assez de contexte.
Un
printf("Entrez votre valeur: ");
ne va pas forcement afficher quoi que ce soit.
Sur une grosse partie des systemes, les entrees-sorties sont bufferisees pour
eviter d'avoir trop d'appel-systemes, et peuvent se faire "en differe".
La strategie standard pour stdout, c'est de n'afficher reellement quelque
chose qu'en presence d'un retour a la ligne.
Si tu veux afficher des lignes incompletes, il faut rajouter un appel a
fflush:
printf("Entrez votre valeur: ");
fflush(stdout);
Donc, si je comprends bien. Je peut continuer a utiliser printf() si
il y a un 'n' dans la chaine (enfin ce qu'il y a entre "") ? C'est
bien ca?
Et si c'est exact faut-il que l'emplacement 'n' soit en fin de chaine
ou pas?
On 15 mar, 17:35, (Marc Espie) wrote:In article
,
Beware wrote:
>>- attention aux entrees-sorties sur lignes non completes. printf ne
>>fonctionne de maniere correcte et garantie QUE si tu affiches une
>>ligne complete, sinon il peut garder les choses en memoire.
>>Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
>>pour etre sur d'afficher avant une entree.
>>Ton programme marche peut-etre par accident (il y a pas mal de systemes
>>qui font aussi du C++, et donc qui "attachent" stdin et stdout ensemble),
>>mais il n'y a rien de garanti.
>Sur cette remarque la, j'aurais besoin d'explication parce que je vois
>pas
>exactement ce que tu veut dire.
Ma faute, trop de details pas assez de contexte.
Un
printf("Entrez votre valeur: ");
ne va pas forcement afficher quoi que ce soit.
Sur une grosse partie des systemes, les entrees-sorties sont bufferisees pour
eviter d'avoir trop d'appel-systemes, et peuvent se faire "en differe".
La strategie standard pour stdout, c'est de n'afficher reellement quelque
chose qu'en presence d'un retour a la ligne.
Si tu veux afficher des lignes incompletes, il faut rajouter un appel a
fflush:
printf("Entrez votre valeur: ");
fflush(stdout);
Donc, si je comprends bien. Je peut continuer a utiliser printf() si
il y a un 'n' dans la chaine (enfin ce qu'il y a entre "") ? C'est
bien ca?
Et si c'est exact faut-il que l'emplacement 'n' soit en fin de chaine
ou pas?
In article com>,
Beware wrote:
>On 15 mar, 17:35, (Marc Espie) wrote:
>> In article
>,
>> Beware wrote:
>> >>- attention aux entrees-sorties sur lignes non completes. printf ne
>> >>fonctionne de maniere correcte et garantie QUE si tu affiches une
>> >>ligne complete, sinon il peut garder les choses en memoire.
>> >>Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
>> >>pour etre sur d'afficher avant une entree.
>> >>Ton programme marche peut-etre par accident (il y a pas mal de syste mes
>> >>qui font aussi du C++, et donc qui "attachent" stdin et stdout ensem ble),
>> >>mais il n'y a rien de garanti.
>> >Sur cette remarque la, j'aurais besoin d'explication parce que je voi s
>> >pas
>> >exactement ce que tu veut dire.
>> Ma faute, trop de details pas assez de contexte.
>> Un
>> printf("Entrez votre valeur: ");
>> ne va pas forcement afficher quoi que ce soit.
>> Sur une grosse partie des systemes, les entrees-sorties sont bufferise es pour
>> eviter d'avoir trop d'appel-systemes, et peuvent se faire "en differe" .
>> La strategie standard pour stdout, c'est de n'afficher reellement quel que
>> chose qu'en presence d'un retour a la ligne.
>> Si tu veux afficher des lignes incompletes, il faut rajouter un appel a
>> fflush:
>> printf("Entrez votre valeur: ");
>> fflush(stdout);
>Donc, si je comprends bien. Je peut continuer a utiliser printf() si
>il y a un 'n' dans la chaine (enfin ce qu'il y a entre "") ? C'est
>bien ca?
>Et si c'est exact faut-il que l'emplacement 'n' soit en fin de chaine
>ou pas?
Si tu rajoutes un fflush() apres chaque printf() qui n'affiche pas une
ligne complete, ca sera bon.
(fflush est standard, cette utilisation est licite, et ca marche).
(et avant que tu demandes, pour un ensemble de raisons complexes, il n'y
a pas d'equivalent pour stdin...)
In article <0cd81272-3e01-47c3-a68d-a9dfe8423...@t7g2000yqa.googlegroups. com>,
Beware <mathieu.hed...@gmail.com> wrote:
>On 15 mar, 17:35, es...@lain.home (Marc Espie) wrote:
>> In article
><021dbeee-39d7-4596-8ffb-c0011b7f6...@w35g2000yqm.googlegroups.com>,
>> Beware <mathieu.hed...@gmail.com> wrote:
>> >>- attention aux entrees-sorties sur lignes non completes. printf ne
>> >>fonctionne de maniere correcte et garantie QUE si tu affiches une
>> >>ligne complete, sinon il peut garder les choses en memoire.
>> >>Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
>> >>pour etre sur d'afficher avant une entree.
>> >>Ton programme marche peut-etre par accident (il y a pas mal de syste mes
>> >>qui font aussi du C++, et donc qui "attachent" stdin et stdout ensem ble),
>> >>mais il n'y a rien de garanti.
>> >Sur cette remarque la, j'aurais besoin d'explication parce que je voi s
>> >pas
>> >exactement ce que tu veut dire.
>> Ma faute, trop de details pas assez de contexte.
>> Un
>> printf("Entrez votre valeur: ");
>> ne va pas forcement afficher quoi que ce soit.
>> Sur une grosse partie des systemes, les entrees-sorties sont bufferise es pour
>> eviter d'avoir trop d'appel-systemes, et peuvent se faire "en differe" .
>> La strategie standard pour stdout, c'est de n'afficher reellement quel que
>> chose qu'en presence d'un retour a la ligne.
>> Si tu veux afficher des lignes incompletes, il faut rajouter un appel a
>> fflush:
>> printf("Entrez votre valeur: ");
>> fflush(stdout);
>Donc, si je comprends bien. Je peut continuer a utiliser printf() si
>il y a un 'n' dans la chaine (enfin ce qu'il y a entre "") ? C'est
>bien ca?
>Et si c'est exact faut-il que l'emplacement 'n' soit en fin de chaine
>ou pas?
Si tu rajoutes un fflush() apres chaque printf() qui n'affiche pas une
ligne complete, ca sera bon.
(fflush est standard, cette utilisation est licite, et ca marche).
(et avant que tu demandes, pour un ensemble de raisons complexes, il n'y
a pas d'equivalent pour stdin...)
In article com>,
Beware wrote:
>On 15 mar, 17:35, (Marc Espie) wrote:
>> In article
>,
>> Beware wrote:
>> >>- attention aux entrees-sorties sur lignes non completes. printf ne
>> >>fonctionne de maniere correcte et garantie QUE si tu affiches une
>> >>ligne complete, sinon il peut garder les choses en memoire.
>> >>Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
>> >>pour etre sur d'afficher avant une entree.
>> >>Ton programme marche peut-etre par accident (il y a pas mal de syste mes
>> >>qui font aussi du C++, et donc qui "attachent" stdin et stdout ensem ble),
>> >>mais il n'y a rien de garanti.
>> >Sur cette remarque la, j'aurais besoin d'explication parce que je voi s
>> >pas
>> >exactement ce que tu veut dire.
>> Ma faute, trop de details pas assez de contexte.
>> Un
>> printf("Entrez votre valeur: ");
>> ne va pas forcement afficher quoi que ce soit.
>> Sur une grosse partie des systemes, les entrees-sorties sont bufferise es pour
>> eviter d'avoir trop d'appel-systemes, et peuvent se faire "en differe" .
>> La strategie standard pour stdout, c'est de n'afficher reellement quel que
>> chose qu'en presence d'un retour a la ligne.
>> Si tu veux afficher des lignes incompletes, il faut rajouter un appel a
>> fflush:
>> printf("Entrez votre valeur: ");
>> fflush(stdout);
>Donc, si je comprends bien. Je peut continuer a utiliser printf() si
>il y a un 'n' dans la chaine (enfin ce qu'il y a entre "") ? C'est
>bien ca?
>Et si c'est exact faut-il que l'emplacement 'n' soit en fin de chaine
>ou pas?
Si tu rajoutes un fflush() apres chaque printf() qui n'affiche pas une
ligne complete, ca sera bon.
(fflush est standard, cette utilisation est licite, et ca marche).
(et avant que tu demandes, pour un ensemble de raisons complexes, il n'y
a pas d'equivalent pour stdin...)
Est-ce qu'une macro qui me permette de remplacer ces deux lignes est
une chose "orthodoxe" ou pas? Du genre :
#define PRINT(chaine) printf("%s", chaine);
fflush(stdout);
et ensuite utiliser PRINT quand j'en ai besoin.
La question peut vous paraitre bete, mais comme je n'ai jamais utilisé
les macros je me demande.
Est-ce qu'une macro qui me permette de remplacer ces deux lignes est
une chose "orthodoxe" ou pas? Du genre :
#define PRINT(chaine) printf("%s", chaine);
fflush(stdout);
et ensuite utiliser PRINT quand j'en ai besoin.
La question peut vous paraitre bete, mais comme je n'ai jamais utilisé
les macros je me demande.
Est-ce qu'une macro qui me permette de remplacer ces deux lignes est
une chose "orthodoxe" ou pas? Du genre :
#define PRINT(chaine) printf("%s", chaine);
fflush(stdout);
et ensuite utiliser PRINT quand j'en ai besoin.
La question peut vous paraitre bete, mais comme je n'ai jamais utilisé
les macros je me demande.
In article ,
Beware wrote:- attention aux entrees-sorties sur lignes non completes. printf ne
fonctionne de maniere correcte et garantie QUE si tu affiches une
ligne complete, sinon il peut garder les choses en memoire.
Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
pour etre sur d'afficher avant une entree.
Ton programme marche peut-etre par accident (il y a pas mal de systemes
qui font aussi du C++, et donc qui "attachent" stdin et stdout ensemble),
mais il n'y a rien de garanti.
Sur cette remarque la, j'aurais besoin d'explication parce que je vois
pas
exactement ce que tu veut dire.
Ma faute, trop de details pas assez de contexte.
Un
printf("Entrez votre valeur: ");
ne va pas forcement afficher quoi que ce soit.
Sur une grosse partie des systemes, les entrees-sorties sont bufferisees pour
eviter d'avoir trop d'appel-systemes, et peuvent se faire "en differe".
La strategie standard pour stdout, c'est de n'afficher reellement quelque
chose qu'en presence d'un retour a la ligne.
Si tu veux afficher des lignes incompletes, il faut rajouter un appel a
fflush:
printf("Entrez votre valeur: ");
fflush(stdout);
In article <021dbeee-39d7-4596-8ffb-c0011b7f6235@w35g2000yqm.googlegroups.com>,
Beware <mathieu.hedard@gmail.com> wrote:
- attention aux entrees-sorties sur lignes non completes. printf ne
fonctionne de maniere correcte et garantie QUE si tu affiches une
ligne complete, sinon il peut garder les choses en memoire.
Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
pour etre sur d'afficher avant une entree.
Ton programme marche peut-etre par accident (il y a pas mal de systemes
qui font aussi du C++, et donc qui "attachent" stdin et stdout ensemble),
mais il n'y a rien de garanti.
Sur cette remarque la, j'aurais besoin d'explication parce que je vois
pas
exactement ce que tu veut dire.
Ma faute, trop de details pas assez de contexte.
Un
printf("Entrez votre valeur: ");
ne va pas forcement afficher quoi que ce soit.
Sur une grosse partie des systemes, les entrees-sorties sont bufferisees pour
eviter d'avoir trop d'appel-systemes, et peuvent se faire "en differe".
La strategie standard pour stdout, c'est de n'afficher reellement quelque
chose qu'en presence d'un retour a la ligne.
Si tu veux afficher des lignes incompletes, il faut rajouter un appel a
fflush:
printf("Entrez votre valeur: ");
fflush(stdout);
In article ,
Beware wrote:- attention aux entrees-sorties sur lignes non completes. printf ne
fonctionne de maniere correcte et garantie QUE si tu affiches une
ligne complete, sinon il peut garder les choses en memoire.
Il faut utiliser setbuf pour changer le mode de tampon, ou fflush
pour etre sur d'afficher avant une entree.
Ton programme marche peut-etre par accident (il y a pas mal de systemes
qui font aussi du C++, et donc qui "attachent" stdin et stdout ensemble),
mais il n'y a rien de garanti.
Sur cette remarque la, j'aurais besoin d'explication parce que je vois
pas
exactement ce que tu veut dire.
Ma faute, trop de details pas assez de contexte.
Un
printf("Entrez votre valeur: ");
ne va pas forcement afficher quoi que ce soit.
Sur une grosse partie des systemes, les entrees-sorties sont bufferisees pour
eviter d'avoir trop d'appel-systemes, et peuvent se faire "en differe".
La strategie standard pour stdout, c'est de n'afficher reellement quelque
chose qu'en presence d'un retour a la ligne.
Si tu veux afficher des lignes incompletes, il faut rajouter un appel a
fflush:
printf("Entrez votre valeur: ");
fflush(stdout);