demande Aide sur un exercice!

demande Aide sur un exercice! - C - Programmation

Marsh Posté le 30-09-2004 à 16:47:05    

Edité suite aux remarques!
alors!
voici l'exercice:
 
ecrire un programme qui demande à l'utilisateur de taper 3 entiers.
qui ensuite,lui pose les questions suivantes:
          1)sont-ils dans l'ordre croissant?
          2)sont-ils tous impairs?
          3)Y a t-il exactement un impair?
          4)sont-ils tous egaux?
          5)sont-ils distincts 2 a 2?(:??: )
          6)l'un des trois est-il plus grand que la somme des autres?
La reponse à chacune de ces questions doit etre un des deux caractères 'y' ou 'n'.
Apres chaque réponse de l'utilisateur,afficher "bonne réponse" ou "Mauvaise réponse".
A la fin,afficher le nombre de bonnes réponses.
 
Mon prog:

Code :
  1. #include<stdio.h>
  2. int main(void)
  4. {
  6. int x,y,z;
  7. int crois,impair_1,impair_2,egaux,plusgrand;
  8. /* declare les variables:*/
  10. char r1='y',r2='y',r3='y',r4='y',r5='y';
  13. printf("entrez le premier entier\n" );
  14. scanf("%i",&x);
  15.         /*lire entier n°1*/
  17.         printf("entrez le second entier\n" );
  18. scanf("%i",&y);
  19.         /*lire entier n°2*/
  21.         printf("entrez le troisieme entier\n" );
  22. scanf("%i",&z);
  23.         /*lire entier n°2*/
  25. printf("sont-ils dans l'ordre croissant?\n" );
  26. scanf("%c",&r1);
  27. /*repondre par 'y' ou 'n'*/
  30.         crois=((x<y)&&(y<z));
  31.        
  32. if (crois==(r1=='y'))
  33. {
  34.                   printf("bonne reponse\n" );
  35. }
  36. else
  37. {
  38.                   printf("mauvaise reponse\n" );
  39. }
  41. printf("sont-ils tous impairs?\n" );
  42. scanf("%c",&r2);
  43. scanf("%c",&r2);
  45. impair_1=((x%2==1)&&(y%2==1)&&(z%2==1));
  47. if (impair_1==(r2=='y'))
  48. {
  49.         printf("bonne reponse\n" );
  50. }
  51. else 
  52. {     
  53.         printf("mauvaise reponse\n" );
  54. }
  56. printf("y a-t-il exactement un impair?\n" );
  57. scanf("%c",&r3);
  58. scanf("%c",&r3);
  60. impair_2=((x%2==1)||(y%2==1)||(z%2==1));
  62. if (impair_2==(r3=='y'))
  63. {
  64.         printf("bonne reponse\n" );
  65. }
  66. else
  67. {
  68.         printf("mauvaise reponse\n" );
  69. }
  70. printf("sont-ils tous egaux?\n" );
  71. scanf("%c",&r4);
  72. scanf("%c",&r4);
  74. egaux=((x==y)&&(y==z)&&(x==z));
  75. if (egaux==(r4=='y'))
  76. {
  77.         printf("bonne reponse\n" );
  78. }
  79. else
  80. {
  81.         printf("mauvaise reponse\n" );
  82. }
  84. printf("l'un des trois est-il plus grand que la somme des autres?\n" );
  85. scanf("%c",&r5);
  86. scanf("%c",&r5);
  88. plusgrand=((x+y<z)||(x+z<y)||(y+z<x));
  89. if (plusgrand==(r5=='y'))
  90. {
  91.         printf("bonne reponse\n" );
  92. }
  93. else
  94. {
  95.         printf("mauvaise reponse\n" );
  96. }
  98. }


 
 
 
a la fin le programme doit m'afficher le nombre de bonne reponse!
comment faire? :??: !


Message édité par turkoglu le 30-09-2004 à 23:18:55
Reply

Marsh Posté le 30-09-2004 à 16:47:05   

Reply

Marsh Posté le 30-09-2004 à 16:54:04    

cpt++

Reply

Marsh Posté le 30-09-2004 à 19:03:16    

Turkoglu a écrit :

mon programme:
#include<stdio.h>
int main(void)
 
{
int x,y,z,i,crois,total,impair_1,impair_2,egaux,plusgrand;
char r1='y',r2='y',r3='y',r4='y',r5='y';
 
 
 printf("entrez le premier entier\n" );
 scanf("%i",&x);
 
 printf("entrez le second entier\n" );
 scanf("%i",&y);
 
 printf("entrez le troisieme entier\n" );
 scanf("%i",&z);
 
 printf("sont-ils dans l'ordre croissant?\n" );
 scanf("%c",&r1);
 
 crois=((x<y)&&(y<z));
  if (crois==(r1=='y')) {printf("bonne reponse\n" );
 }
 else  
 { printf("mauvaise reponse\n" );}
 
 printf("sont-ils tous impairs?\n" );
 scanf("%c",&r2);
 scanf("%c",&r2);
 
 impair_1=((x%2==1)&&(y%2==1)&&(z%2==1));
 
 if (impair_1==(r2=='y')) {printf("bonne reponse\n" );}
 else  {printf("mauvaise reponse\n" );}
 
 printf("y a-t-il exactement un impair?\n" );
 scanf("%c",&r3);
 scanf("%c",&r3);
 
 impair_2=((x%2==1)||(y%2==1)||(z%2==1));
 if (impair_2==(r3=='y')) {printf("bonne reponse\n" );}
 else {printf("mauvaise reponse\n" );}
 printf("sont-ils tous egaux?\n" );
 scanf("%c",&r4);
 scanf("%c",&r4);
 
 egaux=((x==y)&&(y==z)&&(x==z));
 if (egaux==(r4=='y')) {printf("bonne reponse\n" );}
 else {printf("mauvaise reponse\n" );}
 
 printf("l'un des trois est-il plus grand que la somme des autres?\n" );
 scanf("%c",&r5);
 scanf("%c",&r5);
 
 plusgrand=((x+y<z)||(x+y<z)||(y+z<x));
 if (plusgrand==(r5=='y')) {printf("bonne reponse\n" );}
 else {printf("mauvaise reponse\n" );}    
   
 }
a la fin le programme doit m'afficher le nombre de bonne reponse!
comment faire? :??: !


 
Ce source prouve bien qu'on peut écrire du C assez illisible, voire immonde.
J'ai remarqué 2 erreurs
1) la question "y a-t-il exactement un impair" signifie "y a t-il un et un seul impair". Or le test "impair_2=((x%2==1)||(y%2==1)||(z%2==1));" renvoie vrai s'il y a au-moins un impair, c'est à dire qu'il valide le fait qu'il y ait 2 ou 3 impairs. Soit le test est mal fait, soit la question réelle est "y a-t-il au-moins un impair"
 
2)  
plusgrand=((x+y<z)||(x+y<z)||(y+z<x));
Tu testes 2 fois "(x+y<z)". Il me semble que le second test doit être "(x+z<y)"


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 30-09-2004 à 21:23:28    

Commente ton prog stp
 
edit: édente également


Message édité par jijiz le 30-09-2004 à 21:23:54
Reply

Marsh Posté le 30-09-2004 à 22:05:50    

indente [:aloy]
 
et utilise les balises cpp

Reply

Marsh Posté le 30-09-2004 à 22:47:21    

ok!

Reply

Marsh Posté le 01-10-2004 à 08:09:43    

Je suis étonné que Taz le Foudroyant n'ait pas déjà sévi :-)
 
 
if (egaux==(r4=='y'))  
Ce n'est pas propre. "egaux" vaut une valeur vraie ou fausse et le test renvoie une valeur vraie ou fausse. Mais les deux valeurs, mêmes si elles sont vraies, ne sont pas forcément égales.
Il vaut mieux écrire "if (egaux && (r4=='y'))"
Idem pour les autres tests


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 02-10-2004 à 04:32:23    

