Version imprimable
Bonsoir,
Je me suis demandé : quelle différence entre fread(tampon, 1, n, fichier) et fread(tampon, n, 1, fichier) ?
Dans le 1e cas je lis n éléments de 1 octet, et dans le 2e cas je lis 1 élément de n octets, mais quelle différence pour les données que je vais retrouver dans mon tampon ?
Merci,
Spootnik
Bonne Année !
J'ai trouvé ça sur msdnCode:
2
Donc ecrit jusqu'a count Items de taille size chcun, ou count et size sont les 3eme et 2eme parametre respectivementCode:The fwrite function writes up to count items
Euh.. ce n'est pas ce que je demandais :roll:
Aucune. ( si tout se passe bien c'est la valeur de retour qui sera différente, puisque le nombre de blocs lus est différent )Citation:
Envoyé par Spootnik
Mais quel intérêt d'avoir ce prototype alors ?
Pourquoi pas simplement :
size_t fread(void *tampon, size_t n, FILE *fichier);
Où tampon est le tampon d'accueil des données, n le nombre d'octets à lire, fichier le fichier et la valeur retournée le nombre d'octets lus.
?
Je veux dire, si au niveau efficacité et données il n'y a pas de différence, pourquoi ce choix sur le nombre de blocs à lire ?
Est-ce que le résultat est aussi strictement le même en mode binaire ?
Parce qu'à vrai dire je vois juste un argument contre la deuxième façon (fread(tampon, n, 1, fichier)), c'est que vu qu'il n'y a qu'un seul bloc à lire, c'est du tout ou rien, alors que l'autre façon permet tout de même de lire une partie du fichier.
ssmario2 vient de te l'expliquer. Supposons que tu te trouves à deux caractères de la fin de ton fichier et que tu demandes à lire 10 caractères à placer dans buffer. Tu mets donc (bon code) :
Tu auras le premier caractère dans buffer[0] et le deuxième dans buffer[1]. Comme deux objets seulement ont été lus, fread retournera 2.Code:fread(buffer, sizeof(char), 10, f);
Si t'as mis cependant (mauvais code) :
fread retournera 0 (ça c'est un échec total ...) car il n'y a plus d'objet de taille égale à 10 * sizeof(char) à lire depuis ta position actuelle et tu n'auras rien de neuf dans buffer.Code:fread(buffer, 10 * sizeof(char), 1, f);
Oui c'est ce que je voulais dire par le "tout ou rien".
Mais justement quel intérêt d'avoir le choix si la deuxième méthode que tu présentes ("mauvais code") n'a que des inconvénients ?
N'oublions pas que fread() ne sert pas uniquement à lire des char, mais aussi des entiers, des structures, etc.Citation:
Envoyé par Spootnik
Les deux paramètres de fread() permettent donc de donner la taille de l'élément (et donc la taille du type) à lire et le nombre d'élément. Pour pouvoir lire des éléments de n'importe quel type, il est nécessaire[1] d'avoir ces deux informations.
[1] Il existe bien entendu d'autres solutions, mais toutes ont des avantages et inconvénients. L'utilisation de deux paramètres est un bon choix.
Donc la deuxième méthode présente l'avantage de pouvoir lire correctement certains types de données ?
Mais qu'en est-il des structures composées d'éléments de taille différente et enregistrées en binaire alors ?
Est-ce que le fait de lire par blocs de 1 octet pause problème pour l'interprétation d'un fichier binaire ?
Je parlais de bon et mauvais codes par rapport à ce qu'on voulait faire à savoir lire 10 caractères au plus à partir de la position actuelle. Si on voulait lire un tableau de 10 caractères à partir de cette même position, c'est la deuxième méthode qui est la bonne (on veut 10 caractères ou rien).
Oui :king:. C'est bien ça.Citation:
Donc la deuxième méthode présente l'avantage de pouvoir lire correctement certains types de données ?
Tu les lis avec la deuxième méthode, je croyais que t'avais enfin compris ...Citation:
Mais qu'en est-il des structures composées d'éléments de taille différente et enregistrées en binaire alors ?
Ca dépend de ce que tu veux faire. Si tu veux compresser le fichier par exemple, tu t'en fous de ce qu'il contient et tu le considère tout simplement comme une succession d'octets. Si tu sais exactement ce que le fichier contient, tu dois interpréter les données telles qu'elles sont censées être.Citation:
Est-ce que le fait de lire par blocs de 1 octet pause problème pour l'interprétation d'un fichier binaire ?
Mais il n'y a aucune perte d'information ? Par exemple si j'ai un entier sur 4 octets et que je lis par blocs de 2 octets puis que je rassemble ces données, le résultat reste correct ? (cherchez pas à comprendre pourquoi j'ai l'esprit aussi tordu :aie:)Citation:
Envoyé par Melem
Oui, mais comme tu viens de le dire, c'est toi qui rassemble ces données. Tu dédouanes donc la fonction de ce travail.Citation:
Envoyé par Spootnik
Il faut se souvenir qu'initialement, un fichier, c'est une boîte à fiches. Les fichiers en informatique portent ce nom car c'était au départ pour conserver ce genre d'information qu'ils ont été inventés. Les fiches étaient matérialisées par des structures de données de taille toujours fixe, qu'on enregistrait consécutivement sur une bande, sans autre forme de balisage.
Le fait de préciser explicitement au système la taille des éléments lui permet de faire des optimisations éventuelles à la lecture, mais cela sert surtout à garantir au programmeur que les n éléments déclarés comme lus par la fonction le sont réellement et en entier. Une demi-structure en fin de fichier due à des caractères surnuméraires, par exemple, ne sera pas comptabilisée.
Merci beaucoup, c'est très clair comme ça :) .Citation:
Envoyé par Obsidian
PS: j'aime bien ton avatar ^^
Je me permettrais de rajouter que lire octet par octet puis reconstituer "à la main" les éléments contenus dans le fichier est loin d'être trivial, il faut gérer l'alignement (et donc le padding), l'endianness, et toutes ces autres joyeusetés qui dépendent de l'implémentation.Citation:
Envoyé par ObsidianOui, mais comme tu viens de le dire, c'est toi qui rassemble ces données. Tu dédouanes donc la fonction de ce travail.Citation:
Envoyé par Spootnik
Il faut se souvenir qu'initialement, un fichier, c'est une boîte à fiches. Les fichiers en informatique portent ce nom car c'était au départ pour conserver ce genre d'information qu'ils ont été inventés. Les fiches étaient matérialisées par des structures de données de taille toujours fixe, qu'on enregistrait consécutivement sur une bande, sans autre forme de balisage.
Le fait de préciser explicitement au système la taille des éléments lui permet de faire des optimisations éventuelles à la lecture, mais cela sert surtout à garantir au programmeur que les n éléments déclarés comme lus par la fonction le sont réellement et en entier. Une demi-structure en fin de fichier due à des caractères surnuméraires, par exemple, ne sera pas comptabilisée.
"I want everybody to meet ..." :-)Citation:
Envoyé par Spootnik
+1.Citation:
Envoyé par gl
Ah, j'avais cru comprendre qu'il n'y avait pas de problème à ce niveau (c'était justement ça l'objectif de la discussion).. merci pour l'info.Citation:
Envoyé par gl
Attention, ceci pose problème lorsque tu veux faire quelque chose de portable. Sinon, ce n'est pas difficile en soi de récupérer à la main les octets un à un et les remettre en ordre sur une même machine.Citation:
Envoyé par Spootnik
Ué mais je vais faire simple. Je vais tout enregistrer avec le même boutisme (ça s'dit ça ? :aie: ) et lire en "mode tout ou rien" :) .
Si une structure est enregistré tel quel dans le fichier alors si il y aura un problème lors de la lecture octet par octet et de la recomposition du type.Citation:
Envoyé par Spootnik
Par contre, si les données ont elles-même été écrites octet par octet dans un format fixe et précisément défini alors effectivement il n'y aura pas de problème.
Mais on sort alors du cadre de la lecture d'un type quelconque dans un fichier pour arriver à de la vrai serialization/deserialization vers un format indépendant de la plate-forme. Ce qui est certes une bonne chose (surtout si le fichier est destiné à être échangé entre différentes plate-formes), mais ne correspond pas tout à fait à la même utilisation.
Effectivement mon but prochain est de faire de la serialization/deserialization, mais ce n'est plus tout à fait dans le cadre de la discussion :P .
Disons que cela concernera un autre module de ma bibliothèque. Pour l'instant je m'occupe juste de lire et écrire des données brutes dans des fichiers.