fread et frwrite

Version imprimable

Voir 40 message(s) de cette discussion en une page

29/11/2006, 23h00
Emmanuel Delahaye

Citation:

Envoyé par gl

Qu'entends tu par fin de lecture ? Si tu parles de la fin de fichier,

La 'fin de fichier' est une cause possible de fin de lecture. L'autre cause est 'erreur de lecture'.

Citation:

on se retrouve justement dans un cas ou le nombre lu est inferieur au nombre demande, il suffit ensuite eventuellement de faire appel a feof() ou ferror() pour determiner si il s'agit de la fin du fichier ou d'une erreur de lecture.

Mais il le savait, l'animal...

Citation:

Le petit bout de code fournit gere ces deux cas de la meme maniere en copiant le nombre d'elements reelement lus dans le fichier destination.

Normal, il n'y a un cas (en fait 'évènement'), qui est 'fin de lecture'. Par contre, comme déjà expose 2 fois, il y a 2 causes possibles.

Re bonjour
Je voulais savoir si
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 fread(&xn,sizeof(short),1, in); while((fread(&xn,sizeof(short),1, in))!=EOF) { if(a==0) { printf("ecriture ok"); a=1; } fwrite (&yn, sizeof(short),1, out); fread(&xn,sizeof(short),1, in); }
etais une facon correcte de faire une copie d'un fichier binaire.
Lorsque je l'execute mon fichier de sortie est il le meme que celui d'entré?
Y a t il un autre moyen de détecter la fin de fichier?
merci

30/11/2006, 14h43
zooro

Ben non, tu as entre 2 et 3 lectures pour une écriture !
Donc forcément, les fichiers risquent d'être différents !

Concernant la fin de fichier, lit le man de fread:

Citation:

fread traite la fin du fichier comme une erreur, et l'appelant devra appeler feof(3) ou ferror(3) pour distinguer ce cas.

J'ai rectifier le code
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 nb=fread(&xn,sizeof(short),1, in); while(nb==1) { if(a==0) { printf("ecriture ok"); a=1; } fwrite (&yn, sizeof(short),1, out); nb=fread(&xn,sizeof(short),1, in); }
du coup lorsque la fin du fichier est atteinte nb ne recoit plus la valeure "1"
donc la copie se termine.
Y a til d'autres solutions?

30/11/2006, 14h56
sone47

Merci pour le lien
je vais essayer avec feof et ferror, mais quel est la difference du fonctionnement de ces instructions?
Merci
30/11/2006, 15h03
zooro

Citation:

Envoyé par sone47

Merci pour le lien
je vais essayer avec feof et ferror, mais quel est la difference du fonctionnement de ces instructions?
Merci

Le man de feof et ferror :

Citation:

Envoyé par man

La fonction feof teste l'indicateur de fin de fichier concernant le flux pointé par stream, et renvoie une valeur non nulle si cet indicateur est actif. L'indicateur de fin de fichier ne peut être réinitialisé que par la fonction clearerr.
La fonction ferror teste l'indicateur d'erreur concernant le flux pointé par stream, et envoie une valeur non nulle si cet indicateur est actif. L'indicateur d'erreur ne peut être réinitialisé que par la fonction clearerr.
30/11/2006, 15h42
Emmanuel Delahaye
Citation:

Envoyé par sone47

Merci pour le lien

Tu parles à qui ? De quoi ? Meri d'utiiser le bouton http://www.developpez.net/forums/ima...tons/quote.gif.

Citation:

je vais essayer avec feof et ferror, mais quel est la difference du fonctionnement de ces instructions?

Je doute que ces fonctions t'apportent quoi que ce soit. Pour détecter la fin de lecture, on utilise la valeur retournée par la fonction de lecture (ici, fread()). Je n'ai pas encore vérifié, mais ton code semble correct, mais si il peut probablement être simplifié.
Code:

1 2 3 4 5 6 while ((nb = fread (&xn, sizeof xn, 1, in)) == 1) { /* traitement de xn -> yn ... */ fwrite (&yn, sizeof yn, 1, out); }
Attention à ce code. la taille d'un short n'est pas forcément de 2 char. Ca dépend de l'implémentation. sauf cas très restreins de fichiers 'locaux', les données ne sont généralement pas enregistrée en format 'natif' (celui de l'implémentation) dans le fichier. En effet celui-ci peut changer d'une machine à l'autre, d'un système à l'autre, d'un compilateur à l'autre, d'une option de compilation à l'autre. Il n'y a donc rien de moins fiable et portable comme information.

Le principe est de considérer le fichier pour ce qu'il est réellement, c'est à dire un flux d'octets. C'est tout. Les fichiers C ne savent pas faire plus de manière portable.

Pour résoudre le problème de l'échange de données entre machines différentes, le principe est de spécifier un format de donné qui soit le plus indépendant possible du format interne des machines.

En conséquence, il existe deux façons de procéder pour transférer des données.
- Le format binaire
- Le format texte
Le format binaire consiste à définir un format indépendant basé sur des séquences d'octets. Certaines sont normalisés comme XDR (utilisé pour RPC), BER (utilisé pour SNMP) etc. C'est assez complexe et pas à la portée des débutants. Cependant, pour chaque format normalisé, il existe des bibliothèques d'implémentation qui transforment des données en flux et inversement...

