la valeur pointé par un FILE* est-elle intéressante?
23 réponses
Miguel
Bonjour,
Dans l'un de mes "programmes", j'écris dans un fichier toujours au même
endroit, toujours le même nombre de caractères (en utilisant
cstdio/stdio.h).
Pour ce faire, j'utilise fseek avant chaque nouvelle écriture.
J'aimerais savoir si il y a un moyen de contourner cet appel à fseek (dans
un souci de gain de temps) en utilisant par exemple la valeur pointée par
mon FILE* flux (donc en gros si *flux est une strucutre utilisable et si le
code
Dans l'un de mes "programmes", j'écris dans un fichier toujours au même endroit, toujours le même nombre de caractères (en utilisant cstdio/stdio.h). Pour ce faire, j'utilise fseek avant chaque nouvelle écriture.
Ah ? Si tu créées un nouveau fichier (effaces les anciennes données), tu n'as rien à faire d'autre que fopen() avec "w".
J'aimerais savoir si il y a un moyen de contourner cet appel à fseek (dans un souci de gain de temps)
Si tu en as réellement besoin, non.
en utilisant par exemple la valeur pointée par mon
FILE* flux (donc en gros si *flux est une strucutre utilisable et si le code
Non, pas du tout. Le pointeur FILE * est une adresse anonyme sur un bloc interne de gestion du fichier dont les détails ne sont ni spécifiés ni forcément accessibles[1].
------------------ [1] Dans <stdio.h>, il pourrait très bien y avoir un
typedef struct file FILE;
et le tour est joué.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
.sig under repair
Miguel wrote on 14/05/05 :
Dans l'un de mes "programmes", j'écris dans un fichier toujours au même
endroit, toujours le même nombre de caractères (en utilisant cstdio/stdio.h).
Pour ce faire, j'utilise fseek avant chaque nouvelle écriture.
Ah ? Si tu créées un nouveau fichier (effaces les anciennes données),
tu n'as rien à faire d'autre que fopen() avec "w".
J'aimerais savoir si il y a un moyen de contourner cet appel à fseek (dans un
souci de gain de temps)
Si tu en as réellement besoin, non.
en utilisant par exemple la valeur pointée par mon
FILE* flux (donc en gros si *flux est une strucutre utilisable et si le code
Non, pas du tout. Le pointeur FILE * est une adresse anonyme sur un
bloc interne de gestion du fichier dont les détails ne sont ni
spécifiés ni forcément accessibles[1].
------------------
[1] Dans <stdio.h>, il pourrait très bien y avoir un
typedef struct file FILE;
et le tour est joué.
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
Dans l'un de mes "programmes", j'écris dans un fichier toujours au même endroit, toujours le même nombre de caractères (en utilisant cstdio/stdio.h). Pour ce faire, j'utilise fseek avant chaque nouvelle écriture.
Ah ? Si tu créées un nouveau fichier (effaces les anciennes données), tu n'as rien à faire d'autre que fopen() avec "w".
J'aimerais savoir si il y a un moyen de contourner cet appel à fseek (dans un souci de gain de temps)
Si tu en as réellement besoin, non.
en utilisant par exemple la valeur pointée par mon
FILE* flux (donc en gros si *flux est une strucutre utilisable et si le code
Non, pas du tout. Le pointeur FILE * est une adresse anonyme sur un bloc interne de gestion du fichier dont les détails ne sont ni spécifiés ni forcément accessibles[1].
------------------ [1] Dans <stdio.h>, il pourrait très bien y avoir un
typedef struct file FILE;
et le tour est joué.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
.sig under repair
Miguel
Dans l'un de mes "programmes", j'écris dans un fichier toujours au même endroit, toujours le même nombre de caractères (en utilisant cstdio/stdio.h). Pour ce faire, j'utilise fseek avant chaque nouvelle écriture.
Ah ? Si tu créées un nouveau fichier (effaces les anciennes données), tu n'as rien à faire d'autre que fopen() avec "w". ouais, mais il n'y a pas que ce que je veux écrire dedans, je l'ouvre en
"r+t", je veux juste modifier 7 carctères.
J'aimerais savoir si il y a un moyen de contourner cet appel à fseek (dans un souci de gain de temps)
Si tu en as réellement besoin, non. Bon, bah tant pis alors... :'(
en utilisant par exemple la valeur pointée par mon FILE* flux (donc en gros si *flux est une strucutre utilisable et si le code
Non, pas du tout. Le pointeur FILE * est une adresse anonyme sur un bloc interne de gestion du fichier dont les détails ne sont ni spécifiés ni forcément accessibles[1].
------------------ [1] Dans <stdio.h>, il pourrait très bien y avoir un
typedef struct file FILE;
et le tour est joué.
Merci pour ces infos, je pensais qu'il y avait une norme précise sur la définition du FILE*...
Dans l'un de mes "programmes", j'écris dans un fichier toujours au même
endroit, toujours le même nombre de caractères (en utilisant
cstdio/stdio.h).
Pour ce faire, j'utilise fseek avant chaque nouvelle écriture.
Ah ? Si tu créées un nouveau fichier (effaces les anciennes données), tu
n'as rien à faire d'autre que fopen() avec "w".
ouais, mais il n'y a pas que ce que je veux écrire dedans, je l'ouvre en
"r+t", je veux juste modifier 7 carctères.
J'aimerais savoir si il y a un moyen de contourner cet appel à fseek
(dans un souci de gain de temps)
Si tu en as réellement besoin, non.
Bon, bah tant pis alors... :'(
en utilisant par exemple la valeur pointée par mon
FILE* flux (donc en gros si *flux est une strucutre utilisable et si le
code
Non, pas du tout. Le pointeur FILE * est une adresse anonyme sur un bloc
interne de gestion du fichier dont les détails ne sont ni spécifiés ni
forcément accessibles[1].
------------------
[1] Dans <stdio.h>, il pourrait très bien y avoir un
typedef struct file FILE;
et le tour est joué.
Merci pour ces infos, je pensais qu'il y avait une norme précise sur la
définition du FILE*...
Dans l'un de mes "programmes", j'écris dans un fichier toujours au même endroit, toujours le même nombre de caractères (en utilisant cstdio/stdio.h). Pour ce faire, j'utilise fseek avant chaque nouvelle écriture.
Ah ? Si tu créées un nouveau fichier (effaces les anciennes données), tu n'as rien à faire d'autre que fopen() avec "w". ouais, mais il n'y a pas que ce que je veux écrire dedans, je l'ouvre en
"r+t", je veux juste modifier 7 carctères.
J'aimerais savoir si il y a un moyen de contourner cet appel à fseek (dans un souci de gain de temps)
Si tu en as réellement besoin, non. Bon, bah tant pis alors... :'(
en utilisant par exemple la valeur pointée par mon FILE* flux (donc en gros si *flux est une strucutre utilisable et si le code
Non, pas du tout. Le pointeur FILE * est une adresse anonyme sur un bloc interne de gestion du fichier dont les détails ne sont ni spécifiés ni forcément accessibles[1].
------------------ [1] Dans <stdio.h>, il pourrait très bien y avoir un
typedef struct file FILE;
et le tour est joué.
Merci pour ces infos, je pensais qu'il y avait une norme précise sur la définition du FILE*...
Miguel
Désolé pour la grammaire la valeur pointéE par un FILE* est-elle intéressante?
Désolé pour la grammaire
la valeur pointéE par un FILE* est-elle intéressante?
ouais, mais il n'y a pas que ce que je veux écrire dedans, je l'ouvre en "r+t", je veux juste modifier 7 carctères.
"r+t" ???
++
Pierre Maurette
Bonjour, Dans l'un de mes "programmes", j'écris dans un fichier toujours au même endroit, toujours le même nombre de caractères (en utilisant cstdio/stdio.h). Pour ce faire, j'utilise fseek avant chaque nouvelle écriture. J'aimerais savoir si il y a un moyen de contourner cet appel à fseek (dans un souci de gain de temps) en utilisant par exemple la valeur pointée par mon FILE* flux (donc en gros si *flux est une strucutre utilisable et si le code
FILE *flux_orig; FILE *flux_dest; Comment les initialisez-vous ? Un fopen() pour le premier, le même ou
un malloc(sizeof(FILE)) pour le second ?
fseek(flux_orig, là_où_je_veux, SEEK_SET); *flux_dest = *flux_orig; ou
memcpy(flux_dest, flux_orig, sizeof(FILE));
(flux_dest, "ce que je veux écrire"); manque un fprintf, non ?
J'imagine que vous êtes étudiant et n'avez pas de machine à disposition. Sinon, postez du code compilable, c'est mieux et des fois ça répond à la question.
va d'abord m'écrire "ce que je veux écrire" là où je veux, puis réécrire par dessus "quelquechose d'autre")?
(Attention, réponse sans conviction ni certitude, mais comme c'est le week-end...) Sans parler du danger qu'il y a à chercher à piéger le sysytème, votre truc ne peut pas fonctionner à mon avis. Un point de la norme: <$7.19.3.6> The address of the FILE object used to control a stream may be significant; a copy of a FILE object need not serve in place of the original. </$7.19.3.6> Ça veut dire que, comme pour le couple malloc()/free(), la valeur du pointeur renvoyé joue un rôle de clé d'identification. Par exemple si vous laissez mourrir dans une fonction un pointeur renvoyé par malloc() ou fopen(), vous ne pouvez plus faire free() ou fclose(). Rien ne dit que l'état du fichier est entièrement contenu dans l'objet FILE. Cet objet (petit sur ma machine, il fait 24 char) peut très bien ne pas contenir la position courante, celle-ci étant connue au travers de la valeur du FILE*. Voyez plutôt les fonctions fgetpos() et fsetpos(). Encore que je ne pense pas qu'un appel à fseek() soit si coûteux que ça, surtout le second et les suivants ...
-- Pierre
Bonjour,
Dans l'un de mes "programmes", j'écris dans un fichier toujours au même
endroit, toujours le même nombre de caractères (en utilisant cstdio/stdio.h).
Pour ce faire, j'utilise fseek avant chaque nouvelle écriture.
J'aimerais savoir si il y a un moyen de contourner cet appel à fseek (dans un
souci de gain de temps) en utilisant par exemple la valeur pointée par mon
FILE* flux (donc en gros si *flux est une strucutre utilisable et si le code
FILE *flux_orig;
FILE *flux_dest;
Comment les initialisez-vous ? Un fopen() pour le premier, le même ou
un malloc(sizeof(FILE)) pour le second ?
fseek(flux_orig, là_où_je_veux, SEEK_SET);
*flux_dest = *flux_orig;
ou
memcpy(flux_dest, flux_orig, sizeof(FILE));
(flux_dest, "ce que je veux écrire");
manque un fprintf, non ?
J'imagine que vous êtes étudiant et n'avez pas de machine à
disposition. Sinon, postez du code compilable, c'est mieux et des fois
ça répond à la question.
va d'abord m'écrire "ce que je veux écrire" là où je veux, puis réécrire par
dessus "quelquechose d'autre")?
(Attention, réponse sans conviction ni certitude, mais comme c'est le
week-end...)
Sans parler du danger qu'il y a à chercher à piéger le sysytème, votre
truc ne peut pas fonctionner à mon avis.
Un point de la norme:
<$7.19.3.6>
The address of the FILE object used to control a stream may be
significant; a copy of a FILE object need not serve in place of the
original.
</$7.19.3.6>
Ça veut dire que, comme pour le couple malloc()/free(), la valeur du
pointeur renvoyé joue un rôle de clé d'identification. Par exemple si
vous laissez mourrir dans une fonction un pointeur renvoyé par malloc()
ou fopen(), vous ne pouvez plus faire free() ou fclose().
Rien ne dit que l'état du fichier est entièrement contenu dans l'objet
FILE. Cet objet (petit sur ma machine, il fait 24 char) peut très bien
ne pas contenir la position courante, celle-ci étant connue au travers
de la valeur du FILE*.
Voyez plutôt les fonctions fgetpos() et fsetpos(). Encore que je ne
pense pas qu'un appel à fseek() soit si coûteux que ça, surtout le
second et les suivants ...
Bonjour, Dans l'un de mes "programmes", j'écris dans un fichier toujours au même endroit, toujours le même nombre de caractères (en utilisant cstdio/stdio.h). Pour ce faire, j'utilise fseek avant chaque nouvelle écriture. J'aimerais savoir si il y a un moyen de contourner cet appel à fseek (dans un souci de gain de temps) en utilisant par exemple la valeur pointée par mon FILE* flux (donc en gros si *flux est une strucutre utilisable et si le code
FILE *flux_orig; FILE *flux_dest; Comment les initialisez-vous ? Un fopen() pour le premier, le même ou
un malloc(sizeof(FILE)) pour le second ?
fseek(flux_orig, là_où_je_veux, SEEK_SET); *flux_dest = *flux_orig; ou
memcpy(flux_dest, flux_orig, sizeof(FILE));
(flux_dest, "ce que je veux écrire"); manque un fprintf, non ?
J'imagine que vous êtes étudiant et n'avez pas de machine à disposition. Sinon, postez du code compilable, c'est mieux et des fois ça répond à la question.
va d'abord m'écrire "ce que je veux écrire" là où je veux, puis réécrire par dessus "quelquechose d'autre")?
(Attention, réponse sans conviction ni certitude, mais comme c'est le week-end...) Sans parler du danger qu'il y a à chercher à piéger le sysytème, votre truc ne peut pas fonctionner à mon avis. Un point de la norme: <$7.19.3.6> The address of the FILE object used to control a stream may be significant; a copy of a FILE object need not serve in place of the original. </$7.19.3.6> Ça veut dire que, comme pour le couple malloc()/free(), la valeur du pointeur renvoyé joue un rôle de clé d'identification. Par exemple si vous laissez mourrir dans une fonction un pointeur renvoyé par malloc() ou fopen(), vous ne pouvez plus faire free() ou fclose(). Rien ne dit que l'état du fichier est entièrement contenu dans l'objet FILE. Cet objet (petit sur ma machine, il fait 24 char) peut très bien ne pas contenir la position courante, celle-ci étant connue au travers de la valeur du FILE*. Voyez plutôt les fonctions fgetpos() et fsetpos(). Encore que je ne pense pas qu'un appel à fseek() soit si coûteux que ça, surtout le second et les suivants ...
-- Pierre
Miguel
ouais, mais il n'y a pas que ce que je veux écrire dedans, je l'ouvre en "r+t", je veux juste modifier 7 carctères.
"r+t" ??? ouais, comme "r+" pour modification et "t" pour text ;-)
++
ouais, mais il n'y a pas que ce que je veux écrire dedans, je l'ouvre en
"r+t", je veux juste modifier 7 carctères.
"r+t" ???
ouais, comme "r+" pour modification et "t" pour text ;-)
ouais, mais il n'y a pas que ce que je veux écrire dedans, je l'ouvre en "r+t", je veux juste modifier 7 carctères.
"r+t" ??? ouais, comme "r+" pour modification et "t" pour text ;-)
++
Emmanuel Delahaye
Miguel wrote on 14/05/05 :
ouais, mais il n'y a pas que ce que je veux écrire dedans, je l'ouvre en "r+t", je veux juste modifier 7 carctères.
"r+t" ??? ouais, comme "r+" pour modification et "t" pour text ;-)
++
Le 't' n'est pas défin par la norme. Il ne sert à rien. Tu peux faire "r+".
Par contre, j'ai des doutes sur le '+'. Tu veux lire et écrire dans le même fichier en même temps ? Ca se traduit généralement par une destruction du fichier. Il est plus simple et plus sur d'utilise 2 fichier source (un "r", un "w"), et de faire une une copie selective...
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
.sig under repair
Miguel wrote on 14/05/05 :
ouais, mais il n'y a pas que ce que je veux écrire dedans, je l'ouvre en
"r+t", je veux juste modifier 7 carctères.
"r+t" ???
ouais, comme "r+" pour modification et "t" pour text ;-)
++
Le 't' n'est pas défin par la norme. Il ne sert à rien. Tu peux faire
"r+".
Par contre, j'ai des doutes sur le '+'. Tu veux lire et écrire dans le
même fichier en même temps ? Ca se traduit généralement par une
destruction du fichier. Il est plus simple et plus sur d'utilise 2
fichier source (un "r", un "w"), et de faire une une copie selective...
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
ouais, mais il n'y a pas que ce que je veux écrire dedans, je l'ouvre en "r+t", je veux juste modifier 7 carctères.
"r+t" ??? ouais, comme "r+" pour modification et "t" pour text ;-)
++
Le 't' n'est pas défin par la norme. Il ne sert à rien. Tu peux faire "r+".
Par contre, j'ai des doutes sur le '+'. Tu veux lire et écrire dans le même fichier en même temps ? Ca se traduit généralement par une destruction du fichier. Il est plus simple et plus sur d'utilise 2 fichier source (un "r", un "w"), et de faire une une copie selective...
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
.sig under repair
Hamiral
Emmanuel Delahaye wrote:
Par contre, j'ai des doutes sur le '+'. Tu veux lire et écrire dans le même fichier en même temps ? Ca se traduit généralement par une destruction du fichier. Il est plus simple et plus sur d'utilise 2 fichier source (un "r", un "w"), et de faire une une copie selective...
Si le fichier n'est pas trop gros, autant tout charger en mémoire, faire les traitements dessus puis écraser le fichier ensuite. En plus, le souci principal de l'OP étant la performance, c'est probablement une meilleure solution. Non ?
Bon, évidemment, suivant les systèmes, la taille du fichier, toussa ... Ça peut être possible ou pas ...
-- Hamiral
Emmanuel Delahaye wrote:
Par contre, j'ai des doutes sur le '+'. Tu veux lire et écrire dans le
même fichier en même temps ? Ca se traduit généralement par une
destruction du fichier. Il est plus simple et plus sur d'utilise 2
fichier source (un "r", un "w"), et de faire une une copie selective...
Si le fichier n'est pas trop gros, autant tout charger en mémoire, faire les
traitements dessus puis écraser le fichier ensuite. En plus, le souci
principal de l'OP étant la performance, c'est probablement une meilleure
solution. Non ?
Bon, évidemment, suivant les systèmes, la taille du fichier, toussa ... Ça
peut être possible ou pas ...
Par contre, j'ai des doutes sur le '+'. Tu veux lire et écrire dans le même fichier en même temps ? Ca se traduit généralement par une destruction du fichier. Il est plus simple et plus sur d'utilise 2 fichier source (un "r", un "w"), et de faire une une copie selective...
Si le fichier n'est pas trop gros, autant tout charger en mémoire, faire les traitements dessus puis écraser le fichier ensuite. En plus, le souci principal de l'OP étant la performance, c'est probablement une meilleure solution. Non ?
Bon, évidemment, suivant les systèmes, la taille du fichier, toussa ... Ça peut être possible ou pas ...
-- Hamiral
Miguel
Par contre, j'ai des doutes sur le '+'. Tu veux lire et écrire dans le même fichier en même temps ? Ca se traduit généralement par une destruction du fichier. Il est plus simple et plus sur d'utilise 2 fichier source (un "r", un "w"), et de faire une une copie selective...
Si le fichier n'est pas trop gros, autant tout charger en mémoire, faire les traitements dessus puis écraser le fichier ensuite. En plus, le souci principal de l'OP étant la performance, c'est probablement une meilleure solution. Non ?
Bon, évidemment, suivant les systèmes, la taille du fichier, toussa ... Ça peut être possible ou pas ...
Mon "r+t" marche à merveille comme je veux(au passage, c'est un type d'ouverture donné pour exemple de la fonction fopen sur le site www.cplusplus.com ), mon fichier fait 83 caractères. Est-ce que l'écrasement du fichier est un réel gain de temps par rapport au repositionnement du flux?
Par contre, j'ai des doutes sur le '+'. Tu veux lire et écrire dans le
même fichier en même temps ? Ca se traduit généralement par une
destruction du fichier. Il est plus simple et plus sur d'utilise 2
fichier source (un "r", un "w"), et de faire une une copie selective...
Si le fichier n'est pas trop gros, autant tout charger en mémoire, faire
les
traitements dessus puis écraser le fichier ensuite. En plus, le souci
principal de l'OP étant la performance, c'est probablement une meilleure
solution. Non ?
Bon, évidemment, suivant les systèmes, la taille du fichier, toussa ... Ça
peut être possible ou pas ...
Mon "r+t" marche à merveille comme je veux(au passage, c'est un type
d'ouverture donné pour exemple de la fonction fopen sur le site
www.cplusplus.com ), mon fichier fait 83 caractères.
Est-ce que l'écrasement du fichier est un réel gain de temps par rapport au
repositionnement du flux?
Par contre, j'ai des doutes sur le '+'. Tu veux lire et écrire dans le même fichier en même temps ? Ca se traduit généralement par une destruction du fichier. Il est plus simple et plus sur d'utilise 2 fichier source (un "r", un "w"), et de faire une une copie selective...
Si le fichier n'est pas trop gros, autant tout charger en mémoire, faire les traitements dessus puis écraser le fichier ensuite. En plus, le souci principal de l'OP étant la performance, c'est probablement une meilleure solution. Non ?
Bon, évidemment, suivant les systèmes, la taille du fichier, toussa ... Ça peut être possible ou pas ...
Mon "r+t" marche à merveille comme je veux(au passage, c'est un type d'ouverture donné pour exemple de la fonction fopen sur le site www.cplusplus.com ), mon fichier fait 83 caractères. Est-ce que l'écrasement du fichier est un réel gain de temps par rapport au repositionnement du flux?