Si, si les deux valeurs sont vrais alors elles sont égales. Vrai c'est 1 et faux c'est 0, pas autre chose. Mais du point de vue du style c'est vrai que c'est discutable.

Reply

Marsh Posté le 02-10-2004 à 09:22:09    

matafan a écrit :

Si, si les deux valeurs sont vrais alors elles sont égales. Vrai c'est 1 et faux c'est 0, pas autre chose. Mais du point de vue du style c'est vrai que c'est discutable.


Il me semblait avoir lu qu'en C ANSI, une valeur "vraie" est une valeur différente de 0...
 
Je pense que l'exercice gagnerait à être amélioré. par exemple, les 3 nombres pourraient être stockés dans un tableau. Ensuite, je verrais bien une fonction qui compte et renvoie combien il y a d'impair. Comme cela, on pourrait savoir d'un coup s'il n'y a qu'un nombre impair ou si tous les nombres sont impairs.
Ensuite, à voir...


Message édité par Sve@r le 02-10-2004 à 09:25:19

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 03-10-2004 à 16:06:57    

mon code final.
s'il y a des erreures faites moi signes...

Code :
  1. #include<stdio.h>
  2. int main(void)
  4. {
  6. int x,y,z,crois,impair_1,impair_2,egaux,total,plusgrand,distincts;
  7. /* declare les variables qui ont pour valeurs un entier*/
  9. char r1,r2,r3,r4,r5,r6;
  10. /* declare les variables qui ont pour valeurs un caractère*/
  11.    
  12.    
  13.    
  14.       printf("Entrez le premier entier:\n" );
  15.        scanf("%i",&x);
  16.            /*lire entier n°1*/
  17.    
  18.        
  19.          printf("Entrez le second entier:\n" );
  20.        scanf("%i",&y);
  21.             /*lire entier n°2*/
  22.    
  23.        
  24.          printf("Entrez le troisieme entier:\n" );
  25.        scanf("%i",&z);
  26.            /*lire entier n°2*/
  28.    
  29.       printf("Sont-ils dans l'ordre croissant?\n" );
  30.        scanf("%c",&r1);
  31.         /*repondre par un caractere 'y' ou 'n'*/
  33.    
  35. crois=((x<y)&&(y<z));
  36.        
  37. if (crois==(r1=='y')) 
  38. {
  39.    printf("Bonne reponse.\n" );
  40.    r1=1;
  41.    /*donne la valeur 1 si la reponse est juste cela permet de comptabiliser le nombre de bonne reponse a la fin*/
  42. }
  44. else 
  45. { 
  46.                   printf("Mauvaise reponse.\n" );
  47. r1=0;
  48. /*donne la valeur 0 si la reponse est fausse*/
  49. }
  51. total=r1;
  52. /*memorise la reponse,la reponse a pour valeur 1 ou 0 */     
  53.    
  54.    
  55.       printf("Sont-ils tous impairs?\n" );
  56.        scanf("%c",&r2);
  57.        scanf("%c",&r2);
  58.    
  60. impair_1=((x%2==1)&&(y%2==1)&&(z%2==1));
  61.    
  62. if (impair_1==(r2=='y')) 
  63. {
  64.    printf("Bonne reponse.\n" );
  65.    r2=1;
  66. }
  67. else 
  68. {     
  69.    printf("Mauvaise reponse.\n" );
  70.    r2=0;
  71. }
  73. total=(total+r2);
  74.    
  75.       printf("Y a-t-il exactement un impair?\n" );
  76.        scanf("%c",&r3);
  77.        scanf("%c",&r3);
  78.    
  79. impair_2=(((x%2==1)&&!(y%2==1)&&!(z%2==1))||(!(x%2==1)&&(y%2==1)&&!(z%2==1))||(!(x%2==1)&&!(y%2==1)&&(z%2==1)));
  80.    
  81. if (impair_2==(r3=='y')) 
  82. {
  83.    printf("Bonne reponse.\n" );
  84.    r3=1;
  85. }
  86. else 
  87. {
  88.    printf("Mauvaise reponse.\n" );
  89.    r3=0;
  90. }
  92. total=(total+r3);
  94.       printf("Sont-ils tous egaux?\n" );
  95.        scanf("%c",&r4);
  96.        scanf("%c",&r4);
  97.    
  98. egaux=((x==y)&&(y==z)&&(x==z));
  100. if (egaux==(r4=='y')) 
  101. {
  102.    printf("Bonne reponse.\n",r4=1);
  103.    r4=1;
  104. }
  105. else 
  106. {
  107.    printf("Mauvaise reponse.\n",r4=0);
  108.    r4=0;
  109. }
  111. total=(total+r4); 
  113.  printf("Sont-ils distincts 2 a 2?\n" );
  114.        scanf("%c",&r5);
  115.        scanf("%c",&r5);
  117. distincts=(x!=y)&&(x!=z)&&(y!=z);
  119. if (distincts==(r5=='y')) 
  120. {
  122.    printf("Bonne reponse.\n" );
  123.    r5=1;
  124. }
  125. else 
  126. {
  127.    printf("Mauvaise reponse.\n" );
  128.    r5=0;
  129. }
  132. total=(total+r5);   
  133.  
  134.       printf("L'un des trois est-il plus grand que la somme des autres?\n" );
  135.        scanf("%c",&r6);
  136.        scanf("%c",&r6);
  137.    
  139. plusgrand=((x+y<z)||(x+z<y)||(y+z<x));
  141. if (plusgrand==(r6=='y')) 
  142. {
  144.    printf("Bonne reponse.\n",r6=1);
  145.    r6=1;
  146. }
  148. else 
  149. {
  150.    printf("Mauvaise reponse.\n",r6=0);
  151.    r6=0;
  152. }
  154. total=(total+r6);
  155.  printf("Nombre de bonnes reponses:%i.\n",total);
  156.  /*affiche le nombre de bonnes reponses de l'utilisateur*/
  157. return(0);
  158.      
  159. }
  160. /*
  161. deux exemples de l'exécution:le premier est un exemple avec que des bonnes reponses et le second comporte des erreures.
  163. -----------TEST n°1-----------
  164. Entrez le premier entier:
  165. 5
  166. Entrez le second entier:
  167. 16
  168. Entrez le troisieme entier:
  169. 24
  170. Sont-ils dans l'ordre croissant?
  171. y
  172. Bonne reponse.
  173. Sont-ils tous impairs?
  174. n
  175. Bonne reponse.
  176. Y a-t-il exactement un impair?
  177. y
  178. Bonne reponse.
  179. Sont-ils tous egaux?
  180. n
  181. Bonne reponse.
  182. Sont-ils distincts 2 a 2?
  183. y
  184. Bonne reponse.
  185. L'un des trois est-il plus grand que la somme des autres?
  186. y
  187. Bonne reponse.
  188. Nombre de bonnes reponses:6.
  191. -----------TEST n°2-----------
  192. Entrez le premier entier:
  193. 15
  194. Entrez le second entier:
  195. 7
  196. Entrez le troisieme entier:
  197. 34
  198. Sont-ils dans l'ordre croissant?
  199. y
  200. Mauvaise reponse.
  201. Sont-ils tous impairs?
  202. n
  203. Bonne reponse.
  204. Y a-t-il exactement un impair?
  205. y
  206. Mauvaise reponse.
  207. Sont-ils tous egaux?
  208. n
  209. Bonne reponse.
  210. Sont-ils distincts 2 a 2?
  211. y
  212. Bonne reponse.
  213. L'un des trois est-il plus grand que la somme des autres?
  214. n
  215. Mauvaise reponse.
  216. Nombre de bonnes reponses:3.
  217. */


Reply

Marsh Posté le 03-10-2004 à 16:06:57   

Reply

Marsh Posté le 03-10-2004 à 19:41:06    

Ton programme fonctionne mais il est quand même optimisable
Tous tes r1, r2, r3 etc ne servent pas à grand chose. Il te suffit d'insérer l'instruction "total++" à chaque fois que tu affiches "bonne réponse" et tu auras au final le nb total de bonnes réponses.
Ensuite, tu pourrais écrire une fonction spéciale qui permette de faire saisir "y" ou "n" et qui vérifierait que la saisie soit bien "y" ou "n". Cela pourrait être de ce style :

Code :
  1. char saisie(char *prompt)
  2. {
  3.    char rep;
  5.    /* Boucle de saisie */
  6.    do {
  7.       /* Affichage du prompt*/
  8.       printf("%s ?\n", prompt" );
  10.       /* Saisie de la réponse */
  11.       scanf("%c", &rep);
  12.       getchar();
  13.    } while (rep != 'y' && rep != 'n');
  14.    /* Boucle tant que réponse différente de "y" ou "n" */
  16.    /* Renvoi de la réponse */
  17.    return(rep);
  18. }


 
Ensuite, toutes tes saisies se feraient de cette façon :

Code :
  1. ...
  2. r1=saisie("Les nombres sont-ils tous égaux" );
  3. ...
  4. r2=saisie("Y a-t-il un nombre impair" );
  5. ...
  6. r3=saisie("blablabla" );
  7. etc


 
Ensuite, ton test qui vérifie qu'il n'y a qu'un seul nombre impair fonctionne mais il est assez lourd, surtout que tu vérifies une fois qu'ils sont tous impairs et une seconde fois qu'il n'y a qu'un seul impair. Tu pourrais compter au début combien il y a d'impair et utiliser ce compteur quand il faut pour savoir s'il y a 1 seul ou 3 impairs
 
Par ailleurs, l'instruction "if (machin == (rep == 'y'))" n'est absolument pas "propre". Peut-être que ton programme fonctionnesur ta machine parce que "machin" vaut "1" quand il est vrai et que "rep == 'y'" vaut aussi "1" quand c'est vrai mais il se peut que ton programme ne fonctionne pas sur une autre machine où "vrai" peut valoir n'importe quelle valeur diférente de "0". Sur cet ordi là, tu peux avoir "machin" qui vaut "1" et "rep == 'y'" qui vaut "y". Et ton "if" sera faux alors qu'il devait être vrai.
Il vaut mieux écrire "if (machin && (rep == 'y'))"
 
Enfin l'utilisation d'un tableau de 3 nombres rendrait ce programme évolutif. Il serait assez facile de le modifier pour travailler sur 4, 5 ou 10 nombres.
 
Mis à part toutes ces remarques, ton exercice est réussi. Le programme que tu as écrit répond à ce qu'il lui est demandé.
A+


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 03-10-2004 à 19:49:02    

Sve@r a écrit :

Par ailleurs, l'instruction "if (machin == (rep == 'y'))" n'est absolument pas "propre". Peut-être que ton programme fonctionnesur ta machine parce que "machin" vaut "1" quand il est vrai et que "rep == 'y'" vaut aussi "1" quand c'est vrai mais il se peut que ton programme ne fonctionne pas sur une autre machine où "vrai" peut valoir n'importe quelle valeur diférente de "0". Sur cet ordi là, tu peux avoir "machin" qui vaut "1" et "rep == 'y'" qui vaut "y". Et ton "if" sera faux alors qu'il devait être vrai.
Il vaut mieux écrire "if (machin && (rep == 'y'))"


Pas équivalent
 
Parce que si machin est faux et qu'il répond non, ca donne false && false -> false
hors il faut que ca donne true (car la réponse est effectivement la bonne)
 
Faut faire un XOR et en prendre l'inverse, donc
if !(machin^(rep=='y'))


Message édité par masklinn le 03-10-2004 à 19:55:02

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 03-10-2004 à 19:59:43    

Masklinn a écrit :

Pas équivalent
 
Parce que si machin est faux et qu'il répond non, ca donne false && false -> false
hors il faut que ca donne true (car la réponse est effectivement la bonne)


Exact, j'y avais pas pensé
Bien vu Masklinn
 
J'ai pensé à un truc encore plus fou, qui serait assez bien pour les cinglés du C: ce serait que dans cet exercice les questions soient elles-aussi évolutives. Aujourd'hui on vérifie qu'ils sont tous impairs et tous différents, mais demain on vérifie qu'il n'y a que 2 impairs et tous décroissant, etc.
Pour ça, je verrais bien une structure contenant la question, un pointeur sur la fonction qui vérifie que les nombres répondent au critère et la valeur que cette fonction doit renvoyer pour que la réponse soit correcte.
Ensuite, le programmeur définit un tableau de structures de ce type et le programme déroule le tableau. Il pose la qustion, attend la réponse et va vérifier avec la fonction correspondante que la réponse est correcte. Puis il passe à la question suivante etc...


Message édité par Sve@r le 03-10-2004 à 20:09:35

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 04-10-2004 à 18:27:49    

Sve@r a écrit :

J'ai pensé à un truc encore plus fou, qui serait assez bien pour les cinglés du C: ce serait que dans cet exercice les questions soient elles-aussi évolutives. Aujourd'hui on vérifie qu'ils sont tous impairs et tous différents, mais demain on vérifie qu'il n'y a que 2 impairs et tous décroissant, etc.
Pour ça, je verrais bien une structure contenant la question, un pointeur sur la fonction qui vérifie que les nombres répondent au critère et la valeur que cette fonction doit renvoyer pour que la réponse soit correcte.
Ensuite, le programmeur définit un tableau de structures de ce type et le programme déroule le tableau. Il pose la qustion, attend la réponse et va vérifier avec la fonction correspondante que la réponse est correcte. Puis il passe à la question suivante etc...


 
Bon ben je l'ai fait. Voici le code source du truc:

Code :
  1. #include <stdio.h>
  2. #define NB   (3)   /* Nombre d'éléments */
  4. /* Structure qui gère la question et la vérification de la réponse */
  5. typedef struct {
  6. char *prompt;     /* Prompt à afficher */
  7. int (*verif)(int*);    /* Fonction de vérification */
  8. int result;     /* Résultat à avoir */
  9. } t_question;      /* Type de cette structure */
  11. /* Prototype des fonctions utilisées */
  12. int croissance(int*);     /* Vérifie la croissance */
  13. int impair(int*);     /* Compte combien il y a d'impair */
  14. int egalite(int*);     /* Vérifie tous égaux */
  15. int different(int*);     /* Vérifie tous différents */
  16. int un_et_somme(int*);     /* Vérifie un plus grand que la somme */
  18. main()
  19. {
  20. int tabNB[NB];     /* Tableau des nombres */
  21. char rep;     /* Réponse o/n */
  22. int nb_ok;     /* Nb bonnes réponses */
  23. int nb_rep;     /* Nb réponses */
  24. int i;      /* Indice de boucle */
  25. static t_question tabQuestion[]={   /* Tableau des questions */
  26.  {"Les nombres sont-ils croissants", croissance, 1},
  27.  {"Les nombres sont-ils tous impairs", impair, NB},
  28.  {"Y a-t-il un seul impair", impair, 1},
  29.  {"Les nombres sont-ils tous pairs", impair, 0},
  30.  {"Y a-t-il un seul pair", impair, NB - 1},
  31.  {"Les nombres sont-ils tous égaux", egalite, 1},
  32.  {"Les nombres sont-ils tous différents", different, 1},
  33.  {"L'un des nombres est-il plus grand que la somme des autres", un_et_somme, 1},
  34.  {NULL, NULL}
  35. };
  36. t_question *ptQuestion;    /* Ptr balayage des questions */
  38. /* On fait saisir les nombres */
  39. for (i=0; i < NB; i++)
  40. {
  41.  printf("Entrez le nombre %d :", i + 1);
  42.  fflush(stdout);
  43.  scanf("%d", &tabNB[i]);
  44.  getchar();
  45. }
  47. /* Balayage des questions */
  48. nb_ok=0;
  49. for (ptQuestion=tabQuestion, nb_rep=0; ptQuestion->prompt != NULL; ptQuestion++, nb_rep++)
  50. {
  51.  do {
  52.   /* On pose la question */
  53.   printf("%s (o/n) ? ", ptQuestion->prompt);
  54.   fflush(stdout);
  56.   /* On attend la réponse */
  57.   scanf("%c", &rep);
  58.   getchar();
  60.  /* Tant que réponse différente O/N */
  61.  } while (rep != 'o' && rep != 'n');
  63.  /* On évalue les nombres par rapport à la question */
  64.  i=(ptQuestion->verif)(tabNB);
  66.  /* On vérifie que la réponse correspond au résultat */
  67.  if ((rep == 'o' && i == ptQuestion->result) || (rep == 'n' && i != ptQuestion->result))
  68.  {
  69.   printf("Bonne réponse\n" );
  70.   nb_ok++;
  71.  }
  72.  else
  73.   printf("Mauvaise réponse\n" );
  74. }
  76. /* Affichage final */
  77. printf("Vous avez donné %d bonnes réponses sur %d\n", nb_ok, nb_rep);
  78. }
  80. /* Fonction qui vérifie la croissance */
  81. int croissance(int *tabNB)
  82. {
  83. int i;      /* Indice de boucle */
  85. /* On balaye les nombres */
  86. for (i=1; i < NB; i++)
  87. {
  88.  /* On regarde si la croissance s'interromp */
  89.  if (tabNB[i] <= tabNB[i - 1])
  90.   /* La croissance n'est plus respectée */
  91.   return(0);
  92. }
  94. /* Tous croissants */
  95. return(1);
  96. }
  98. /* Fonction qui compte le nombre d'impairs */
  99. int impair(int *tabNB)
  100. {
  101. int i;      /* Indice de boucle */
  102. int cpt;     /* Compteur des impairs */
  104. /* On balaye les nombres */
  105. cpt=0;
  106. for (i=0; i < NB; i++)
  107. {
  108.  if ((tabNB[i] % 2) == 1)
  109.   /* Le nombre est impair */
  110.   cpt++;
  111. }
  113. /* On renvoie le résultat */
  114. return(cpt);
  115. }
  117. /* Fonction qui vérifie qu'ils sont tous égaux */
  118. int egalite(int *tabNB)
  119. {
  120. int i;      /* Indice de boucle */
  122. /* On balaye les nombres */
  123. for (i=1; i < NB; i++)
  124. {
  125.  /* On regarde si le nombre est différent du premier */
  126.  if (tabNB[i] != tabNB[0])
  127.   /* L'égalité n'est plus respectée */
  128.   return(0);
  129. }
  131. /* Tous égaux */
  132. return(1);
  133. }
  135. /* Fonction qui vérifie qu'ils sont tous différents */
  136. int different(int *tabNB)
  137. {
  138. int i;      /* Indice de boucle */
  139. int j;      /* Indice de boucle */
  141. /* On balaye les nombres */
  142. for (i=1; i < NB; i++)
  143. {
  144.  /* On balaye les nombres situés avant celui en cours */
  145.  for (j=0; j < i; j++)
  146.  {
  147.   /* On regarde si le nombre est égal à un des nombres précédents */
  148.   if (tabNB[i] == tabNB[j])
  149.    /* L'inégalité n'est plus respectée */
  150.    return(0);
  151.  }
  152. }
  154. /* Tous inégaux */
  155. return(1);
  156. }
  158. /* Fonction qui vérifie si l'un est plus grand que la somme des autres */
  159. int un_et_somme(int *tabNB)
  160. {
  161. int i;      /* Indice de boucle */
  162. int j;      /* Indice de boucle */
  163. int somme;     /* Somme des autres */
  165. /* On balaye les nombres */
  166. for (i=0; i < NB; i++)
  167. {
  168.  somme=0;
  170.  /* On balaye les autres nombres pour les additionner */
  171.  for (j=0; j < NB; j++)
  172.  {
  173.   /* Si on est sur le même nombre */
  174.   if (i == j)
  175.    /* On le saute */
  176.    continue;
  178.   /* On additionne le nombre */
  179.   somme+=tabNB[j];
  180.  }
  182.  /* On compare le nombre en cours et la somme des autres */
  183.  if (tabNB[i] > somme)
  184.   /* On a trouvé */
  185.   return(1);
  186. }
  188. /* Aucun des nombres n'est plus grand que la somme des autres */
  189. return(0);
  190. }


 
Et voilà - Si on veut rajouter une question, il suffit de:
- écrire la fonction qui la vérifie
- rajouter la question, le nom de la fonction et le résultat attendu dans le tabQuestion
- prototyper la fonction avant le main
- et recompiler
 
Si on a envie de s'amuser sur 4, 5 ou 100 nombres, il suffit de modifier la valeur du "#define NB  (3)" et recompiler


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 04-10-2004 à 18:38:10    

- return c'est pas une fonction pour ce qui en douteraient
- ça manque cruellement de const
- int main()
- ton NB c'est pas flexible du tout
- utilise size_t pour parcourir un tableau, pas int
- puts est ton ami
- tu ne vérifies jamais le retour de scanf
 
 
#     scanf("%c", &rep);
#             getchar();
#
#         /* Tant que réponse différente O/N */
#         } while (rep != 'o' && rep != 'n');
 
 
ça c'est typiquement une boucle infinie ...
 
du reste, je comprends ce que c'est que tous ces getchar() dans tous les sens, c'est inutilisable un programme ou il faut passer ton temps à appuyer sur entrée pour rien

Reply

Marsh Posté le 04-10-2004 à 19:58:17    

Taz a écrit :

- return c'est pas une fonction pour ce qui en douteraient
- ça manque cruellement de const
- int main()
- ton NB c'est pas flexible du tout
- utilise size_t pour parcourir un tableau, pas int
- puts est ton ami
- tu ne vérifies jamais le retour de scanf
 
 
#     scanf("%c", &rep);
#             getchar();
#
#         /* Tant que réponse différente O/N */
#         } while (rep != 'o' && rep != 'n');
 
 
ça c'est typiquement une boucle infinie ...
 
du reste, je comprends ce que c'est que tous ces getchar() dans tous les sens, c'est inutilisable un programme ou il faut passer ton temps à appuyer sur entrée pour rien


 
Le "getchar()" c'est pour ôter du clavier le return qui suit le nombre lorsqu'on le saisit.
 
Ta définition de boucle infinie est à revoir. Le pgm sort de la boucle quand "rep" vaut "o" ou "n". De plus, j'ai quand-même testé ce pgm sur un système Linux
 
int main() => ok. Bien qu'une fonction sans typage soit "int" par défaut je suis d'accord avec toi
 
Je ne comprends pas ce que tu entends par "flexible". On en a déjà discuté. Si le préprocesseur est ton ennemi ce n'est pas le mien.
 
Pourquoi "size_t" ??? Tu aurais dit un "unsigned long" j'aurais compris mais là...
 
 
 


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 04-10-2004 à 20:21:37    

Sve@r a écrit :

Le "getchar()" c'est pour ôter du clavier le return qui suit le nombre lorsqu'on le saisit.

inutile
 

Sve@r a écrit :


Ta définition de boucle infinie est à revoir. Le pgm sort de la boucle quand "rep" vaut "o" ou "n". De plus, j'ai quand-même testé ce pgm sur un système Linux

non c'est toi là qui n'as pas compris ...

Sve@r a écrit :


int main() => ok. Bien qu'une fonction sans typage soit "int" par défaut je suis d'accord avec toi

était, fut, mais pas 'soit'. Le changement date de 83 non ?
 

Sve@r a écrit :


Je ne comprends pas ce que tu entends par "flexible". On en a déjà discuté. Si le préprocesseur est ton ennemi ce n'est pas le mien.

tu soulèves toi même le problème : si NB change, il faut tout recompiler. Le prends pas comme ça, là dernière fois que je t'ai vu  faire une macro, c'était un massacre. Pense également aux nombres de gens qui ont fait un #define NB et voit le nombre de collisions possibles
 

Sve@r a écrit :


Pourquoi "size_t" ??? Tu aurais dit un "unsigned long" j'aurais compris mais là...

parce que le type, c'est size_t et rien d'autres. Tu vois, toi même tu te perds déjà à savoir si c'est un int, un long, un unsigned long. size_t c'est size_t, où que tu sois

Reply

Marsh Posté le 04-10-2004 à 20:24:29    

Sve@r, ca sert a rien, rien que pour le scanf sans controle retour, tu risque la boucle inf en cas de saisie erronée comme l'a dit taz

Reply

Marsh Posté le 05-10-2004 à 16:50:10    

Taz a écrit :

le "getchar()" est inutile


C'est toi qui m'a appris cela ! Le "scanf(%d)" s'arrête à tout ce qui n'est pas numérique et s'il reste un "return" de trop, j'ai qu'à le sauter. alors je le saute avec "getchar()" !!!
 

Taz a écrit :

était, fut, mais pas 'soit'. Le changement date de 83 non ?


Ca c'est la norme "C99". dans la norme "C90" une fonction non-déclarée est de type "int"
 

Taz a écrit :

tu soulèves toi même le problème : si NB change, il faut tout recompiler. Le prends pas comme ça, là dernière fois que je t'ai vu  faire une macro, c'était un massacre. Pense également aux nombres de gens qui ont fait un #define NB et voit le nombre de collisions possibles


Si tu veux parler de ma macro où j'avais imbriqué des boucles et des conditionnelles en protégeant le retour à la ligne par des anti-slashes, le tout encapsulé par des accolades, eh bien elle était certainement horrible et immonde mais elle fonctionnait. mais le sujet n'est pas là. Ca t'embête tant de tout recompiler ? Tu veux faire quoi. Utiliser une constante pour la taille du tableau ? Ca c'est autorisé en C99 mais pas en C90. Et si j'ai une collision avec "NB redefined", mon compilateur me le dira mais je ne crois pas que dans les headers officiels il y ait beaucoup de "NB" !!!
 

Taz a écrit :

parce que le type, c'est size_t et rien d'autres. Tu vois, toi même tu te perds déjà à savoir si c'est un int, un long, un unsigned long. size_t c'est size_t, où que tu sois


Là, je ne comprends plus du tout. Tu me dis "le type c'est" mais type de quoi ? de la taille du tableau ?? Cette taille n'a pas de variable et donc pas de type !!! Ensuite, si le tableau fait moins de 128 éléments je peux le balayer avec un "char" si j'en ai envie. S'il en fait moins de 256 je peux utiliser un "unsigned char". etc etc. Si vraiment je veux être tranquille j'utilise un "unsigned long". Ensuite je ne crois pas que l'on puisse manipuler des tableaux plus grands...
 
Je tiens quand-même compte de tes remarques et j'ai réécrit le programme en essayant un compromis entre tes opinions et les miennes. Le pauvre Turkoglu n'y comprendra sans-doute plus rien mais j'espère qu'au-moins il satisfaira la TazNorme...

Code :
  1. #include <stdio.h>
  2. #define NB  (3)  /* Nombre d'éléments */
  4. /* Structure qui gère la question et la vérification de la réponse */
  5. typedef struct {
  6. char *prompt;   /* Prompt à afficher */
  7. size_t (*verif)(const int*); /* Fonction de vérification */
  8. size_t result;   /* Résultat à avoir */
  9. } t_question;    /* Type de cette structure */
  11. /* Prototype des fonctions utilisées */
  12. size_t croissance(const int*); /* Vérifie la croissance */
  13. size_t impair(const int*); /* Compte combien il y a d'impair */
  14. size_t egalite(const int*); /* Vérifie tous égaux */
  15. size_t different(const int*); /* Vérifie tous différents */
  16. size_t un_et_somme(const int*); /* Vérifie un plus grand que la somme */
  18. int main()
  19. {
  20. int tabNB[NB];   /* Tableau des nombres */
  21. char rep[3];   /* Réponse o/n */
  22. size_t nb_ok;   /* Nb bonnes réponses */
  23. size_t nb_rep;   /* Nb réponses */
  24. size_t res;   /* Résultat de l'évaluation */
  25. static t_question tabQuestion[]={/* Tableau des questions */
  26.  {"Les nombres sont-ils croissants", croissance, 1},
  27.  {"Les nombres sont-ils tous impairs", impair, NB},
  28.  {"Y a-t-il un seul impair", impair, 1},
  29.  {"Les nombres sont-ils tous pairs", impair, 0},
  30.  {"Y a-t-il un seul pair", impair, NB - 1},
  31.  {"Les nombres sont-ils tous égaux", egalite, 1},
  32.  {"Les nombres sont-ils tous différents", different, 1},
  33.  {"L'un des nombres est-il plus grand que la somme des autres", un_et_somme, 1},
  34.  {NULL, NULL}
  35. };
  36. t_question *ptQuestion;  /* Ptr balayage des questions */
  38. /* On fait saisir les nombres */
  39. for (nb_rep=0; nb_rep < NB; nb_rep++)
  40. {
  41.  printf("Entrez le nombre %d :", nb_rep + 1);
  42.  fflush(stdout);
  43.  scanf("%d", &tabNB[nb_rep]);
  44.  getchar();
  45. }
  47. /* Balayage des questions */
  48. nb_ok=0;
  49. for (ptQuestion=tabQuestion, nb_rep=0; ptQuestion->prompt != NULL; ptQuestion++, nb_rep++)
  50. {
  51.  do {
  52.   /* On pose la question */
  53.   printf("%s (o/n) ? ", ptQuestion->prompt);
  54.   fflush(stdout);
  56.   /* On attend la réponse (O/N suivi de 'return') */
  57.   fgets(rep, 3, stdin);
  59.  /* Tant que réponse différente O/N */
  60.  } while (*rep != 'o' && *rep != 'n');
  62.  /* On évalue les nombres par rapport à la question */
  63.  res=(ptQuestion->verif)(tabNB);
  65.  /* On vérifie que la réponse correspond au résultat */
  66.  if ((*rep == 'o' && res == ptQuestion->result) || (*rep == 'n' && res != ptQuestion->result))
  67.  {
  68.   printf("Bonne réponse\n" );
  69.   nb_ok++;
  70.  }
  71.  else
  72.   printf("Mauvaise réponse\n" );
  73. }
  75. /* Affichage final */
  76. printf("Vous avez donné %d bonnes réponses sur %d\n", nb_ok, nb_rep);
  77. return(0);
  78. }
  80. /* Fonction qui vérifie la croissance */
  81. size_t croissance(const int *tabNB)
  82. {
  83. size_t i;   /* Indice de boucle */
  85. /* On balaye les nombres */
  86. for (i=1; i < NB; i++)
  87. {
  88.  /* On regarde si la croissance s'interromp */
  89.  if (tabNB[i] <= tabNB[i - 1])
  90.   /* La croissance n'est plus respectée */
  91.   return(0);
  92. }
  94. /* Tous croissants */
  95. return(1);
  96. }
  98. /* Fonction qui compte le nombre d'impairs */
  99. size_t impair(const int *tabNB)
  100. {
  101. size_t cpt;   /* Compteur des impairs */
  102. size_t i;   /* Indice de boucle */
  104. /* On balaye les nombres */
  105. cpt=0;
  106. for (i=0; i < NB; i++)
  107. {
  108.  if ((tabNB[i] % 2) == 1)
  109.   /* Le nombre est impair */
  110.   cpt++;
  111. }
  113. /* On renvoie le résultat */
  114. return(cpt);
  115. }
  117. /* Fonction qui vérifie qu'ils sont tous égaux */
  118. size_t egalite(const int *tabNB)
  119. {
  120. size_t i;   /* Indice de boucle */
  122. /* On balaye les nombres */
  123. for (i=1; i < NB; i++)
  124. {
  125.  /* On regarde si le nombre est différent du premier */
  126.  if (tabNB[i] != tabNB[0])
  127.   /* L'égalité n'est plus respectée */
  128.   return(0);
  129. }
  131. /* Tous égaux */
  132. return(1);
  133. }
  135. /* Fonction qui vérifie qu'ils sont tous différents */
  136. size_t different(const int *tabNB)
  137. {
  138. size_t i;   /* Indice de boucle */
  139. size_t j;   /* Indice de boucle */
  141. /* On balaye les nombres */
  142. for (i=1; i < NB; i++)
  143. {
  144.  /* On balaye les nombres situés avant celui en cours */
  145.  for (j=0; j < i; j++)
  146.  {
  147.   /* On regarde si le nombre est égal à un des nombres précédents */
  148.   if (tabNB[i] == tabNB[j])
  149.    /* L'inégalité n'est plus respectée */
  150.    return(0);
  151.  }
  152. }
  154. /* Tous inégaux */
  155. return(1);
  156. }
  158. /* Fonction qui vérifie si l'un est plus grand que la somme des autres */
  159. size_t un_et_somme(const int *tabNB)
  160. {
  161. size_t i;   /* Indice de boucle */
  162. size_t j;   /* Indice de boucle */
  163. int somme;   /* Somme des autres */
  165. /* On balaye les nombres */
  166. for (i=0; i < NB; i++)
  167. {
  168.  somme=0;
  170.  /* On balaye les autres nombres pour les additionner */
  171.  for (j=0; j < NB; j++)
  172.  {
  173.   /* Si on est sur le même nombre */
  174.   if (i == j)
  175.    /* On le saute */
  176.    continue;
  178.   /* On additionne le nombre */
  179.   somme+=tabNB[j];
  180.  }
  182.  /* On compare le nombre en cours et la somme des autres */
  183.  if (tabNB[i] > somme)
  184.   /* On a trouvé */
  185.   return(1);
  186. }
  188. /* Aucun des nombres n'est plus grand que la somme des autres */
  189. return(0);
  190. }


Message édité par Sve@r le 05-10-2004 à 16:52:01

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 05-10-2004 à 18:16:07    

Sve@r a écrit :

C'est toi qui m'a appris cela ! Le "scanf(%d)" s'arrête à tout ce qui n'est pas numérique et s'il reste un "return" de trop, j'ai qu'à le sauter. alors je le saute avec "getchar()" !!!
 
 
Ca c'est la norme "C99". dans la norme "C90" une fonction non-déclarée est de type "int"
 
 
Si tu veux parler de ma macro où j'avais imbriqué des boucles et des conditionnelles en protégeant le retour à la ligne par des anti-slashes, le tout encapsulé par des accolades, eh bien elle était certainement horrible et immonde mais elle fonctionnait. mais le sujet n'est pas là. Ca t'embête tant de tout recompiler ? Tu veux faire quoi. Utiliser une constante pour la taille du tableau ? Ca c'est autorisé en C99 mais pas en C90. Et si j'ai une collision avec "NB redefined", mon compilateur me le dira mais je ne crois pas que dans les headers officiels il y ait beaucoup de "NB" !!!
 
 
Là, je ne comprends plus du tout. Tu me dis "le type c'est" mais type de quoi ? de la taille du tableau ?? Cette taille n'a pas de variable et donc pas de type !!! Ensuite, si le tableau fait moins de 128 éléments je peux le balayer avec un "char" si j'en ai envie. S'il en fait moins de 256 je peux utiliser un "unsigned char". etc etc. Si vraiment je veux être tranquille j'utilise un "unsigned long". Ensuite je ne crois pas que l'on puisse manipuler des tableaux plus grands...
 
Je tiens quand-même compte de tes remarques et j'ai réécrit le programme en essayant un compromis entre tes opinions et les miennes. Le pauvre Turkoglu n'y comprendra sans-doute plus rien mais j'espère qu'au-moins il satisfaira la TazNorme...
 


1) non, pas comme ça, pas de cette manière en tout cas. si tu fais "echo 1 2 3 4 | prog" ça foire.
 
