Retourner aux forums || Retourner au forum Programmation.c
Programmation.c : fwrite vs write
Posté par liberforce (Jabber id, page perso, ) le 25 novembre 2005Je développe un programme GTK+, et la question de l'écriture vers des fichiers est un peu confuse pour moi... la glib ne fournit un wrapper pour l'ouverture (g_open) mais pas pour la lecture/écriture d'un fichier...
Je dois donc choisir entre des appels à fwrite ou write. Mais lequel utiliser pour avoir un programme portable (sous linux et windows) ? En gros, guelle sont les différences entre les fonctions read/write/open , etc... et leur équivalent en f* ?
Question subsidiaire: comment savoir de quel header j'ai besoin pour utiliser telle ou telle fonction ? Par exemple, impossible de trouver le header qui me fournit "write", j'ai toujours l'erreur
lvfile.c:87: attention : déclaration implicite de la fonction << write >>
Merci pour votre aide... Tous les conseils sont la bienvenue...
> Lire le message (16 commentaires, moyenne: 2,1).
man
$ man 2 write
SYNOPSIS
#include <unistd.h>
ssize_t write(int fd, const void *buf, size_t count);
Voilou,
sinon fwrite c'est du ansi, alors que write c'est du posix. Donc si tu veux une portbilité max, je dirai plutot fwrite
le python, c'est bon
-
[^]Re: man
Posté par liberforce (Jabber id, page perso, ) le 25/11/2005 à 11:14. (lien). Évalué à 3.Merci pour ta réponse, j'avais bien tenté un man write, mais sous cygwin, il me jette:
$ man write
No manual entry for write
En tout cas c'est ce qu'il m'avait semblé comprendre, que fwrite était plus portable, mais alors pourquoi y a pas de wrapper dans la glib pour éviter la confusion ? Hum... Le mystère reste entier... Merci pour ton aide ;-)-
[^]Re: man
Posté par cho7 (page perso, ) le 25/11/2005 à 11:18. (lien). Évalué à 1.regarde bien ma ligne :
$ man 2 write
Car write n'a pas de pas de manuel autrement, j'ai du tapper dans la section 2 des manuels.
A la fin de man fwrite, ils te le mette d'ailleurs : voir aussi write(2). Tu sais désormais dans quelle section du manuel regarder :)
Sinon les différentes sections de manuels (d'après man man) :
1 Executable programs or shell commands
2 System calls (functions provided by the kernel)
3 Library calls (functions within program libraries)
4 Special files (usually found in /dev)
5 File formats and conventions eg /etc/passwd
6 Games
7 Miscellaneous (including macro packages and conven-
tions), e.g. man(7), groff(7)
8 System administration commands (usually only for root)
9 Kernel routines [Non standard]--
le python, c'est bon-
[^]Re: man
Posté par left () le 25/11/2005 à 13:50. (lien). Évalué à 3.Car write n'a pas de pas de manuel autrement, j'ai du tapper dans la section 2 des manuels.
Farce ? au contraire, si tu dois faire 'man 2 write', c'est justement parce que généralement il y a aussi un 'write' dans la section 1 des pages de manuel. La commande man parcours l'ensemble des pages de manuel section par section, et séléctionne la première page qui correspond.
Dans le même genre:
$ man printf -> manuel de printf du shell
$ man 3 printf -> manuel de printf du langage C
pour t'en convaincre, et si c'est installé sur ta machine: xman, qui est une GUI au pages de manuel.-
[^]Re: man
Posté par cho7 (page perso, ) le 25/11/2005 à 18:50. (lien). Évalué à 2.simple erreur de compréhension.
J'avais,une idée de phrase en tête, j'ai changé de tournure au dernier moment, et ca donne un truc bizarre. :)--
le python, c'est bon
-
-
[^]Re: man
Posté par liberforce (Jabber id, page perso, ) le 25/11/2005 à 15:34. (lien). Évalué à 2.non non, j'avais essayé man 2 write avant aussi...
$ man 2 write
No entry for write in section 2 of the manual
Apparemment, ce n'est pas fourni avec mon cygwin...
-
-
-
[^]Re: man
Posté par kolter (page perso, ) le 25/11/2005 à 11:14. (lien). Évalué à 3.je confirme, sans hésitations fwrite !
write est plus bas niveau que fwrite et bien moins pratique à utiliser !
M.-
[^]Re: man
Posté par liberforce (Jabber id, page perso, ) le 25/11/2005 à 16:00. (lien). Évalué à 2.pourquoi bien moins pratique ? Je ne vois que les éventuels soucis de portabilité... Peux tu argumenter un peu là dessus ? en quoi write (descripteur, donnees, taille_des_donnes) est moins pratique à utiliser ? Au contraire je le trouve plus simple moi, par rapport à fwrite...
$man fwrite
NAME
3.20 `fwrite'--write array elements
SYNOPSIS
#include <stdio.h>
size_t fwrite(const void *BUF, size_t SIZE,
size_t COUNT, FILE *FP);
-
[^]Re: man
Posté par Nicolas Boulay () le 25/11/2005 à 19:58. (lien). Évalué à 2.fwrite utilise un buffer alors que write non.
-
[^]Re: man
Posté par RedIsDead () le 29/11/2005 à 23:56. (lien). Évalué à 2.Tout a fait, write est un appel systeme bas niveau et qui est _bloquant_, donc il vaut mieux faire des write le plus gros possible pour optimiser le bousin.
C'est justement ce que charge de faire pour toi fwrite en mettant temporairement tout ce que tu veux ecrire dans un buffer et une fois que c'est plein, un gros write.
-
-
-
g_io_channel
Utilises g_io_channel (http://developer.gnome.org/doc/API/2.0/glib/glib-IO-Channels(...) ), c'est plus propre, plus portable et en bonus, tu as la gestion des problèmes d'encoding :-)
Ça donne du code qui ressemble à ça:
GIOChannel *chan = g_io_channel_new_file ("monfichier.txt", ...);
g_io_channel_set_encoding (chan, "ISO-8859-1", ...);
...
g_io_channel_read (chan, pointeur buffer, nb_octets à lire, pointeur nb octets lus);
...
g_io_channel_write (chan, pointeur buffer, nb octets à écrire, pointeur nb octets écrits)
...
g_io_channel_close (chan);
(bien sur, tester tous les retour de g_io_channel_* pour gérer proprement les erreurs)
-
[^]Re: g_io_channel
Posté par liberforce (Jabber id, page perso, ) le 25/11/2005 à 15:50. (lien). Évalué à 2.Hum... Intéressant, c'est bizarre, ça n'a pas l'air ni très connu, ni très utilisé... Des raisons particulières ?
Je m'attendais à trouver au moins une référence dans les "file utilities" de la glib ( http://developer.gnome.org/doc/API/2.0/glib/glib-File-Utilit(...) ). Mais non, rien... Je pense que ça va finir en question sur la mailing list gnome-love...-
[^]Re: g_io_channel
Posté par Arnaud (page perso, ) le 25/11/2005 à 17:47. (lien). Évalué à 1.Heu.. c'est quand même sur la page principale de la doc de la GLib! ( http://developer.gnome.org/doc/API/2.0/glib/ ) :
IO Channels - portable support for using files, pipes and sockets.
Je pense que si c'est peu utilisé, c'est que ça n'a pas encore été "approrié" par les développeurs. Et puis de toute façon plein de programmeurs s'appuies sur le VFS. Enfin, simple supposition, mon dada principal, c'est C++/Qt ;-)-
[^]Re: g_io_channel
Posté par liberforce (Jabber id, page perso, ) le 05/12/2005 à 15:04. (lien). Évalué à 2.Currently full support is available on UNIX platforms, support for Windows is only partially complete.
-
-
glib 2.8
Si tu as la glib 2.8 et que tu veux pas te faire chier, tu peux même utiliser directemetn g_file_get_contents/g_file_set_contents pour lire/écrire un fichier entier en un coup. Utilisé en combinaison avec des GString ça peut être un moyen simple d'écrire ton fichier.
-
[^]Re: glib 2.8
Posté par liberforce (Jabber id, page perso, ) le 28/11/2005 à 10:23. (lien). Évalué à 2.Effectivement, c'est à envisager, j'avais vu le get_contents mais pas le set_contents. Merci pour le coup de main :-)
Revenir en haut de page || Retourner aux forums || Retourner au forum Programmation.c
Cette page a été générée par Templeet en 0.1018s (dont 0.0259 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.