Discussion :

[zibzab]

Bonjour, je souhaiterai me déplacer dans un fichier txt se remplissant au fur et à mesure double par double sur 7 colonnes de doubles espacé de \t.

J'utilise pour le moment fsetpos et fgetpos avec des fpos_t et des fseek/ftellmais j'ai vu récemment je ne sais plus où que de mélanger les fseek et les fgetpos n'étaient pas bon. Je voudrais donc savoir comment unifier tout cela car j'effectue des remontées et des descente dans mon fichier danc les deux paires de fonctions me sont utiles...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
// fseek me permet essentiellement de remonter caractère par caractère depuis la fin, c'est essentiellement cela que je souhaiterai faire exclusivement en fgetpos / fsetpos ...
fseek(fic, -1, SEEK_END)...
 
// fgetpos et fsetpos me permettent de me placer à la fin des fseek
fgetpos(fic, &pos_a);

Voilà, je voulais donc savoir si j'avais le droit de marier les deux sans perdre en fiabilité? Si non comment faire tout en fgetpos/fsetpos qui est le seul portable selon le man..Merci d'avance

[Neckara]

Bonjour,

D'après le man, fseek et ftell sont de l'AINSI C (C89 si je ne m'abuse), ils sont donc bel et bien portables.

[zibzab]

Oui c'est ce que je me suis toujours dis mais là j'avais un besoin plus poussé des fonction de positionnement ce qui m'a permis de tomber sur ça :

http://www.cplusplus.com/reference/cstdio/ftell/


Il y a le petit commentaire //non portable à côté de la ligne qui correspond à l'utilisation de fseek que je souhaite faire. Est-ce que je me prends la t^te pour rien ou est-ce que cela a une importance?

[gangsoleil]

Bonjour,

fseek, ftell et fgetpos sont bien des fonctions standard, je ne vois pas en quoi ca ne serait pas portable...
De meme pour SEEK_CUR, SEEK_END et SEEK_SET....

Tout cela est par exemple present dans le paragraphe 7.19.9 de la norme C99.

[Bktero]

En allant sur la page dédiée à fseek(), on peut lire ceci http://www.cplusplus.com/reference/cstdio/fseek/

For streams open in text mode, offset shall either be zero or a value returned by a previous call to ftell, and origin shall necessarily be SEEK_SET.

If the function is called with other values for these arguments, support depends on the particular system and library implementation (non-portable).

Mon interprétation est que ce n'est donc pas fseek() qui n'est pas portable, mais l'utilisation de SEEK_END (d'après cette page sur fseek(), je rajouterais "dans un flux texte" mais d'après l'exemple de code de la page que tu cites, je dirais plutôt "quelque soit le mode du flux").

Ceci dit, la page de manuel ne dit rien sur une non portabilité : http://man.developpez.com/man3/fseek.3.php

http://www.gnu.org/software/libc/man...sitioning.html donne une précision :

Portability Note: In non-POSIX systems, ftell, ftello, fseek and fseeko might work reliably only on binary streams.

[Sve@r]

For streams open in text mode, offset shall either be zero or a value returned by a previous call to ftell, and origin shall necessarily be SEEK_SET.

If the function is called with other values for these arguments, support depends on the particular system and library implementation (non-portable).

Mon interprétation est que ce n'est donc pas fseek() qui n'est pas portable, mais l'utilisation de SEEK_END

Bien vu mais moi j'irais même jusqu'à dire que SEEK_CUR doit aussi être évité...

[Médinoc]

En effet: Avec SEEK_CUR et n'importe quel offset (positif ou négatif), même 1, la norme ne précise pas ce qui se passe en mode texte si on tombe sur un \r\n...

[zibzab]

Ouais donc son utilité reste limité si on ne peux utiliser que SEEK_SET avec les gros fichiers si tu veux aller à la fin depuis le début c'est un peu galère quoi. Car fgetpos et fsetpos ne font clairement pas tout. C'est bien la première fois que je suis aussi déçu d'une bibli standard...snif! En tout cas merci pour vos explications et interprétation ca m'a permis d'y voir plus clair. Merci

[Médinoc]

Si tu veux quelque chose qui fait le café, ouvre ton fichier en mode binaire et gère les fins de ligne toi-même: Tu pourras alors utiliser fseek() à son plein potentiel.
Ou bien, tu indexes le fichier, en le lisant une fois et en mémorisant les valeurs retournées par ftell() (ou fgetpos()) à chaque ligne par exemple.

[Bktero]

Bien vu mais moi j'irais même jusqu'à dire que SEEK_CUR doit aussi être évité...

Oui aussi. Je cherchais juste à analyser le commentaire "non-portable" du code dont parlait le PO

Pas bête l'idée de Médinoc de travailler en binaire.

[Sve@r]

Pas bête l'idée de Médinoc de travailler en binaire.

Moui je suis pas certain que ce soit aussi marvellous.
Parce qu'imagine le fichier texte contenant la ligne suivante:

azerty

Sous Unix, il sera écrit "azerty\n". Sous zindow (où tout le monde sait que pour eux simplicité égale performance), il sera écrit "azerty\r\n".

Ensuite tu ouvres le fichier en binaire => ok. Puis tu demandes un fseek(fp, -2, SEEK_END) puis tu fais un fgetc().
Ben sous Unix tu te retrouves à lire le 'y' mais sous zindow tu te retrouves à lire le '\r'...

C'est bien la première fois que je suis aussi déçu d'une bibli standard...snif!

Ben comme tu le vois, c'est pas vraiment la faute aux programmeurs de la bibli qui font ce qu'ils peuvent mais qui sont démunis face à certaines aberrations...

[Bktero]

Non ce n'est pas marvellous. De toute façon, je ne crois pas qu'il y est de solution marvellous à ce genre de problème, bien que je ne me sois jamais réellement penché sur le problème. Soit tu n'es pas portable, soit tu fais des codes un peu plus complexes. L'ouverture est en mode binaire est faite pour gérer explicitement les \r\n, pas pour faire un code aussi bête que celui que tu proposes, mais tu t'en doutais bien