2) j'ai pas le papier sous les yeux, il me semble que justement, C89 déprécie cette usage du C K&R. Mais ça n'a pas d'importance la norme, c'est un mauvais usage et il est aujourd'hui proscrit
 
3)une mauvaise macro est une mauvaise macro. c'est pas avec une approche "tant que ça marche c'est bon" qu'on arrive à quelque chose. tu dis n'importe quoi, la taille d'un tableau est une constante quelque soit la norme. C99 permet de faire des VLA. Fais à malloc. Et pour la redéfinition de NB, encore une fois, c'est pas avec ton approche 'tant que ça marche' que t'arriveras à quelque chose. Il se peut qu'avec ton système et avec ces include, ça ne génère pas de conclusion. Il n'y a pas de .h officiel, ils sont libres, ils doivent juste fournir un certains nombres de déclaration. Donc ton NB, c'est dangereux, surtout que c'est évitable. Si tu tiens vraiment à garder ton NB à la noix, et bien utilise le en faisant des prototypes lisibles int t[NB] et pas avec des * explicites qui sont complètement déroutantes.
 
4) là tu nages complet, tu mélanges tout et son contraire. l'argument de l'opérateur [] est un size_t, il n'y a rien d'autre à dire
 
5) y a pas de TazNorme et return n'est toujours pas une fonction