Le format texte est beaucoup plus simple à mettre en oeuvre. Il consiste tout simplement à transformer les données en une représentation textuelle. Le jeu de caractère utilisé est très portable (ASCII) mais il est restreint (pas de caractères > 127, donc pas d'accentuées, par exemple). C'est rustique mais efficace. On peut définir un format de données simple comme CSV, par exemple, qui permet de résoudre la plupart des problèmes d'échange de données structurées.

Quoiqu'il en soit, le format des données doit être spécifié de manière indépendante des implémentations.
30/11/2006, 19h48
gl

Citation:

Envoyé par Emmanuel Delahaye

Citation:

Le petit bout de code fournit gere ces deux cas de la meme maniere en copiant le nombre d'elements reelement lus dans le fichier destination.

Normal, il n'y a un cas (en fait 'évènement'), qui est 'fin de lecture'. Par contre, comme déjà expose 2 fois, il y a 2 causes possibles.

Je te l'accorde il y a deux causes possible d'arret de la lecture. Le code fournit convient parfaitement pour traiter le cas "fin de fichier atteint".
Pour le cas "erreur de lecture" c'est une solution parmi tant d'autres, loin d'etre ideale mais parfois suffisante. Si il convient d'effectuer un autre traitement dans ce cas de figure, le test sur la cause de l'arret de lecture devient effectivement indispensable.
Dans tout les cas, utiliser une taille fixe, potentiellement differente de celle reellement lue par fread(), est une erreur.

PS: pour la question sur le sens de "fin de lecture", ma question etait reelle. Pour moi, le terme "fin" a, certes a tort, une connotation positive d'arret normal et prevu, d'ou ma question.
30/11/2006, 23h52
Emmanuel Delahaye

Citation:

Envoyé par gl

PS: pour la question sur le sens de "fin de lecture", ma question etait reelle. Pour moi, le terme "fin" a, certes a tort, une connotation positive d'arret normal et prevu, d'ou ma question.

Le terme "Arrêt de Lecture" est sans doute plus adéquate.
01/12/2006, 18h09
lylia SI

Bonjour
Sone47 , je reviens a ta premiere question concernant le fscanf, fprintf,fgets et fputs:D
En fait les fonctions fread et fwrite réalisent un transfert d'information- entre mémoire et fichier- qu'on qualifie de "BRUT" dans le sens ou ça se fait sans aucune transformation de l'information ,les octects qui figurent dans le fichier sont des copies conformes de ceux qui apparaissent en mémoire
mais en C, on peut également accompagner ces transferts d'informations d'opérations de formatage analogues a celles que réalisent printf ou scanf
les fichiers concernés par ces opérations de formatage c'est ce qu'on appelle de coutume DES FICHIERS DE TYPE TEXTE ce sont des fichiers que vous pouvez manipuler avec un éditeur et dans ce type de fichiers chaque octect représente un caractere codé en ASCII
et parmis les fonctions permettant de travailler avec des fichiers de type texte les suivantes:
fscanf(fichier,format,liste d'adresses)
fprintf (fichier,format,liste d'expressions)
fgetc(fichier)
fputc(caractere,fichier)
fgets(chaine,lgmax,fichier)
fputs(chaine,fichier)

Citation:

Envoyé par lylia SI

En fait les fonctions fread et fwrite réalisent un transfert d'information- entre mémoire et fichier- qu'on qualifie de "BRUT" dans le sens ou ça se fait sans aucune transformation de l'information ,les octects qui figurent dans le fichier sont des copies conformes de ceux qui apparaissent en mémoire

Non ! Erreur récurrente.

Ce qui fait la différence entre raw et cooked, c'est le mode d'ouverture. Point.

[DOS/Windows]

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
 
#include<stdio.h>
#include<ctype.h>
 
static void create (char const *fname, char const *line)
{
   FILE *fp = fopen (fname, "w");
   if (fp != NULL)
   {
      char const *p = line;
      while (*p != 0)
      {
         fputc (*p, fp);
         p++;
      }
      fclose (fp);
   }
   else
   {
      perror (fname);
   }
}
 
static void count (char const *fname, char const *mode)
{
   FILE *fp = fopen (fname, mode);
   if (fp != NULL)
   {
      int i = 0;
      int c;
      while ((c = fgetc (fp)) != EOF)
      {
         printf ("%3d", c);
         if (isprint (c))
         {
            printf (" '%c'", c);
         }
         putchar ('\n');
         i++;
      }
      fclose (fp);
      printf ("%d byte%s read in '%s' mode\n\n", i, i != 1 ? "s" : "", mode);
   }
   else
   {
      perror (fname);
   }
}
 
int main (void)
{
#define F "data.txt"
 
   create (F, "hello\n");
   count (F, "r");
   count (F, "rb");
   return 0;
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
104 'h'
101 'e'
108 'l'
108 'l'
111 'o'
 10
6 bytes read in 'r' mode
 
104 'h'
101 'e'
108 'l'
108 'l'
111 'o'
 13
 10
7 bytes read in 'rb' mode
 
 
Press ENTER to continue.

Voir 40 message(s) de cette discussion en une page