Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
864 connectés 

  FORUM HardWare.fr
  Programmation
  C

  [Améliorations] Programme de manipulation de fichiers

 
 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[Améliorations] Programme de manipulation de fichiers

n°2107869
lucas-84
Posté le 24-10-2011 à 17:26:54  profilanswer
 

Edit : désolé pour l'indentation bizarre, il y a eu un problème lors du c/c... :S

 

Bonjour,

 

Je vous présente un petit programme de manipulation de fichiers. Je suis à la recherche de remarques, critiques, etc, vu que je ne programme que depuis un an.

 

Voici le code :

 
Code :
  1. /**
  2. * \file main.c
  3. * \brief gere les arguments du main()
  4. * \author lucas-84
  5. * \version 0.1
  6. * \date 24/10/2011
  7. *
  8. * Gere les arguments du main() d'un programme de manipulation de fichiers.
  9. *
  10. */
  12. #include <stdio.h>
  13. #include <stdlib.h>
  14. #include <string.h>
  15. #include "error.h"
  16. #include "file.h"
  18. /**
  19. * \fn int main (void)
  20. * \brief Entrée du programme.
  21. *
  22. * \return EXIT_FAILURE en cas d'erreur, EXIT_SUCCESS sinon.
  23. */
  24. int main (int argc, char *argv[])
  25. {
  26.     const char *args[] = {"-c", "-r", "-w"};
  27.     ret_e (*handle_file) (const char *);
  29.     if (argc <= 1) {
  30. PRINT_ERROR_ARG_MAIN ();
  31. return EXIT_FAILURE;
  32.     }
  33.     if (strcmp (argv[1], args[0]) == 0) {
  34. handle_file = create_file;
  35.     } else if (strcmp (argv[1], args[1]) == 0) {
  36. handle_file = read_file;
  37.     } else if (strcmp (argv[1], args[2]) == 0) {
  38. handle_file = write_file;
  39.     } else {
  40. PRINT_ERROR_ARG_MAIN ();
  41. return EXIT_FAILURE;
  42.     }
  43.     if (handle_file (argv[2]) == RET_ERROR) {
  44. return EXIT_FAILURE;
  45.     }
  46.     return EXIT_SUCCESS;
  47. }
 
Code :
  1. /****************************************************************************
  2.   Name ........ : file.c
  3.   Role ........ : handles files
  4.   Author  ..... : lucas-84
  5.   Version ..... : V0.1 on 24/10/2011
  7.   Compilation :
  8.    gcc -Wall -pedantic -std=c99 -o zReader main.c file.c error.c
  9.   Execution :
  10.    ./zReader [OPTIONS] [FILE]
  11. ****************************************************************************/
  13. #include <stdio.h>
  14. #include <stdlib.h>
  15. #include <string.h>
  16. #include "error.h"
  17. #include "file.h"
  19. /**
  20. * \fn static ret_e open_file (const char *path, const char *mode)
  21. * \brief Ouvre un fichier
  22. *
  23. * \param path pointeur vers une chaine de caractere indiquant le chemin du
  24. * fichier a creer.
  25. * \param mode pointeur vers une chaine de caractere indiquant le mode
  26. * d'ouverture du fichier a creer.
  27. * \return NULL en cas d'erreur, le fichier ouvert sinon.
  28. */
  29. /*@null@*/ static FILE *open_file (const char *path, const char *mode)
  30. {
  31.     FILE *f = NULL;
  32.     if ((f = fopen (path, mode)) == NULL) {
  33. PRINT_ERROR ("fopen" );
  34. return NULL;
  35.     }
  36.     return f;
  37. }
  39. /**
  40. * \fn static ret_e close_file (FILE *f)
  41. * \brief Ferme un fichier
  42. *
  43. * \param f fichier a fermer.
  44. * \return RET_ERROR en cas d'erreur, RET_SUCCESS sinon.
  45. */
  46. static ret_e close_file (FILE *f)
  47. {
  48.     if (fclose (f) == EOF) {
  49. PRINT_ERROR ("fclose" );
  50. return RET_ERROR;
  51.     }
  52.     return RET_SUCCESS;
  53. }
  55. /**
  56. * \fn ret_e create_file (const char *path)
  57. * \brief Cree un fichier
  58. *
  59. * \param path pointeur vers une chaine de caractere indiquant le chemin du
  60. * fichier a creer.
  61. * \return RET_ERROR en cas d'erreur, RET_SUCCESS sinon.
  62. */
  63. ret_e create_file (const char *path)
  64. {
  65.     FILE *f = NULL;
  67.     if ((f = open_file (path, "w" )) == NULL) {
  68. return RET_ERROR;
  69.     }
  70.     if (close_file (f) == RET_ERROR) {
  71. return RET_ERROR;
  72.     }
  73.     return RET_SUCCESS;
  74. }
  76. /**
  77. * \fn ret_e read_file (const char *path)
  78. * \brief Lit un fichier
  79. *
  80. * \param path pointeur vers une chaine de caractere indiquant le chemin du
  81. * fichier a creer.
  82. * \return RET_ERROR en cas d'erreur, RET_SUCCESS sinon.
  83. */
  84. ret_e read_file (const char *path)
  85. {
  86.     FILE *f = NULL;
  87.     int c;
  89.     if ((f = open_file (path, "r" )) == NULL) {
  90. return RET_ERROR;
  91.     }
  92.     while ((c = fgetc (stdin)) != EOF) {
  93. (void) fprintf (stdout, "%c", c);
  94.     }
  95.     if (close_file (f) == RET_ERROR) {
  96. return RET_ERROR;
  97.     }
  98.     return RET_SUCCESS;
  99. }
  101. /**
  102. * \fn ret_e write_file (const char *path)
  103. * \brief Ecrit un fichier
  104. *
  105. * \param path pointeur vers une chaine de caractere indiquant le chemin du
  106. * fichier a creer.
  107. * \return RET_ERROR en cas d'erreur, RET_SUCCESS sinon.
  108. */
  109. ret_e write_file (const char *path)
  110. {
  111.     FILE *f = NULL;
  112.     char s[LINE_MAX] = "";
  114.     if ((f = open_file (path, "a+" )) == NULL) {
  115. return RET_ERROR;
  116.     }
  117.     (void) fprintf (stdout, "\"/quit\" to stop\n" );
  118.     while (fgets (s, (int) sizeof (s), stdin) != NULL &&
  119.    strstr (s, "/quit" ) == 0)  {
  120. (void) fputs (s, f);
  121.     }
  122.     if (close_file (f) == RET_ERROR) {
  123. return RET_ERROR;
  124.     }
  125.     return RET_SUCCESS;
  126. }
 
Code :
  1. /****************************************************************************
  2.   Name ........ : file.h
  3.   Role ........ : declares file.c functions
  4.   Author  ..... : lucas-84
  5.   Version ..... : V0.1 on 24/10/2011
  7.   Compilation :
  8.    gcc -Wall -pedantic -std=c99 -o zReader main.c file.c error.c
  9.   Execution :
  10.    ./zReader [OPTIONS] [FILE]
  11. ****************************************************************************/
  13. #ifndef FILE_H
  14. #define FILE_H
  16. #include "error.h"
  18. #define LINE_MAX  512
  20. ret_e create_file (const char *);
  21. ret_e read_file (const char *);
  22. ret_e write_file (const char *);
  24. #endif
 
Code :
  1. /****************************************************************************
  2.   Name ........ : error.h
  3.   Role ........ : declares error.c functions
  4.   Author  ..... : lucas-84
  5.   Version ..... : V0.1 on 24/10/2011
  7.   Compilation :
  8.    gcc -Wall -pedantic -std=c99 -o zReader main.c file.c error.c
  9.   Execution :
  10.    ./zReader [OPTIONS] [FILE]
  11. ****************************************************************************/
  13. #ifndef ERROR_H
  14. #define ERROR_H
  16. #include <errno.h>
  17. #include <stdio.h>
  18. #include <string.h>
  20. #define PRINT_ERROR(s)                                                       \
  21.     do {                                                                     \
  22.         (void) fprintf(stderr, "----------------------------------------"    \
  23.                                "----------------------------------------\n"  \
  24.                                "\t\t\t\t\tERROR\n\n"                         \
  25.                                "Fonction    : %s\n"                          \
  26.                                "File        : %s\n"                          \
  27.                                "Line        : %d\n"                          \
  28.                                "Description : %s\n"                          \
  29.                                "----------------------------------------"    \
  30.                                "----------------------------------------\n", \
  31.                                s, __FILE__, __LINE__, strerror(errno));      \
  32.     } while (0)
  35. #define PRINT_ERROR_ARG_MAIN()                                               \
  36.     do {                                                                     \
  37.         (void) fputs ("----------------------------------------"      \
  38.                       "----------------------------------------\n"      \
  39.                       "\t\t\t\t\tERROR\n\n"         \
  40.                       "Invalid argument.\n"         \
  41.                       "Synopsis : ./zReader [OPTIONS] [FILE]\n"       \
  42.                       "Options :\n"                 \
  43.                       "  -c : create file\n"         \
  44.                       "  -r : read file\n"         \
  45.                       "  -w : write file\n"         \
  46.                       "----------------------------------------"      \
  47.                       "----------------------------------------\n", stdout); \
  48.     } while (0)      
  50. #define PRINT_ERROR_ARG_FUNCTION(s)                                          \
  51.     do {                                                                     \
  52.         (void) fprintf(stderr, "----------------------------------------"    \
  53.                                "----------------------------------------\n"  \
  54.                                "\t\t\t\t\tERROR\n\n"                         \
  55.                                "Fonction    : %s\n"                          \
  56.                                "File        : %s\n"                          \
  57.                                "Line        : %d\n"                          \
  58.                                "Description : bad argument\n"                \
  59.                                "----------------------------------------"    \
  60.                                "----------------------------------------\n", \
  61.                                s, __FILE__, __LINE__);                       \
  62.     } while (0)
  64. /**
  65. * \enum ret_e
  66. * \brief Constantes d'erreurs.
  67. *
  68. * Str_err_e est un type de retour des fonctions de file.c indiquant si une
  69. * erreur s'est produite ou pas.
  70. */
  71. typedef enum {
  72.     RET_ERROR = -1,
  73.     RET_SUCCESS = 1
  74. } ret_e;
  76. #endif
 

Merci d'avance et bonne journée à vous tous,
lucas-84

 


Message édité par lucas-84 le 24-10-2011 à 17:30:18
mood
Publicité
Posté le 24-10-2011 à 17:26:54  profilanswer
 

n°2107898
gilou
Modérateur
Modzilla
Posté le 24-10-2011 à 19:22:04  profilanswer
 

Bon, j'ai pris une fonction au hasard.
C'est une question de style, mais plutôt que ceci:

Code :
  1. ret_e read_file (const char *path)
  2. {
  3.     FILE *f = NULL;
  4.     int c;
  5.     if ((f = open_file (path, "r" )) == NULL) {
  6.         return RET_ERROR;
  7.     }
  8.     while ((c = fgetc (stdin)) != EOF) {
  9.         (void) fprintf (stdout, "%c", c);
  10.     }
  11.     if (close_file (f) == RET_ERROR) {
  12.         return RET_ERROR;
  13.     }
  14.     return RET_SUCCESS;
  15. }


J'aurais écrit ceci:

Code :
  1. ret_e read_file(const char *path)
  2. {
  3.     FILE *f;
  4.     if (f = open_file(path, "r" )) {
  5.         int c = fgetc(stdin);
  6.         while (c != EOF) {
  7.             fprintf(stdout, "%c", c);
  8.             c = fgetc(stdin);
  9.         }
  10.         if (close_file(f)) {
  11.             return RET_SUCCESS;
  12.         }
  13.     }
  14.     return RET_ERROR;
  15. }


Ou j'ai un seul chemin amenant au succès, et un retour en erreur par défaut.
En plus, ça permet d'avoir des lignes de sens plus clair à la lecture:
if (f = open_file(path, "r" )) { --> Si on a ouvert le fichier ...
La manière dont tu as écrit ton code n'est utile que si tu fais des différentiations sur les types d'erreur rencontrées, et ce n'est manifestement pas le cas de ton code.
 
Le cast par (void) de le ligne (void) fprintf (stdout, "%c", c); est totalement inutile et à éviter AMHA.
A+,


Message édité par gilou le 24-10-2011 à 19:37:19

---------------
There's more than what can be linked! --    Iyashikei Anime Forever!    --  AngularJS c'est un framework d'engulé!  --
n°2107900
lucas-84
Posté le 24-10-2011 à 19:34:55  profilanswer
 

Salut,
 
Tout d'abord, merci à toi d'avoir répondu.
 
Je prend note pour le changement que tu proposes, par contre :
 

Code :
  1. # int c = fgetc(stdin);
  2. #         while (c != EOF) {
  3. #             fprintf(stdout, "%c", c);
  4. #             c = fgetc(stdin);
  5. #         }


 
 
Ce n'est pas un peu répétitif ?
 
Pour le cast, j'avais lu ça dans des conseils de codage de wikisource, cela permettait de bien tester les retours de fonction. Et puis, splint râle quand je ne caste pas, alors...


Message édité par lucas-84 le 24-10-2011 à 19:35:43
n°2107902
gilou
Modérateur
Modzilla
Posté le 24-10-2011 à 19:50:41  profilanswer
 

Euh, vu que tu ne fais qu’appeler la fonction, sans utiliser la valeur de retour de celle ci, il n'y a aucune raison valable pour qu'un outil râle dans ce cas précis.
Un outil peut râler en cas d'affectation mais ici il n'y en a pas.
 
Quand à être répétitif, c'est exactement la même chose que dans ton code, mais je préfère un test de boucle simple sans appel de fonction dedans si on peut l'éviter.
Il faudrait profiler pour voir si le code généré est plus efficace, mais ici, c'est plus une question de goût, de préoccupation de lisibilité et de maintenance.  
Ce que tu as écrit ici n'a rien de problématique, parce qu'on a des procédure de base bien connues comme fgetc et qu'on sait ce qu'elle fait.  
Par contre ce style peut être un peu moins compréhensible avec des procédures maisons dont on n'a pas toujours en tête ce qu'elles renvoient en cas d'échec (en particulier s'il y a plusieurs codes d'échec).
 
A+,


---------------
There's more than what can be linked! --    Iyashikei Anime Forever!    --  AngularJS c'est un framework d'engulé!  --
n°2107950
lucas-84
Posté le 25-10-2011 à 09:47:39  profilanswer
 

Citation :

Euh, vu que tu ne fais qu’appeler la fonction, sans utiliser la valeur de retour de celle ci, il n'y a aucune raison valable pour qu'un outil râle dans ce cas précis.
Un outil peut râler en cas d'affectation mais ici il n'y en a pas.

 
Citation :

Une bonne habitude consiste à caster en void tous les appels à des fonctions dont on souhaite ignorer les codes retour. Cette pratique facilite les contrôle avec les outils qualité.

 

[...]

 

Les outils de contrôle statiques comme splint émettent un warning lorsqu'un codes retour de fonction n'est pas testé ou explicitement ignoré.


http://fr.wikibooks.org/wiki/Conse [...] fication_3

 
Citation :

Quand à être répétitif, c'est exactement la même chose que dans ton code, mais je préfère un test de boucle simple sans appel de fonction dedans si on peut l'éviter.

 

En fait, c'est juste que j'ai vu deux fois « fgetc (stdin) » et ça m'a un peu surpris. Pas moyen de faire ça avec un do while ?

 
Citation :

Il faudrait profiler pour voir si le code généré est plus efficace, mais ici, c'est plus une question de goût, de préoccupation de lisibilité et de maintenance.  
Ce que tu as écrit ici n'a rien de problématique, parce qu'on a des procédure de base bien connues comme fgetc et qu'on sait ce qu'elle fait.  
Par contre ce style peut être un peu moins compréhensible avec des procédures maisons dont on n'a pas toujours en tête ce qu'elles renvoient en cas d'échec (en particulier s'il y a plusieurs codes d'échec).

 

Dans ce cas-là, est-il préférable de faire de même avec les conditions ? Aucun appel de fonction dedans ?

 


Message édité par lucas-84 le 25-10-2011 à 09:48:01
n°2107980
gilou
Modérateur
Modzilla
Posté le 25-10-2011 à 11:22:29  profilanswer
 

Citation :

Une bonne habitude consiste à caster en void tous les appels à des fonctions dont on souhaite ignorer les codes retour. Cette pratique facilite les contrôle avec les outils qualité.


Ça n'a pas grand intérêt sauf éventuellement, à indiquer explicitement à un outil, qui devrait être paramétrable afin de ne pas se préoccuper de ce genre de chose, qu'on ne se préoccupe pas de la valeur de retour. Bref, ça me semble plus être la règle posée pour faire plaisir à un outil et son concepteur qu'autre chose.
Dans la pratique, on ne rencontre pas ce style de cast dans du code C habituellement. Elle est pas complètement idiote donc cette règle, mais comme elle ne fait pas partie des usages, elle risque plus de déconcerter quelqu'un qui relira le code qu'autre chose.
 

Citation :

En fait, c'est juste que j'ai vu deux fois « fgetc (stdin) » et ça m'a un peu surpris. Pas moyen de faire ça avec un do while ?


A partir du moment ou on exécute le même nombre de fois fgetc (stdin), il vaut mieux avoir un code plus simple et lisible AMHA, en particulier, vis à vis de ce que l'on teste dans sa boucle.
 

Citation :

Dans ce cas-là, est-il préférable de faire de même avec les conditions ? Aucun appel de fonction dedans ?


On n’exécute la condition qu'une fois, alors c'est moins important, mais ça peut être préférable.
 
Mais en fait, l'intérêt de ce style, c'est le suivant:
Quand on a:
int (ou char) machin = f(blabla);
if (test sur machin) { bloc (ou on n'utilise pas machin) }
On peut le remplacer par
if (f(blabla)) { bloc }
parce que ça évite une variable inutile.
 
Idem quand on a:
int (ou char) machin = f(blabla);
while (test sur machin) { bloc (ou on n'utilise pas machin, sauf une fois, pour avoir une nouvelle valeur de test, en faisant machin = f(blabla)) }
On peut le remplacer par
ça se remplace par
while (f(blabla)) { bloc }
 
Par contre, a partir du moment ou on utilise la valeur testée dans le bloc, on ne gagne rien a utiliser ce style de codage (peut être quelques octets dans l'exécutable généré), et on rend la lecture moins claire.
 
Pour reprendre ta page exemple,

Citation :

while ((optc = getopt_long (argc, argv, "htvm", longopts, (int *) 0)) != EOF)


Un (bon) programmeur sait à quoi correspond getopt_long, donc il comprends le sens de ce code.
Mais dès que cela devient trop complexe à lire sans perdre le fil du code courant, il vaut mieux éviter, car c'est mauvais pour la maintenance du code.
 
Un autre point:
FILE *f = NULL;
Il vaut mieux éviter d'affecter a NULL un pointeur déclaré, car alors, le compilateur n'émettra plus les warnings qu'il émet quand un pointeur est utilisé avant d'avoir été affecté, puisque maintenant pour lui, le pointeur a été affecté avant première utilisation, et ça, c'est le genre de warning très utile.
(l'inconvénient c'est que si dans une fonction, on renvoie un pointeur sans l'avoir affecté, la fonction appelante ne peut pas vérifier qu'il n'y a pas eu affectation, mais dans la pratique je préfère ce cas de figure, car quand je récupère un pointeur d'une fonction appellée, je vais relire son code pour vérifier qu'il y a bien eu affectation avant retour de la fonction).
 
A+,


Message édité par gilou le 25-10-2011 à 11:35:22

---------------
There's more than what can be linked! --    Iyashikei Anime Forever!    --  AngularJS c'est un framework d'engulé!  --
n°2108016
lucas-84
Posté le 25-10-2011 à 13:51:27  profilanswer
 

Merci encore une fois pour ta réponse.

 
Citation :

Ça n'a pas grand intérêt sauf éventuellement, à indiquer explicitement à un outil, qui devrait être paramétrable afin de ne pas se préoccuper de ce genre de chose, qu'on ne se préoccupe pas de la valeur de retour. Bref, ça me semble plus être la règle posée pour faire plaisir à un outil et son concepteur qu'autre chose.
Dans la pratique, on ne rencontre pas ce style de cast dans du code C habituellement. Elle est pas complètement idiote donc cette règle, mais comme elle ne fait pas partie des usages, elle risque plus de déconcerter quelqu'un qui relira le code qu'autre chose.

 

Si on gagne en lisibilité, je m'avoue vaincu. Mais bon, avec splint :

 
Citation :

file.c:149:3: Return value (type int) ignored: fputs(s, f)
  Result returned by function call is not used. If this is intended, can cast
  result to (void) to eliminate message. (Use -retvalint to inhibit warning)

 
Citation :

On n’exécute la condition qu'une fois, alors c'est moins important, mais ça peut être préférable.
 
Mais en fait, l'intérêt de ce style, c'est le suivant:
Quand on a:
int (ou char) machin = f(blabla);
if (test sur machin) { bloc (ou on n'utilise pas machin) }
On peut le remplacer par
if (f(blabla)) { bloc }
parce que ça évite une variable inutile.
 
Idem quand on a:
int (ou char) machin = f(blabla);
while (test sur machin) { bloc (ou on n'utilise pas machin, sauf une fois, pour avoir une nouvelle valeur de test, en faisant machin = f(blabla)) }
On peut le remplacer par
ça se remplace par
while (f(blabla)) { bloc }
 
Par contre, a partir du moment ou on utilise la valeur testée dans le bloc, on ne gagne rien a utiliser ce style de codage (peut être quelques octets dans l'exécutable généré), et on rend la lecture moins claire.

 

Après réflexion, je suis tout à fait d'accord.

 
Citation :

Un (bon) programmeur sait à quoi correspond getopt_long, donc il comprends le sens de ce code.
Mais dès que cela devient trop complexe à lire sans perdre le fil du code courant, il vaut mieux éviter, car c'est mauvais pour la maintenance du code.
 
Un autre point:
FILE *f = NULL;
Il vaut mieux éviter d'affecter a NULL un pointeur déclaré, car alors, le compilateur n'émettra plus les warnings qu'il émet quand un pointeur est utilisé avant d'avoir été affecté, puisque maintenant pour lui, le pointeur a été affecté avant première utilisation, et ça, c'est le genre de warning très utile.
(l'inconvénient c'est que si dans une fonction, on renvoie un pointeur sans l'avoir affecté, la fonction appelante ne peut pas vérifier qu'il n'y a pas eu affectation, mais dans la pratique je préfère ce cas de figure, car quand je récupère un pointeur d'une fonction appellée, je vais relire son code pour vérifier qu'il y a bien eu affectation avant retour de la fonction).

 

Je prends note, c'est très intéressant. :)

 

Sinon, j'essaie en ce moment de décortiquer une suite de messages de splint :

 
Spoiler :

splint file.c
Splint 3.1.2 --- 03 May 2009

 

file.c: (in function open_file)
file.c:35:12: Dependent storage f returned as implicitly only: f
  Dependent storage is transferred to a non-dependent reference. (Use
  -dependenttrans to inhibit warning)
   file.c:30:34: Storage f becomes dependent
file.c: (in function create_file)
file.c:67:24: Fresh storage f not released before return
  A memory leak has been detected. Storage allocated locally is not released
  before the last reference to it is lost. (Use -mustfreefresh to inhibit
  warning)
   file.c:64:37: Fresh storage f created
file.c: (in function read_file)
file.c:91:24: Fresh storage f not released before return
   file.c:82:37: Fresh storage f created
file.c: (in function write_file)
file.c:114:6: Return value (type int) ignored: fputs(s, f)
  Result returned by function call is not used. If this is intended, can cast
  result to (void) to eliminate message. (Use -retvalint to inhibit warning)
file.c:116:24: Fresh storage f not released before return
   file.c:106:37: Fresh storage f created

 
 

D'après ce que j'ai déchiffré rapidement, on dirait qu'il ne détecte pas le fclose et donc la libération de la mémoire. Il me parle de memory leak, mais après avoir passé un coup de valgrind, je n'en vois aucune.
Mon file.c :

 
Code :
  1. /**
  2. * \file file.c
  3. * \brief manipule les fichiers
  4. * \author lucas-84
  5. * \version V0.2 on 25/10/2011
  6. * \date 24/10/2011
  7. *
  8. * Manipule les fichiers directement
  9. *
  10. */
  12. #include <stdio.h>
  13. #include <stdlib.h>
  14. #include <string.h>
  15. #include "error.h"
  16. #include "file.h"
  18. /**
  19. * \fn static ret_e open_file (const char *path, const char *mode)
  20. * \brief Ouvre un fichier
  21. *
  22. * \param path pointeur vers une chaine de caractere indiquant le chemin du
  23. * fichier a creer.
  24. * \param mode pointeur vers une chaine de caractere indiquant le mode
  25. * d'ouverture du fichier a creer.
  26. * \return NULL en cas d'erreur, le fichier ouvert sinon.
  27. */
  28. /*@null@*/ static FILE *open_file (const char *path, const char *mode)
  29. {
  30.     FILE *f = fopen (path, mode);
  32.     if (f == NULL) {
  33. PRINT_ERROR ("fopen" );
  34.     }
  35.     return f;
  36. }
  38. /**
  39. * \fn static ret_e close_file (FILE *f)
  40. * \brief Ferme un fichier
  41. *
  42. * \param f fichier a fermer.
  43. * \return RET_ERROR en cas d'erreur, RET_SUCCESS sinon.
  44. */
  45. static ret_e close_file (FILE *f)
  46. {
  47.     if (fclose (f) == EOF) {
  48.         PRINT_ERROR ("fclose" );
  49. return RET_ERROR;
  50.     }
  51.     return RET_SUCCESS;
  52. }
  54. /**
  55. * \fn ret_e create_file (const char *path)
  56. * \brief Cree un fichier
  57. *
  58. * \param path pointeur vers une chaine de caractere indiquant le chemin du
  59. * fichier a creer.
  60. * \return RET_ERROR en cas d'erreur, RET_SUCCESS sinon.
  61. */
  62. ret_e create_file (const char *path)
  63. {
  64.     FILE *f = open_file (path, "w" );
  66.     if (f != NULL) {
  67. return close_file (f);
  68.     }
  69.     return RET_ERROR;
  70. }
  72. /**
  73. * \fn ret_e read_file (const char *path)
  74. * \brief Lit un fichier
  75. *
  76. * \param path pointeur vers une chaine de caractere indiquant le chemin du
  77. * fichier a creer.
  78. * \return RET_ERROR en cas d'erreur, RET_SUCCESS sinon.
  79. */
  80. ret_e read_file (const char *path)
  81. {
  82.     FILE *f = open_file (path, "r" );
  84.     if (f != NULL) {
  85. int c = fgetc (stdin);
  87. while (c != EOF) {
  88.     fprintf (stdout, "%c", c);
  89.     c = fgetc (stdin);
  90. }
  91. return close_file (f);
  92.     }
  93.     return RET_ERROR;
  94. }
  96. /**
  97. * \fn ret_e write_file (const char *path)
  98. * \brief Ecrit un fichier
  99. *
  100. * \param path pointeur vers une chaine de caractere indiquant le chemin du
  101. * fichier a creer.
  102. * \return RET_ERROR en cas d'erreur, RET_SUCCESS sinon.
  103. */
  104. ret_e write_file (const char *path)
  105. {
  106.     FILE *f = open_file (path, "a" );
  108.     if (f != NULL) {
  109. char s[LINE_MAX] = "";
  111. fprintf (stdout, "\"/quit\" to stop\n" );
  112. while (fgets (s, (int) sizeof (s), stdin) != NULL &&
  113.        strstr (s, "/quit" ) == 0)  {
  114.     fputs (s, f);
  115. }
  116. return close_file (f);
  117.     }
  118.     return RET_ERROR;
  119. }
 

Merci à tous  !  :jap:
Bonne journée,
lucas-84


Message édité par lucas-84 le 25-10-2011 à 14:17:17

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C

  [Améliorations] Programme de manipulation de fichiers

 

Sujets relatifs
Tri croissant des fichiers dans l'explorateur WindowsTrouver emails dans fichiers récursifs
[lazarus] Manipulation de chaine et extraction de caractère[C] programme cherche les racines des polynomes
[Python] Aide pour un programme de débutant[Résolu] MIME::Lite Comment attacher plusieurs fichiers dans un mail?
Tester la présence de plusieurs fichiers dans un même répertoireDessiner graphe via un programme C++
faire un programme qui s'execute cotée serveurInterface Graphique et gestion de fichiers
Plus de sujets relatifs à : [Améliorations] Programme de manipulation de fichiers

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo
Page générée en 0.123 secondes

Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR