[AIDE] bug mon projet C

bug mon projet C [AIDE] - C - Programmation

Marsh Posté le 14-06-2008 à 15:20:53    

Je ne comprend pas les erreur généré et ou le problème qu'il y a quelqu'un pourrai m'aide  
svp
 

Code :
  1. #include <stdio.h>
  2. #include <stdlib.h>
  3. #include <windows.h>
  6. void saisi()
  7. {
  8. int ans;
  9. double base;
  10. double tx;
  12. system("cls" );
  13. printf("saisir le taux\n" );
  14. scanf("%lf",&tx);
  15. printf("saisir la basse d'amortisement\n" );
  16. scanf("%lf",&base);
  17. printf("saisir le nombre d anner d amortisement\n" );
  18. scanf("%d",&ans);
  19. system("cls" );
  20. printf("Saisie OK\n" );
  21. system("pause" );
  22. system("cls" );
  24. FILE *fdata_out;   // <<=== 1er erreurs
  25.                                        //'FILE' : illegal use of this type as an expression
  26.                                  // et je ne vois pas pourquoi
  27. fdata_out = fopen("data.ini","w" );
  28. fprintf(fdata_out,"%.2lf\t %.2lf\t %d\n",tx,base,ans);
  29. fclose(fdata_out);
  31. }
  34. void calcule()
  35. {
  36. int annees;
  37. double anuit;
  38. double base;
  39. int j;
  40. int i;
  41. double tx;
  42. double vc;
  43. double base2;
  44. double deg;
  45. double lin;
  46. system("cls" );
  48.  FILE *fdata_in;   // <<=== Idem ici
  49.  fdata_in = fopen("data.ini","r" );
  50.  fscanf(fdata_in,"%lf %lf %d",&tx,&base,&annees);
  51.  fclose(fdata_in);
  53. j=0;
  54. deg=(100 / annees)*tx;
  55. system("cls" );
  56. base2=base;
  57. printf("amortisement pour :\n\n" );
  58. printf(" -  %d Annee \n",annees);
  59. printf(" - %.2lf comme base d amortisement\n\n",base);
  60. printf("Annee\t|\tbase\t|\ttx degresif ( en %)\t|\ttx lineaire ( en %)\t|\t annuiter\t|\tvaleur net comptable\t|" );
  61. //if(wprint=1);
  62. //{
  63. // FILE *fiche
  64. //  fiche =fopen("./amodeg.txt","w" );
  65. //}
  66. for(i=1;i<=annees;i++)
  67. {
  68.  lin=100/(annees-j);
  69.  j=j+1;
  70.  anuit=0;
  71.  if( deg > lin)
  72.   anuit=base2*(deg/100);
  73.  else
  74.   anuit=base2*(lin/100);
  75.  vc=base2-anuit;
  76.  printf("%d",i,"\t|\t","%.2lf",base2,"\t|\t","%.2lf",deg,"\t\t|\t\t","%.2lf",lin,"\t\t\t|\t","%.2lf",anuit,"\t\t|\t\t","%.2lf",vc,"\t\t|" );
  77.  //if(wprint=1);
  78.  //{
  79.  // fwrite( char $variable,nbcar,nbcar,"amortisement.txt" );
  80.  //  fprintf(fdata,"%.2lf\t %.2lf\t %d\n",tx,base,ans);
  81.  //}
  82.  base2=vc;
  83. }
  84. //if(wprint=1);
  85. //{  
  86. // fclose(fiche);
  87. //}
  88. system("pause" );
  89. }
  92. int menu()
  93. {
  94. int _choix;
  95. system("cls" );
  96. printf("\t\t####################################################\n" );
  97. printf("\t\t#########  Calcul d'amortisement degresif  #########\n" );
  98. printf("\t\t####################################################\n" );
  99. printf("  1= Calcul avec affichage (seulement)\n" );
  100. printf("  2= Calcul avec copie dans une fichier\n" );
  101. printf("  3= saisie des information (taux nombre d'année et de la basse d'amortisement)\n" );
  102. printf("\n\n" );
  103. printf("0= quitter\n" );
  104. scanf("%d",&_choix);
  105. return _choix;
  106. }
  108. int main()
  109. {
  110. int choix;
  111. do
  112. {
  113.  choix=menu();
  114.  switch(choix)
  115.  {
  116.   case 1:calcule();
  117.     break;
  118.   case 2:calcule();
  119.     break;
  120.   case 3:saisi();
  121.     break;
  122.  }
  123. }while(choix!=0);
  124. return 0;
  125. }


 
 
Merci pour l'aide apporter

Reply

Marsh Posté le 14-06-2008 à 15:20:53   

Reply

Marsh Posté le 14-06-2008 à 15:28:53    

Merci le fait de deplacer les ligne  
FILE *variable;
en dessous des déclaration des variable ne généré plus de bug.
 
je reviendrais si j'ai d'autre souci ^^ merci

Reply

Marsh Posté le 14-06-2008 à 15:33:29    

C'est quoi la raison de ça d'ailleurs? Le compilo veut savoir combien de mémoire allouer avant de commencer le programme? Il s'en sort comment du coups avec l'allocation dynamique :??: ?

Message cité 2 fois
Reply

Marsh Posté le 14-06-2008 à 15:41:06    

nan mais ça c'est une limitation C89. Mais c'est pour faire des compilo plus simple à écrire j'imagine. aujourd'hui en C99 on s'en fiche: tu peux tout mélanger et c'est mieux.

Reply

Marsh Posté le 14-06-2008 à 15:42:15    

j utilise Visual studio 6 sp6

Reply

Marsh Posté le 14-06-2008 à 15:42:41    

bref: ça compile ou pas, mais si ça compile, ça ne pose aucun problème.

Reply

Marsh Posté le 14-06-2008 à 15:43:36    

avant l aide apporter par " NazzTazz " ça compiler pas
maintenant si

Reply

Marsh Posté le 14-06-2008 à 17:14:09    

heux comment on fait pour afficher le caractère "%" dans la console ???
 

Code :
  1. printf("%c",37);


^^
 
j ai une structure nommé "Tableau" et j aimerais crée un tableau de cet structure
du coup j initialise comme suivant

Code :
  1. Tableau tab[20];


pour un tableau de taille 20
mais comment faire pour un tableau de taille variable ?

Message cité 1 fois
Message édité par darkius le 14-06-2008 à 17:15:00
Reply

Marsh Posté le 14-06-2008 à 17:26:09    

malloc.
 
Element* t = malloc(n * sizeof *t);
// puis vérifier que t != NULL

Reply

Marsh Posté le 14-06-2008 à 18:22:54    

T1 je vais jamais m'y faire à ces malloc ... C'est tellement plus simple les truc style Vector de Java/C++/...

Reply

Marsh Posté le 14-06-2008 à 18:22:54   

Reply

Marsh Posté le 14-06-2008 à 18:23:54    

en tout cas merci pour l'aide apporter

Reply

Marsh Posté le 14-06-2008 à 19:30:01    

darkius a écrit :

heux comment on fait pour afficher le caractère "%" dans la console ???


Code :
  1. putchar('%');
  2. printf("%%" );
  3. puts("%" );
 
esox_ch a écrit :

C'est quoi la raison de ça d'ailleurs? Le compilo veut savoir combien de mémoire allouer avant de commencer le programme? Il s'en sort comment du coups avec l'allocation dynamique :??: ?


Tu peux déclarer des variables ailleurs mais il faut créer un nouveau bloc (en C89) :

Code :
  1. #include <stdio.h>
  4. int main(void)
  5. {
  6.    puts("Test" );
  7.  
  8.    {
  9.       int temp;
  10.    }
  11.    /* une fois sorti du bloc la variable temp n'existe plus */
  12.  
  13.    return 0;
  14. }


Message édité par dap++ le 14-06-2008 à 19:30:19

---------------
dap.developpez.com
Reply

Marsh Posté le 14-06-2008 à 21:11:55    

Oué un nouveau scope quoi ...

Reply

Marsh Posté le 14-06-2008 à 23:50:16    

esox_ch a écrit :

Il s'en sort comment du coups avec l'allocation dynamique :??: ?


Un compilateur C89 ne sait pas faire d'allocation dynamique

Message cité 1 fois
Message édité par sligor le 14-06-2008 à 23:51:04
Reply

Marsh Posté le 14-06-2008 à 23:54:42    

oui oui très bien mon projet est terminer en ce qui pour le code
me manque plus qu un rapport de 4 a 5 page a rédiger ... le plus chiant lol
 
merci a tous

Reply

Marsh Posté le 15-06-2008 à 11:33:57    

sligor a écrit :


Un compilateur C89 ne sait pas faire d'allocation dynamique


