ecriture en binaire vs indirect

Version imprimable

bonsoir ,
j'ai un peu teste les different mode d'ecritures et il y'a une grande difference que je ne comprend pas .
voila le code qui est tres simple :
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 #include<stdio.h> #include<stdlib.h> /*pour la fonction exit*/ #define MAX 5 int main(void){ FILE *fp; int t[5]={1,2,3,4,5}; int i=0; if( (fp = fopen("test.txt","wb")) == NULL ){ perror("ouverture en ecriture"); exit(1); } fwrite(t,sizeof(int),MAX,fp); printf("%ld\n",ftell(fp));/*affiche 20*/ fclose(fp); if( (fp = fopen("test2.txt","w"))== NULL ){ perror("ouverture en ecriture"); exit(2); } for(i=0;i<MAX;i++) fprintf(fp,"%d ",t[i]); printf("%ld\n",ftell(fp));/*affiche 10*/ fclose(fp); return 0; }
pourquoi en binaire le ftell m'affiche 20 et en normale il m'affiche 10 . alors que c'est la meme serie de nombre , je ne vois donc vraiment pas comment on peux se depacer sur un fichier en mode binaire ?
donc dois-je conclure que l'ecriture en mode binaire prend une grande place ?et surtous pourquoi ?
en esperant avoir ete claire , je vous souhaite une bonne nuit .

24/10/2008, 00h57
elmcherqui

j'ai une autre question :
- quand est ce qu'on utilise fflush(flot du fichier) . car je ne vois vraiement pas son utilitee , vu que l'ecriture en fichier ne peux pas echouer .
24/10/2008, 09h47
3DArchi

Citation:

Envoyé par elmcherqui

int t[5]={1,2,3,4,5};

Ecriture en binaire :"0000000100000002000000030000000400000005", soit 20 octects
Ecriture texte (fprintf(fp,"%d ",t[i])) : "1 2 3 4 5 ", soit 10 octets.
Ouvre les fichiers et tu verras tout de suite la différence.

Citation:

Envoyé par elmcherqui

donc dois-je conclure que l'ecriture en mode binaire prend une grande place ?

"FFFFFFFF" (4 octets) en binaire sera écrit "4294967295" (10 octets) en texte.

Citation:

Envoyé par elmcherqui

quand est ce qu'on utilise fflush(flot du fichier) .

Quand on veut forcer à écrire les données depuis la mémoire vers le disque.

Citation:

Envoyé par elmcherqui

car je ne vois vraiement pas son utilitee , vu que l'ecriture en fichier ne peux pas echouer .

Ah bon? Si ton programme plante, ou l'OS plante, ou tu as une brusque coupure d'électricité et que les écritures n'avaient pas été faites, elles sont perdues. fflush permet de garantir qu'après son appel les données ont bien été transférées sur le disque.

Je pense que tu devrais faire un petit tour vers les différents tutos pour comprendre la différence entre mode texte et mode binaire, la gestion des fichiers, etc...
Bon courage.
24/10/2008, 10h06
dtrosset

Bonjour,

Je crois que tu confonds écriture en binaire et écriture en binaire ...

Écriture en binaire :
Le "b" du "wb" de fopen ne sert qu'à éventuellement transformer les caractères de fin de ligne entre le fichier et ce que reçoit le programme. Le C considère en effet la fin de ligne indiquée par un seul caractère 0x0A, alors que typiquement, un fichier texte DOS ou Windows contiendra une paire de caractères 0x0D 0x0A. Par exemple si le fichier texte windows contient les octets (hex) 41 0D 0A 42 0D 0A (soit A et B chacun sur une ligne) en mode "b", le programme recevra 6 octets, alors qu'en mode non "b", le programme ne recevra que 4 octets (les 0D qui précedent un 0A sont supprimés). Sous UNIX/Linux, il n'y a aucune différence que le "b" soit présent ou pas, puisque les fin de lignes des fichiers textes sont indiquées par le seul caractère 0x0A, comme en C.