Reply

Marsh Posté le 05-10-2004 à 18:45:10    

Ce type de entre débat ("int" et "size_t", "#define NB" ou pas) revient dans un grand nombre de posts. Je pense qu'il y a deux types biens distincts de projets :
- une application finie pour UN système, UNE utilisation particulière voire UN TP.
- une appli portable ou une bibliothèque de fonctions ou objets : pour DES systèmes / DES compilos...
On comprend aisément que les préoccupations ne soient pas les mêmes. Je pense que Turkoglu doit se situer dans la première catégorie et qu'il doit se sentir plus à l'aise avec "int" qu'avec "size_t". Si le "#define NB" pose un problème à la compile, il changera de symbole comme le dit Sve@r. Une boucle infinie dans un exo pour un tp, bof, dans tout autre projet plus ambitieux, c'est mortel.
Quand on fait son premier exo en C, on se préoccupe rarement de la souplesse du code et encore moins de sa portablité ! Voir son code fonctionner comme on l'entend est la récompense qui donne envie d'aller plus loin. En conclusion, arrêtez de vous étriper (et de poster 88280493 lignes de code !) vous avez raison tous les deux.


---------------
If I want to fail and succeed, which I have done ?
Reply

Marsh Posté le 05-10-2004 à 19:08:48    