ça n'a rien à voir. mixer code et déclaration VS. VLA c'est pas du tout le même problème.

Reply

Marsh Posté le 15-06-2008 à 11:37:02    

Question :
Comment ça se fait que ces compilo C89 sont encore utilisés? Parce ce que j'ai du programmer un microcontrolleur il y a pas longtemps, et le compilo (fourni par MicroChip, le fabriquant) acceptait pas les déclarations au milieu du code ... Il y a un avantage ou c'est juste eux qui avaient pas envie de se re-écrire le truc?

Message cité 1 fois
Reply

Marsh Posté le 15-06-2008 à 13:13:47    

pas l'envie ou pas la nécessité.

Reply

Marsh Posté le 15-06-2008 à 13:20:14    

c'est quoi ton compilateur là ? il me semble que gcc est explicite pour ce genre de trucs

Reply

Marsh Posté le 15-06-2008 à 13:32:52    

esox_ch a écrit :

Question :
Comment ça se fait que ces compilo C89 sont encore utilisés?


A ma connaissance seul le compilateur de Sun supporte entièrement le C99. Les autres compilateurs le supportent que partiellement.
Donc pour écrire du code portable il faut écrire en C89.

Message cité 1 fois
Reply

Marsh Posté le 15-06-2008 à 13:36:31    

gcc toto.c -std=c99 marche farpaitement ;)

Reply

Marsh Posté le 15-06-2008 à 13:47:45    

sligor a écrit :


A ma connaissance seul le compilateur de Sun supporte entièrement le C99. Les autres compilateurs le supportent que partiellement.


 
J'crois que Sun cc ne supporte pas encore entièrement C99, pas plus que gcc ou lcc, mais qu'il s'en approche pas mal (idem pour les deux autres).

Reply

Marsh Posté le 15-06-2008 à 13:53:24    

On dévie du topic... mais comment ça se fait que les compilo mettent autant de temps à supporter cette nouvelle norme?

Message cité 1 fois
Reply

Marsh Posté le 15-06-2008 à 14:01:39    

sligor a écrit :

On dévie du topic... mais comment ça se fait que les compilo mettent autant de temps à supporter cette nouvelle norme?

 

Amha, c'est le support des arrays de taille variable qui doit être pénible à implémenter, avec plein de cas tordus.

 

Ca, en C99, c'est autorisé (et perso, je trouve cette idée dégueux):

 
Code :
  1. int main (void) {
  2. ...
  3. z = 256;
  4. char tmp[z];
  5. ...
  6. }
 

Ca veut dire que tu peux allouer un tableau de taille variable à l'execution sur la pile, ce qui est loin d'être une sinécure à traiter, entre les problèmes d'alignement, le fait que ca soit fait à l'execution et pas la compilation, etc.

 

Edit: et le support étendu des flottants et leurs erreurs associées.


Message édité par Gf4x3443 le 15-06-2008 à 14:05:10
Reply

Marsh Posté le 15-06-2008 à 14:03:25    

Ouais les VLA c'est une belle connerie je trouve. :/

Message cité 1 fois
Reply

Marsh Posté le 15-06-2008 à 14:41:42    

Elmoricq a écrit :

Ouais les VLA c'est une belle connerie je trouve. :/


bah c'est du Z: si tu ne comprends pas les limites et gains d'une fonctionnalité, tu te tires dans le pieds. Mais si tu utilises les VLA avec un n bien borné, ça devient intéressant.

Message cité 1 fois
Reply

Marsh Posté le 15-06-2008 à 15:17:27    

dans le genre pas mal non plus.
 

Code :
  1. void process_array( int h, int w, float tab[h][w]);


 
les VLA, ca appelle pas juste malloca ?

Message cité 1 fois
Reply

Marsh Posté le 15-06-2008 à 15:22:36    

Taz a écrit :


bah c'est du Z: si tu ne comprends pas les limites et gains d'une fonctionnalité, tu te tires dans le pieds. Mais si tu utilises les VLA avec un n bien borné, ça devient intéressant.


 
Certes
 
Je vois surtout venir les béotiens formés qui pondent du Java/C# (dégueux) à longueur de journée, et qui vont se retrouver à utiliser cette fonctionnalité comme ils se sont habitués à le faire dans leur langage de prédilection (et de manière sale, je parie).

Reply

Marsh Posté le 15-06-2008 à 15:25:18    

Joel F a écrit :

dans le genre pas mal non plus.
les VLA, ca appelle pas juste malloca ?


 
Ca peut. Le problème c'est que ca fait appel à des routines qui sont très machine dépendant, et les effets de bord sont dangereux.
 
Moi je vois surtout venir les mecs qui vont exploser leur pile sans comprendre.

Message cité 1 fois
Reply

Marsh Posté le 15-06-2008 à 16:32:23    

Gf4x3443 a écrit :


 
Ca peut. Le problème c'est que ca fait appel à des routines qui sont très machine dépendant, et les effets de bord sont dangereux.
 
Moi je vois surtout venir les mecs qui vont exploser leur pile sans comprendre.


 
Ah ça je dit pas le contraire. M'enfin, en attendant, j'ai eu sous les yeux du code indus qui fait exactement ce que j'ai montré.
Ça a l'air de marcher pas mal, mais bon c'est codé par des roxxor du Traitement du signal qui manie le -fstack-size= avec brio donc bon.
 
Enfin c'est toujours pareil, c'est un outil de plus, reste à enseigner au gens de l'utiliser proprement.

Reply

Marsh Posté le 15-06-2008 à 19:35:50    

Si je comprend bien le problème serait un peu le même qui arrive en Java & co quand tu commences à fouttre tout et n'importe quoi dans tes vecteurs en te disant que ça vaut pas la peine de créer un objet proprement pour tout stocker? Tu te manges donc des memory heap de partout..?

Message cité 1 fois
Reply

Marsh Posté le 15-06-2008 à 20:20:39    

esox_ch a écrit :

Si je comprend bien le problème serait un peu le même qui arrive en Java & co quand tu commences à fouttre tout et n'importe quoi dans tes vecteurs en te disant que ça vaut pas la peine de créer un objet proprement pour tout stocker? Tu te manges donc des memory heap de partout..?

 

Il est multi factoriel le problème.

 

D'un, ca ajoute une notion un peu éloignée du C, à savoir que l'on va pouvoir allouer dynamiquement de gros ensembles sur la pile. Ca pose un problème parce que:
- c'est très facile de faire des erreurs à ce niveau. Un stack overflow a des effets de bords notables, difficile à détecter car très machine dépendant. Exemple, les adresses de retour des fonctions, les paramètres passés aux fonctions... sont dans la pile.
- habitude du langage, au niveau pointeur, difficile à visualiser autrement. Et la encore, on peut prendre de très mauvaises habitudes de prog (et qui ne marchent pas nécessairement, qui plus est, alors que dans d'autres langages, ca peut marcher...).

 

Exemple qui me vient en tête:

 
Code :
  1. char * toto(int size) {
  2.       /* hey les copains, super, plus besoin de malloc(), ca fait tout tout seul! */
  3.       char * buf;
  4.       char tmp[size];
  5.       buf = tmp; /* ok, pourquoi pas... */
  6.       return buf; /* grosse connerie, sodo gravier goudron plumes */
  7. }
 

Il suffit que le gusse prennent l'habitude de tout faire "dynamiquement", facon garbage collector/allocation dynamique d'autres langages qui ont leur propre runtime, et ca va sembler valide au mec d'écrire ca. Alors que non.

 

Si le mec sait ce qu'il fait (genre en TSI, en bioinfo, ...), connait la différence entre un pointeur et un tableau, ok, pas de souci: j'approuve, moi même, je trouve que c'est utile. On peut s'astreindre de faire un appel système pour de l'allocation. On manipule des ensembles de taille variable, pour du calcul, c'est efficace, moins d'overhead à faire des appels systèmes.

 

La ou ca craint, c'est le développeur C du dimanche, qui a fait 3 semaines de C puis ensuite est passé à Java/C# ou autre, calque les comportements de ce langage au C lorsqu'il doit y revenir, et paf.

 

Les VLA c'est utile pour qui sait s'en servir. Or, c'est pas à la portée du premier béotien venu qui prétend être développeur C mais n'en fait que depuis 3 semaines. J'en ai vu.


Message édité par Gf4x3443 le 15-06-2008 à 20:23:34
Reply

Marsh Posté le 15-06-2008 à 20:27:45    

D'accord... Je vois mieux ...
Moi qui vient effectivement de Java (et qui fait du Ruby en ce moment) j'ai un mal de chien à me replonger dans ces questions d'allocation d'espace ... Et vu qu'en ce moment je prépare un examen sur les bases d'assembleur ... bein ça fait mal :D

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

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