Écriture en binaire :
Quand tu utilises fwrite(), tu écris directement les octets de la représentation binaire de ce que tu envoies. Dans ton premier cas tu écris donc 5 fois 4 octets (la taille d'un int est 4). Ton fichier contient donc 20 octets (en hexa) : 01 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 05 00 00 00.
Quand tu utilises fprintf("%d "), tu écris du texte, et donc les octets de la représentation ASCII des nombres que tu envoies, séparés par des espaces. Ton fichier contient donc 10 octets (toujours en hexa) : 31 20 32 20 33 20 34 20 35 20.

Didier
24/10/2008, 23h25
elmcherqui

Merci pour vos reponses , fflush est maintenant plus claire .
j'ai donc une question : si elle permet de forcer l'ecriture des donnees sur le fichier pourquoi elle est tres rarement utilise ?

sinon si j'ai bien compris , quand j'ouvre en mode ecriture en binaires mes chiffres sont transforme en hexadecimal sur 8 bits .c'est bien sa ? et pourquoi precisement 8bits ?
25/10/2008, 00h47
Emmanuel Delahaye

Citation:

Envoyé par elmcherqui

Merci pour vos reponses , fflush est maintenant plus claire .
j'ai donc une question : si elle permet de forcer l'ecriture des donnees sur le fichier pourquoi elle est tres rarement utilise ?

Probablement parce qu'il est rare d'avoir à forcer l'écriture dans un fichier. en général, la fermeture suffit.

Citation:

Parce
sinon si j'ai bien compris , quand j'ouvre en mode ecriture en binaires mes chiffres sont transforme en hexadecimal sur 8 bits .c'est bien sa ? et pourquoi precisement 8bits ?

Je crois que tu n'as pas compris du tout...

Le mode binaire est tout simplement un mode 'transparent' ou 'brut' qui ne modifie rien des données. Aucune interprétation n'est faite. Ce qu'on lit est strictement ce qu'on a écrit.

Évidemment, il faut savoir ce qu'on fait et comprendre que le format des données sur une machine n'est pas forcément le même sur une autre machine. Il peut donc y avoir des problèmes de portabilité.

http://emmanuel-delahaye.developpez....m#enreg_struct
27/10/2008, 14h45
Obsidian

Citation:

Envoyé par elmcherqui

j'ai donc une question : si elle permet de forcer l'ecriture des donnees sur le fichier pourquoi elle est tres rarement utilise ?

Parce que le système est conçu pour que le programmeur n'ait pas à s'en soucier.

Le comportement « normal » lors d'un appel à toute fonction d'écriture est d'aller écrire la donnée dans le fichier. Seulement, ces appels sont très coûteux en ressources. C'est très long de faire un accès disque (et un accès cassette, ou bande magnétique, je ne te raconte pas). Donc, à la place, toutes les données sont cumulées dans une mémoire-tampon et celle-ci est vidée en une fois, dans trois cas : à intervalles réguliers, lorsque le tampon est plein, et lorsqu'un ordre explicite est envoyé (fflush()).

D'autre part, le système sait ce qu'il a à faire. Lorsque tu refermes un fichier, il est évident qu'il va effectuer un fflush() implicite, histoire de liquider ce qui traîne avant de classer l'affaire. Dans la même veine, si ton processus essaie de lire ce qu'il vient d'écrire, et que ces données sont toujours dans le tampon, eh bien le système ira les chercher au même endroit et, là encore, c'est transparent.

Donc, comme on l'a dit, la plupart du temps, tu n'as pas à t'en soucier. Le système gère ça au mieux. Coller des fflush() dans tous les coins, outre le fait d'être particulièrement sale, ne ferait que court-circuiter cette facilité.

En fait, les cas qui nécessitent l'intervention du programmeur pour vider les tampons sont pratiquement toujours ceux où un processus ou un acteur tiers à ton programme entrent en jeu : si plusieurs processus doivent écrire à tour de rôle dans le même fichier, celui doit impérativement être à jour au moment voulu. Même chose en lecture : si un programme A a écrit dans un fichier mais que c'est toujours dans les tampons, alors le programme B pourra l'attendre un certain temps. Ça peut être intéressant dans le cas d'un fork, également.

Sinon, le cas où l'on trouve souvent des fflush() dans un programme unique est lorsque l'on fait du déboguage en insérant des printf() un peu partout pour suivre l'état du programme. C'est spécialement vrai quand on utilise à la fois stdout et stderr. L'ordre de sortie des lignes peut alors ne pas être garanti. Mais dans ce cas, les meilleures choses à faire sont :

1) Apprendre à se servir d'un débogueur, à la place.
2) Ouvrir le fichier en demandant explicitement au système de ne pas utiliser de tampon, à l'aide de setbuf().