moi je vois pas le problème avec size_t c'est pourtant facile à utiliser et sans problème. Surtout c'est conseiller, en milieu universitaire, on travaille très vite sur autre chose que du X86-32bits

Reply

Marsh Posté le 05-10-2004 à 20:45:18    

lsdyoyo a écrit :

Ce type de entre débat ("int" et "size_t", "#define NB" ou pas) revient dans un grand nombre de posts. Je pense qu'il y a deux types biens distincts de projets :
- une application finie pour UN système, UNE utilisation particulière voire UN TP.
- une appli portable ou une bibliothèque de fonctions ou objets : pour DES systèmes / DES compilos...
On comprend aisément que les préoccupations ne soient pas les mêmes. Je pense que Turkoglu doit se situer dans la première catégorie et qu'il doit se sentir plus à l'aise avec "int" qu'avec "size_t". Si le "#define NB" pose un problème à la compile, il changera de symbole comme le dit Sve@r. Une boucle infinie dans un exo pour un tp, bof, dans tout autre projet plus ambitieux, c'est mortel.
Quand on fait son premier exo en C, on se préoccupe rarement de la souplesse du code et encore moins de sa portablité ! Voir son code fonctionner comme on l'entend est la récompense qui donne envie d'aller plus loin. En conclusion, arrêtez de vous étriper (et de poster 88280493 lignes de code !) vous avez raison tous les deux.


Tu es notre Salomon !!!  :D


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 05-10-2004 à 21:01:12    

le C a été créé pour être portable et tout entier fait pour ça  : tout est défini ou indéfini, mais tout point du langage est caractérisé. L'oublier, c'est une erreur de jugement avec ses conséquences

Reply

Marsh Posté le 06-10-2004 à 12:19:59    

Taz, il faudrait comprendre que le reste du monde n'a pas forcément les mêmes préoccupations ou les mêmes objectifs que toi ! Excuses-nous d'exister.
Encore une fois : peu de programmeurs sont concernés par la portabilité de leur code, et ce, même si le langage qu'ils utilisent a été conçu à la base pour être portable. Dans le même ordre d'idée : le C a été conçu pour écrire des systèmes d'exploitation multi-plateformes, à ton avis combien de développeurs C s'en servent pour ça ?
Une fois admis que la portabilité n'est pas forcément un critère primordial pour UN développement précis, passons à l'étape suivante : la lisibilité du code pour le commun des mortels. A ton avis toujours, un source est-il plus lisible avec des "int" ou des "size_t" :heink: ? Est-il obligatoire de le truffer de "const" alors qu'on ne conçoit pas une fonction ou une méthode portable a intégrer dans une API ou une collection d'objets mais simplement et humblement SA petite fonction dans SON petit programme :heink: ?
Nous avons (largement) dévié du sujet de départ : le tp de Turkoglu. Son problème est, je pense, tout à fait dans la catégorie "petit programme". Quand on poste dans ce thread on essaie (je sais, c'est pas facile) de se mettre à son niveau :whistle: . En revanche, nous comptons tous sur toi, Taz, pour aider le developpeur qui s'embarquera dans un développement multi-OS de composants graphique ou encore sur les précautions à prendre en C++ avec les projets de 10.000+ lignes de code. :jap:  


---------------
If I want to fail and succeed, which I have done ?
Reply

Marsh Posté le 06-10-2004 à 12:24:14    

non, toi faudrait que tu comprennes que quand tu commences à étudier à la Fac, tu n'as __aucune__ idée de où et comment tu vas travailler. Alors si on t'apprends des langages universels, c'est pas pour rien. Si tu veux foutre en l'air ton apprentissage c'est toi qui vois.
 

Citation :

A ton avis toujours, un source est-il plus lisible avec des "int" ou des "size_t" :heink: ? Est-il obligatoire de le truffer de "const" alors qu'on ne conçoit pas une fonction ou une méthode portable a intégrer dans une API ou une collection d'objets mais simplement et humblement SA petite fonction dans SON petit programme :heink: ?

oui et oui. Mais fallait le dire tout de suite que tu fesais pas de C, ça m'aurait éviter de répondre ...
 
Et ça n'a rien à voir avec la taille du projet. Même sur 100 lignes, ces règles sont canoniques et une erreur de constness est un bug grave.


Message édité par Taz le 06-10-2004 à 12:25:00
Reply

Marsh Posté le 06-10-2004 à 17:54:32    

Ah, tu as appris en fac. Ok, je vois mieux le tableau. Premièrement, attention tu vas avoir un choc : je n'ai jamais été en fac. Si, si, j't'assures et en plus (second choc) : je ne suis pas le seul ! Je sévis dans un autre monde que le tiens.
Dans cet autre monde :
- Nous développons des applications pas uniquement pour la beauté de la chose. Je sais, j'ai honte de le dire.
- On trouve que des sources avec des "int" sont plus lisibles qu'avec des "size_t". D'une manière générale, on est attaché à la simplicité. Il faudrait pas que le gus qui risque de repasser un jour soit perdu dans des syntaxes pas évidentes et inutiles  :o (provoc).
- Très peu de développement sont conçu pour être portables. Bonjour les contraintes et le temps à y passer pour un résultat même pas garanti le jour où il faudrait changer de système ! Et donc, on a rarement que des étudiants soient formés à rendre leur source portable.
- On a besoin d'un prog, on le développe pour un système, on le debug, on l'installe et basta !
- Il existe des contraintes de temps de réalisation et de budget. On a pas toujours le temps de faire joli pour le sport. Quand faut que l'appli soit installée pour hier...
 
En conclusion de cette première partie : quel décalage entre l'école et le monde des extras-terrestres !
 

Citation :

Mais fallait le dire tout de suite que tu fesais pas de C, ça m'aurait éviter de répondre ...

 
Ca fait 15 ans que je fais du C et depuis peu du C++. Depuis près de 10 ans, je bosse dans un petite boîte (nous sommes 3). Nous développons une application en C (avec un soupçon d'asm) d'environ 75.000 lignes de code. En plus, c'est bourré de "char *" là dedans ! Ah ça, c'est sûr, faut faire gaffe, mais bonjour la vitesse. Cette appli est critique et tourne 24h/24, 7j/7 chez nos clients. Ils peuvent nous appeler à toute heure du jour et de la nuit en cas de plantage (oui, je l'ai dit, cette appli est critique pour eux). Nous avons environ 25 sociétés clientes pour environ une centaine de postes en réseau. Le résultat est que, ça va, merci, on dort bien la nuit. La fiabilité de notre soft est dans une bonne moyenne. Tiens, un détail, y'a AUCUN "const" ni "size_t" dans les sources, curieux non ?
Certains l'auront deviné, nous sommes (encore  :o ) sous DOS. Pour des raisons évidente d'obsolescence, nous attaquons le développement sous Windows. Le pire c'est qu'on a jamais pris de précaution de portabilité. Dommage ? Non : il faut presque tout récrire car trop de choses diffèrent ("G"UI, base de données...) et... ...les sources sont plus faciles à porter !
Allez, assez raconté ma vie, à toi.


---------------
If I want to fail and succeed, which I have done ?
Reply

Marsh Posté le 06-10-2004 à 18:05:02    

et ben je te plains :|

Reply

Marsh Posté le 06-10-2004 à 18:11:24    

Joel F a écrit :

et ben je te plains :|

ouais, ça fait franchement peur quand même ...

Reply

Marsh Posté le 06-10-2004 à 18:58:59    

Pourquoi me plaindre ?
Et qu'est-ce qui fait peur ?


---------------
If I want to fail and succeed, which I have done ?
Reply

Marsh Posté le 06-10-2004 à 19:58:40    

J'ai pas fait la fac non plus... et je supporte plutôt l'avis de Taz. En fait je vois pas trop le rapport avec la fac... c'est pas parce qu'on y étudie qu'on pense comme les profs. Donc tu veux vraiment savoir pourquoi ça fait peur ? Réponse: vous êtes 3 avec un soft qui, tel que tu le décris, doit être à la merci de la moindre erreur d'inatention lors de son évolution. Bin oui pas de const c'est marrant, mais c'est jamais que 6 caractères avec l'espace, et oh combien ça aide les const pour ne pas replonger dans la doc et/ou le code de la fonction appelée, pour faire des vérifs sup' à la compil, etc. Pour size_t passe encore, moi même je suis pas.. hum.
Mais tu vois tu l'avoues toi mm: vous devez tout réécrire pour le porter. Je vois pas en quoi c'est plus facile à porter quand c'est écrit sans const ni size_t. Enfin je suis surtout convaincu que c'est plus dur.
Ça coûte rien de coder propre et ça change la vie. Vu que t'as l'occasion de réécrire... essaie tu verras.
PS: alors sérieux l'argument des perfs (le "bonjour la vitesse" ) c'est vraiment n'importe quoi. Un const ne change qu'à la compil... idem pour tout ce qui est propre, on parle pas des algos là mais de la syntaxe et de la méthode.

Reply

Marsh Posté le 06-10-2004 à 20:09:46    

ah j'oubliais, les fonctions de la bibliothèque standard utilisent des size_t, alors n'oubliez pas de caster (sizeof, malloc, fread/fwrite, etc etc) :D. Et le jour où tu es sur une plateforme ou sizeof(int) != sizeof(size_t), tu bénis ton code avec tes size_t :)
 
 
 
et détrompe toi, un const bien placé (surtout quand il est avec son copain static, ça fait des miracles :)

Reply

Marsh Posté le 06-10-2004 à 20:12:16    

c'est completement stupide, c'est justement l'absence de const et de size_t qui tue la lisibilité du code

Reply

Marsh Posté le 06-10-2004 à 20:13:00    

pourquoi elle est pas de moi cette phrase [:taz]

Reply

Marsh Posté le 06-10-2004 à 20:16:10    

parce que taz was grilled

Reply

Marsh Posté le 06-10-2004 à 20:20:59    

j'ajoute que parcourir un tableau d'entier avec un int sous turbo c c'est du suicide

Reply

Marsh Posté le 07-10-2004 à 02:24:18    

lsdyoyo a écrit :

Ah, tu as appris en fac. Ok, je vois mieux le tableau. Premièrement, attention tu vas avoir un choc : je n'ai jamais été en fac. Si, si, j't'assures et en plus (second choc) : je ne suis pas le seul ! Je sévis dans un autre monde que le tiens.
Dans cet autre monde :
- Nous développons des applications pas uniquement pour la beauté de la chose. Je sais, j'ai honte de le dire.
- On trouve que des sources avec des "int" sont plus lisibles qu'avec des "size_t". D'une manière générale, on est attaché à la simplicité. Il faudrait pas que le gus qui risque de repasser un jour soit perdu dans des syntaxes pas évidentes et inutiles  :o (provoc).
- Très peu de développement sont conçu pour être portables. Bonjour les contraintes et le temps à y passer pour un résultat même pas garanti le jour où il faudrait changer de système ! Et donc, on a rarement que des étudiants soient formés à rendre leur source portable.
- On a besoin d'un prog, on le développe pour un système, on le debug, on l'installe et basta !
- Il existe des contraintes de temps de réalisation et de budget. On a pas toujours le temps de faire joli pour le sport. Quand faut que l'appli soit installée pour hier...
 
En conclusion de cette première partie : quel décalage entre l'école et le monde des extras-terrestres !
 

Citation :

Mais fallait le dire tout de suite que tu fesais pas de C, ça m'aurait éviter de répondre ...

 
Ca fait 15 ans que je fais du C et depuis peu du C++. Depuis près de 10 ans, je bosse dans un petite boîte (nous sommes 3). Nous développons une application en C (avec un soupçon d'asm) d'environ 75.000 lignes de code. En plus, c'est bourré de "char *" là dedans ! Ah ça, c'est sûr, faut faire gaffe, mais bonjour la vitesse. Cette appli est critique et tourne 24h/24, 7j/7 chez nos clients. Ils peuvent nous appeler à toute heure du jour et de la nuit en cas de plantage (oui, je l'ai dit, cette appli est critique pour eux). Nous avons environ 25 sociétés clientes pour environ une centaine de postes en réseau. Le résultat est que, ça va, merci, on dort bien la nuit. La fiabilité de notre soft est dans une bonne moyenne. Tiens, un détail, y'a AUCUN "const" ni "size_t" dans les sources, curieux non ?
Certains l'auront deviné, nous sommes (encore  :o ) sous DOS. Pour des raisons évidente d'obsolescence, nous attaquons le développement sous Windows. Le pire c'est qu'on a jamais pris de précaution de portabilité. Dommage ? Non : il faut presque tout récrire car trop de choses diffèrent ("G"UI, base de données...) et... ...les sources sont plus faciles à porter !
Allez, assez raconté ma vie, à toi.


 
Ben y'a vraiment pas de quoi t'en vanter.
Tu sevis (terme bien choisi) effectivement dans un autre monde.  
A+,


---------------
There's more than what can be linked! --    Iyashikei Anime Forever!    --  AngularJS c'est un framework d'engulé!  --
Reply

Marsh Posté le 08-10-2004 à 17:03:29    

Arrêtez vos délires.
- Taz, tu crois sincèrement qu'un jour size_t sera autre chose qu'un unsigned ? Je ne vois pas trop dans ce cas pourquoi unsigned est censé coller à la taille des registres CPU. Et si, pour la portabilité, tu te préoccupes du nombre d'octet occupé par les types de variable, il faut bannir "int" et rester avec "short" et "long".
- cris56, parcourir un tableau avec un "int" est du suicide ?  (je me disais aussi, c'est bizarre tous ces anges qui volent autour !) Mmmmouais, unsigned est-il mieux ? Bof, un débordement d'indice est un débordement d'indice et ce, même en inférieur : -1 est-il pire que 65535 ou 4294967295 ? Perso, si ça arrive, je trouve qu'au debug -1 est plus facile à tracer.
- g012, relis mon post. Le "bonjour la vitesse" parlait des "char *" et en aucun cas des const et autres size_t (c'est gentil de m'indiquer qu'ils ne changent rien à la vitesse d'exécution !). Quand j'ai dit que les sources sont plus faciles à porter, je me suis emporté. Je voulais surtout dire que ça n'aurait aidé en rien de concevoir du code portable quand le problème ne vient pas du code mais de l'environnement comme l'interface utilisateur ou la base de données.
 
Vous critiquez le développement de notre application sans rien en connaître ni tenir compte du résultat. Notez que je n'ai jamais affirmé que nos méthodes étaient les seules possibles ni que nos sources étaient irréprochables.
Je tenais à montrer qu'il est viable de produire du code sans s'occuper de sa portabilité ainsi que d'autres précautions. Referais-je pareil pour d'autres types de projet ? Sans doute pas.
J'ai écrit quelques classes de base pour nos futurs besoins en C++ sous Windows et, par exemple, elles sont truffées de "const" ! D'ailleurs, on en avait déjà quelques-uns dans nos sources C à certains endroits clés, mais en proportion de tous ceux où on auraient pu en coller, c'est négligeable.
 
Si j'ai parlé de nos sources c'est que je suis surpris par le nombre de posts qui critiquent le code publié uniquement sur la forme. Ca n'aide en rien. Dans ce thread, j'ai trouvé bien l'initative de Sve@r de montrer différentes approches du problème.
Et bam, prends-toi ça ! Sans compter le ton employé qui est parfois limite. Si seulement ce n'était qu'un exemple isolé (je ne sais plus qui a dit qu'il ne faut plus poster de code sur hardware.fr) ?
As-tu remarqué, Taz (was grilled), le nombre de gens qui te demandent des précisions lorsque tu leur parles dans un jargon incompréhensible ? Faut se mettre au même niveau que l'autre...
 
En final, je pensais naïvement que les sources servaient aussi à être compilées un jour et que les forums servaient à aider les gens.


Message édité par lsdYoYo le 08-10-2004 à 17:04:37

---------------
If I want to fail and succeed, which I have done ?
Reply

Marsh Posté le 08-10-2004 à 17:12:51    

Citation :

- cris56, parcourir un tableau avec un "int" est du suicide ?  (je me disais aussi, c'est bizarre tous ces anges qui volent autour !) Mmmmouais, unsigned est-il mieux ? Bof, un débordement d'indice est un débordement d'indice et ce, même en inférieur : -1 est-il pire que 65535 ou 4294967295 ? Perso, si ça arrive, je trouve qu'au debug -1 est plus facile à tracer.


il recommande d'utiliser size_t, sombre vébéteux :o


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 08-10-2004 à 17:15:03    

http://forum.hardware.fr/hardwaref [...] 8490-1.htm
No comments.


---------------
If I want to fail and succeed, which I have done ?
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed