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
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 ),
Peu importe qui t'as dit d'utiliser "t", c'est une erreur. La bonne chaine est "r+".
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?
Non. Si j'i bien compris, tu lis le fichier, tu modifies des valeurs en mémoire et tu le réécris entièrement, c'est ça ?
rewind() est probablement la bonne fonction pour 'revenir au début'.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
Miguel wrote on 14/05/05 :
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 ),
Peu importe qui t'as dit d'utiliser "t", c'est une erreur. La bonne
chaine est "r+".
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?
Non. Si j'i bien compris, tu lis le fichier, tu modifies des valeurs en
mémoire et tu le réécris entièrement, c'est ça ?
rewind() est probablement la bonne fonction pour 'revenir au début'.
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
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 ),
Peu importe qui t'as dit d'utiliser "t", c'est une erreur. La bonne chaine est "r+".
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?
Non. Si j'i bien compris, tu lis le fichier, tu modifies des valeurs en mémoire et tu le réécris entièrement, c'est ça ?
rewind() est probablement la bonne fonction pour 'revenir au début'.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
Miguel
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 ),
Peu importe qui t'as dit d'utiliser "t", c'est une erreur. La bonne chaine est "r+".
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?
Non. Si j'i bien compris, tu lis le fichier, tu modifies des valeurs en mémoire et tu le réécris entièrement, c'est ça ?
Pas tout à fait: j'ouvre le fichier en modification "r+" while (nécessaie) je me place là où il faut (toujours au même endroit) je modifie ce que je veux une autre application utilise le fichier puis se ferme /* l'autre appli est aussi de mon cru, mais il est important qu'elle soit différente */ je ferme le fichier et c'est fini
J'ai un code qui marche pour faire ca, mais en fait, j'aimerais gagner le plus de temps possible, et je pensais pouvoir le faire au niveau du repositionnemen, d'où ma question sur les FILE*... Voila j'espère que c'est plus clair et merci pour les conseils déjà tombés
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 ),
Peu importe qui t'as dit d'utiliser "t", c'est une erreur. La bonne chaine
est "r+".
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?
Non. Si j'i bien compris, tu lis le fichier, tu modifies des valeurs en
mémoire et tu le réécris entièrement, c'est ça ?
Pas tout à fait:
j'ouvre le fichier en modification "r+"
while (nécessaie)
je me place là où il faut (toujours au même endroit)
je modifie ce que je veux
une autre application utilise le fichier puis se ferme /* l'autre
appli est aussi de mon cru, mais il est important qu'elle soit différente */
je ferme le fichier
et c'est fini
J'ai un code qui marche pour faire ca, mais en fait, j'aimerais gagner le
plus de temps possible, et je pensais pouvoir le faire au niveau du
repositionnemen, d'où ma question sur les FILE*...
Voila j'espère que c'est plus clair et merci pour les conseils déjà tombés
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 ),
Peu importe qui t'as dit d'utiliser "t", c'est une erreur. La bonne chaine est "r+".
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?
Non. Si j'i bien compris, tu lis le fichier, tu modifies des valeurs en mémoire et tu le réécris entièrement, c'est ça ?
Pas tout à fait: j'ouvre le fichier en modification "r+" while (nécessaie) je me place là où il faut (toujours au même endroit) je modifie ce que je veux une autre application utilise le fichier puis se ferme /* l'autre appli est aussi de mon cru, mais il est important qu'elle soit différente */ je ferme le fichier et c'est fini
J'ai un code qui marche pour faire ca, mais en fait, j'aimerais gagner le plus de temps possible, et je pensais pouvoir le faire au niveau du repositionnemen, d'où ma question sur les FILE*... Voila j'espère que c'est plus clair et merci pour les conseils déjà tombés
cedric
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...
Pourquoi plus simple, et pourquoi plus sur ?
Par ailleurs, ce n'est pas équivalent. Un fichier ouvert avec r+ et même s'il est complètement réécrit sera toujours le même fichier, alors que si tu copie, ce n'est plus le même fichier. Or, il peut y avoir d'autres programmes qui lisent ce fichier...
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...
Pourquoi plus simple, et pourquoi plus sur ?
Par ailleurs, ce n'est pas équivalent. Un fichier ouvert avec r+ et même
s'il est complètement réécrit sera toujours le même fichier, alors que
si tu copie, ce n'est plus le même fichier. Or, il peut y avoir d'autres
programmes qui lisent ce fichier...
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...
Pourquoi plus simple, et pourquoi plus sur ?
Par ailleurs, ce n'est pas équivalent. Un fichier ouvert avec r+ et même s'il est complètement réécrit sera toujours le même fichier, alors que si tu copie, ce n'est plus le même fichier. Or, il peut y avoir d'autres programmes qui lisent ce fichier...
Emmanuel Delahaye
Miguel wrote on 14/05/05 :
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 ),
Peu importe qui t'as dit d'utiliser "t", c'est une erreur. La bonne chaine est "r+".
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?
Non. Si j'i bien compris, tu lis le fichier, tu modifies des valeurs en mémoire et tu le réécris entièrement, c'est ça ?
Pas tout à fait: j'ouvre le fichier en modification "r+" while (nécessaie) je me place là où il faut (toujours au même endroit) je modifie ce que je veux une autre application utilise le fichier puis se ferme /* l'autre appli est aussi de mon cru, mais il est important qu'elle soit différente */
Une application vien lire un fichier déjà ouvert ? C'est risqué. Est-tu sûr que ton ecriture est terminée (fflush()) ?
je ferme le fichier et c'est fini
J'ai un code qui marche pour faire ca, mais en fait, j'aimerais gagner le plus de temps possible, et je pensais pouvoir le faire au niveau du repositionnemen, d'où ma question sur les FILE*... Voila j'espère que c'est plus clair et merci pour les conseils déjà tombés
Il n'y a rien de plus rapide que fseek(). Mais je continue de penser que ta methode est douteuse et probablement pas portable sur un autre système...
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
I once asked an expert COBOL programmer, how to declare local variables in COBOL, the reply was: "what is a local variable?"
Miguel wrote on 14/05/05 :
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 ),
Peu importe qui t'as dit d'utiliser "t", c'est une erreur. La bonne chaine
est "r+".
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?
Non. Si j'i bien compris, tu lis le fichier, tu modifies des valeurs en
mémoire et tu le réécris entièrement, c'est ça ?
Pas tout à fait:
j'ouvre le fichier en modification "r+"
while (nécessaie)
je me place là où il faut (toujours au même endroit)
je modifie ce que je veux
une autre application utilise le fichier puis se ferme /* l'autre
appli est aussi de mon cru, mais il est important qu'elle soit différente */
Une application vien lire un fichier déjà ouvert ? C'est risqué. Est-tu
sûr que ton ecriture est terminée (fflush()) ?
je ferme le fichier
et c'est fini
J'ai un code qui marche pour faire ca, mais en fait, j'aimerais gagner le
plus de temps possible, et je pensais pouvoir le faire au niveau du
repositionnemen, d'où ma question sur les FILE*...
Voila j'espère que c'est plus clair et merci pour les conseils déjà tombés
Il n'y a rien de plus rapide que fseek(). Mais je continue de penser
que ta methode est douteuse et probablement pas portable sur un autre
système...
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
I once asked an expert COBOL programmer, how to
declare local variables in COBOL, the reply was:
"what is a local variable?"
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 ),
Peu importe qui t'as dit d'utiliser "t", c'est une erreur. La bonne chaine est "r+".
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?
Non. Si j'i bien compris, tu lis le fichier, tu modifies des valeurs en mémoire et tu le réécris entièrement, c'est ça ?
Pas tout à fait: j'ouvre le fichier en modification "r+" while (nécessaie) je me place là où il faut (toujours au même endroit) je modifie ce que je veux une autre application utilise le fichier puis se ferme /* l'autre appli est aussi de mon cru, mais il est important qu'elle soit différente */
Une application vien lire un fichier déjà ouvert ? C'est risqué. Est-tu sûr que ton ecriture est terminée (fflush()) ?
je ferme le fichier et c'est fini
J'ai un code qui marche pour faire ca, mais en fait, j'aimerais gagner le plus de temps possible, et je pensais pouvoir le faire au niveau du repositionnemen, d'où ma question sur les FILE*... Voila j'espère que c'est plus clair et merci pour les conseils déjà tombés
Il n'y a rien de plus rapide que fseek(). Mais je continue de penser que ta methode est douteuse et probablement pas portable sur un autre système...
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
I once asked an expert COBOL programmer, how to declare local variables in COBOL, the reply was: "what is a local variable?"
Miguel
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 ),
Peu importe qui t'as dit d'utiliser "t", c'est une erreur. La bonne chaine est "r+".
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?
Non. Si j'i bien compris, tu lis le fichier, tu modifies des valeurs en mémoire et tu le réécris entièrement, c'est ça ?
Pas tout à fait: j'ouvre le fichier en modification "r+" while (nécessaie) je me place là où il faut (toujours au même endroit) je modifie ce que je veux une autre application utilise le fichier puis se ferme /* l'autre appli est aussi de mon cru, mais il est important qu'elle soit différente */
Une application vien lire un fichier déjà ouvert ? C'est risqué. Est-tu sûr que ton ecriture est terminée (fflush()) ?
je ferme le fichier et c'est fini
J'ai un code qui marche pour faire ca, mais en fait, j'aimerais gagner le plus de temps possible, et je pensais pouvoir le faire au niveau du repositionnemen, d'où ma question sur les FILE*... Voila j'espère que c'est plus clair et merci pour les conseils déjà tombés
Il n'y a rien de plus rapide que fseek(). Mais je continue de penser que ta methode est douteuse et probablement pas portable sur un autre système...
Testée et approuvée sous Linux (avec fflush) dans un cas élémentaire (l'autre appli est à venir...)
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 ),
Peu importe qui t'as dit d'utiliser "t", c'est une erreur. La bonne
chaine est "r+".
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?
Non. Si j'i bien compris, tu lis le fichier, tu modifies des valeurs en
mémoire et tu le réécris entièrement, c'est ça ?
Pas tout à fait:
j'ouvre le fichier en modification "r+"
while (nécessaie)
je me place là où il faut (toujours au même endroit)
je modifie ce que je veux
une autre application utilise le fichier puis se ferme /* l'autre
appli est aussi de mon cru, mais il est important qu'elle soit différente
*/
Une application vien lire un fichier déjà ouvert ? C'est risqué. Est-tu
sûr que ton ecriture est terminée (fflush()) ?
je ferme le fichier
et c'est fini
J'ai un code qui marche pour faire ca, mais en fait, j'aimerais gagner le
plus de temps possible, et je pensais pouvoir le faire au niveau du
repositionnemen, d'où ma question sur les FILE*...
Voila j'espère que c'est plus clair et merci pour les conseils déjà
tombés
Il n'y a rien de plus rapide que fseek(). Mais je continue de penser que
ta methode est douteuse et probablement pas portable sur un autre
système...
Testée et approuvée sous Linux (avec fflush) dans un cas élémentaire
(l'autre appli est à venir...)
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 ),
Peu importe qui t'as dit d'utiliser "t", c'est une erreur. La bonne chaine est "r+".
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?
Non. Si j'i bien compris, tu lis le fichier, tu modifies des valeurs en mémoire et tu le réécris entièrement, c'est ça ?
Pas tout à fait: j'ouvre le fichier en modification "r+" while (nécessaie) je me place là où il faut (toujours au même endroit) je modifie ce que je veux une autre application utilise le fichier puis se ferme /* l'autre appli est aussi de mon cru, mais il est important qu'elle soit différente */
Une application vien lire un fichier déjà ouvert ? C'est risqué. Est-tu sûr que ton ecriture est terminée (fflush()) ?
je ferme le fichier et c'est fini
J'ai un code qui marche pour faire ca, mais en fait, j'aimerais gagner le plus de temps possible, et je pensais pouvoir le faire au niveau du repositionnemen, d'où ma question sur les FILE*... Voila j'espère que c'est plus clair et merci pour les conseils déjà tombés
Il n'y a rien de plus rapide que fseek(). Mais je continue de penser que ta methode est douteuse et probablement pas portable sur un autre système...
Testée et approuvée sous Linux (avec fflush) dans un cas élémentaire (l'autre appli est à venir...)
Targeur fou
Désolé pour la grammaire la valeur pointéE par un FILE* est-elle intéressante?
Que veux tu dire par là ? FILE est une structure et FILE * un pointeur (qui t'es donné directement par appel de fopen(), tmpfile() ou freopen() qui sont des fonction de la libc). Ce que te propose l'interface de la libc, c'est de manipuler des FILE *, pas des FILE. La valeur pointée par un FILE * est une structure interne qu'il serait dangereux de modifier. Il y a peut être des membres de FILE nommés ptr ou offset par exemple, mais qui va te dire que c'est le décalage par rapport au début du fichier ou le décalage par rapport au début du tampon de lecture/écriture utilisé.
Regis
Désolé pour la grammaire
la valeur pointéE par un FILE* est-elle intéressante?
Que veux tu dire par là ? FILE est une structure et FILE * un pointeur
(qui t'es donné directement par appel de fopen(), tmpfile() ou
freopen() qui sont des fonction de la libc). Ce que te propose
l'interface de la libc, c'est de manipuler des FILE *, pas des FILE. La
valeur pointée par un FILE * est une structure interne qu'il serait
dangereux de modifier. Il y a peut être des membres de FILE nommés
ptr ou offset par exemple, mais qui va te dire que c'est le décalage
par rapport au début du fichier ou le décalage par rapport au début
du tampon de lecture/écriture utilisé.
Désolé pour la grammaire la valeur pointéE par un FILE* est-elle intéressante?
Que veux tu dire par là ? FILE est une structure et FILE * un pointeur (qui t'es donné directement par appel de fopen(), tmpfile() ou freopen() qui sont des fonction de la libc). Ce que te propose l'interface de la libc, c'est de manipuler des FILE *, pas des FILE. La valeur pointée par un FILE * est une structure interne qu'il serait dangereux de modifier. Il y a peut être des membres de FILE nommés ptr ou offset par exemple, mais qui va te dire que c'est le décalage par rapport au début du fichier ou le décalage par rapport au début du tampon de lecture/écriture utilisé.
Regis
Antoine Leca
En <news:, Emmanuel Delahaye va escriure:
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.
D'accord.
Tu peux faire "r+".
En général, oui.
Il ne sert à rien.
Mmm, pas sûr. Sur plateformes MSDOS et cie, il xiste des options de compilations (qui font sortir de la stricte conformité à la norme) qui font que les fichiers sont ouverts par défaut en mode binaire, "b". Dans ce cadre-là, l'option "t" permet de forcer le mode texte, ce qui est parfois bien utile... De plus, je crois que la plupart des autres implémentations (lire Unix et cie) vont tranquillement ignorer ce "t" sans s'offusquer, et ouvrir le fichier en mode texte, donc avoir l'effet recherché.
Par contre, j'ai des doutes sur le '+'. Tu veux lire et écrire dans le même fichier en même temps ?
"r+" est la bonne option pour ouvrir un fichier existant en écriture. Même si cela ne saute pas forcément aux yeux.
Antoine
En <news:mn.73847d55de5b0f6e.15512@YOURBRAnoos.fr>,
Emmanuel Delahaye va escriure:
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.
D'accord.
Tu peux faire "r+".
En général, oui.
Il ne sert à rien.
Mmm, pas sûr.
Sur plateformes MSDOS et cie, il xiste des options de compilations (qui font
sortir de la stricte conformité à la norme) qui font que les fichiers sont
ouverts par défaut en mode binaire, "b". Dans ce cadre-là, l'option "t"
permet de forcer le mode texte, ce qui est parfois bien utile...
De plus, je crois que la plupart des autres implémentations (lire Unix et
cie) vont tranquillement ignorer ce "t" sans s'offusquer, et ouvrir le
fichier en mode texte, donc avoir l'effet recherché.
Par contre, j'ai des doutes sur le '+'. Tu veux lire et écrire dans le
même fichier en même temps ?
"r+" est la bonne option pour ouvrir un fichier existant en écriture. Même
si cela ne saute pas forcément aux yeux.
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.
D'accord.
Tu peux faire "r+".
En général, oui.
Il ne sert à rien.
Mmm, pas sûr. Sur plateformes MSDOS et cie, il xiste des options de compilations (qui font sortir de la stricte conformité à la norme) qui font que les fichiers sont ouverts par défaut en mode binaire, "b". Dans ce cadre-là, l'option "t" permet de forcer le mode texte, ce qui est parfois bien utile... De plus, je crois que la plupart des autres implémentations (lire Unix et cie) vont tranquillement ignorer ce "t" sans s'offusquer, et ouvrir le fichier en mode texte, donc avoir l'effet recherché.
Par contre, j'ai des doutes sur le '+'. Tu veux lire et écrire dans le même fichier en même temps ?
"r+" est la bonne option pour ouvrir un fichier existant en écriture. Même si cela ne saute pas forcément aux yeux.
Antoine
Antoine Leca
En <news:4285d4f3$0$23872$, Miguel va escriure:
la valeur pointéE par un FILE* est-elle intéressante?
Je ne sais pas si c'est la question, mais il faut savoir que parfois la valeur (l'adresse) du pointeur FILE* peut être signifiante; certaines implémentations ont du code qui lis une chaîne connue de structures FILE (par exemple pour fermer les fichiers à la fin du programme), et donc si tu déplace ailleurs la structure pointée, cela ne fonctionne plus.
Antoine
En <news:4285d4f3$0$23872$626a14ce@news.free.fr>, Miguel va escriure:
la valeur pointéE par un FILE* est-elle intéressante?
Je ne sais pas si c'est la question, mais il faut savoir que parfois la
valeur (l'adresse) du pointeur FILE* peut être signifiante; certaines
implémentations ont du code qui lis une chaîne connue de structures FILE
(par exemple pour fermer les fichiers à la fin du programme), et donc si tu
déplace ailleurs la structure pointée, cela ne fonctionne plus.
la valeur pointéE par un FILE* est-elle intéressante?
Je ne sais pas si c'est la question, mais il faut savoir que parfois la valeur (l'adresse) du pointeur FILE* peut être signifiante; certaines implémentations ont du code qui lis une chaîne connue de structures FILE (par exemple pour fermer les fichiers à la fin du programme), et donc si tu déplace ailleurs la structure pointée, cela ne fonctionne plus.
Antoine
kanze
Pierre Maurette wrote:
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 ?
Ce n'est pas garantie que malloc(sizeof(FILE)) compile. Le type FILE n'est pas forcement complet. (Je crois même qu'il peut être void, mais je ne suis pas sûr.)
Aussi, j'ai mes doutes quant à la légalité d'une expression du genre *unFile. Là non plus, je ne suis pas 100% sûr, mais je crois qu'une implémentation pourrait bien mettre des entiers arbitraires dedans, et non de véritables pointeurs. C-à-d donc que le code pourrait se compiler, mais provoquer un core lors de l'exécution.
(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.
Ici, pas forcement. Ce n'est pas parce que quelque chose d'indéfini fonctionne sur une implémentation qu'il fonctionne partout.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Pierre Maurette wrote:
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 ?
Ce n'est pas garantie que malloc(sizeof(FILE)) compile. Le type
FILE n'est pas forcement complet. (Je crois même qu'il peut être
void, mais je ne suis pas sûr.)
Aussi, j'ai mes doutes quant à la légalité d'une expression du
genre *unFile. Là non plus, je ne suis pas 100% sûr, mais je
crois qu'une implémentation pourrait bien mettre des entiers
arbitraires dedans, et non de véritables pointeurs. C-à-d donc
que le code pourrait se compiler, mais provoquer un core lors de
l'exécution.
(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.
Ici, pas forcement. Ce n'est pas parce que quelque chose
d'indéfini fonctionne sur une implémentation qu'il fonctionne
partout.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
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 ?
Ce n'est pas garantie que malloc(sizeof(FILE)) compile. Le type FILE n'est pas forcement complet. (Je crois même qu'il peut être void, mais je ne suis pas sûr.)
Aussi, j'ai mes doutes quant à la légalité d'une expression du genre *unFile. Là non plus, je ne suis pas 100% sûr, mais je crois qu'une implémentation pourrait bien mettre des entiers arbitraires dedans, et non de véritables pointeurs. C-à-d donc que le code pourrait se compiler, mais provoquer un core lors de l'exécution.
(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.
Ici, pas forcement. Ce n'est pas parce que quelque chose d'indéfini fonctionne sur une implémentation qu'il fonctionne partout.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Pierre Maurette
Pierre Maurette wrote:
[...]
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 ?
Ce n'est pas garantie que malloc(sizeof(FILE)) compile. Le type FILE n'est pas forcement complet. (Je crois même qu'il peut être void, mais je ne suis pas sûr.) Je posais la question de l'initialisation, puisque le code était
furieusement incomplet. Sinon, j'avais envisagé l'objet void, mais la possibilité d'un type incomplet m'avait échappé.
Aussi, j'ai mes doutes quant à la légalité d'une expression du genre *unFile. Là non plus, je ne suis pas 100% sûr, mais je crois qu'une implémentation pourrait bien mettre des entiers arbitraires dedans, et non de véritables pointeurs. C-à-d donc que le code pourrait se compiler, mais provoquer un core lors de l'exécution. Je ne sais pas ce qu'en dit la norme, mais effectivement je ne serais
pas choqué si une implémentation de fopen() était un wrapper d'un FOPEN de l'OS qui lui-même renverrait un handle. Ce handle serait simplement mis en bijection avec le pointeur FILE* renvoyé. C'est ce que je voulais dire par "la valeur du pointeur renvoyé joue un rôle de clé d'identification".
[...]
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.
Ici, pas forcement. Ce n'est pas parce que quelque chose d'indéfini fonctionne sur une implémentation qu'il fonctionne partout. Bien entendu. Néanmoins, les deux FILE* non initialisés, sans points de
suspensions, dans ce qui ressemble quand même à un listing, ça fait désordre. Et quand j'écris "des fois ça répond à la question", je veux dire que souvent, en isolant le minimum de code contenant le problème, on résoud le problème. Et puis c'est plus sympa, non ? Pour ceux qui comme moi s'amusent avec le code posté, ou d'autres qui le passent dans une quelconque moulinette.
-- Pierre
Pierre Maurette wrote:
[...]
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 ?
Ce n'est pas garantie que malloc(sizeof(FILE)) compile. Le type
FILE n'est pas forcement complet. (Je crois même qu'il peut être
void, mais je ne suis pas sûr.)
Je posais la question de l'initialisation, puisque le code était
furieusement incomplet.
Sinon, j'avais envisagé l'objet void, mais la possibilité d'un type
incomplet m'avait échappé.
Aussi, j'ai mes doutes quant à la légalité d'une expression du
genre *unFile. Là non plus, je ne suis pas 100% sûr, mais je
crois qu'une implémentation pourrait bien mettre des entiers
arbitraires dedans, et non de véritables pointeurs. C-à-d donc
que le code pourrait se compiler, mais provoquer un core lors de
l'exécution.
Je ne sais pas ce qu'en dit la norme, mais effectivement je ne serais
pas choqué si une implémentation de fopen() était un wrapper d'un FOPEN
de l'OS qui lui-même renverrait un handle. Ce handle serait simplement
mis en bijection avec le pointeur FILE* renvoyé. C'est ce que je
voulais dire par "la valeur du pointeur renvoyé joue un rôle de clé
d'identification".
[...]
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.
Ici, pas forcement. Ce n'est pas parce que quelque chose
d'indéfini fonctionne sur une implémentation qu'il fonctionne
partout.
Bien entendu. Néanmoins, les deux FILE* non initialisés, sans points de
suspensions, dans ce qui ressemble quand même à un listing, ça fait
désordre.
Et quand j'écris "des fois ça répond à la question", je veux dire que
souvent, en isolant le minimum de code contenant le problème, on résoud
le problème.
Et puis c'est plus sympa, non ? Pour ceux qui comme moi s'amusent avec
le code posté, ou d'autres qui le passent dans une quelconque
moulinette.
Comment les initialisez-vous ? Un fopen() pour le premier, le même ou un malloc(sizeof(FILE)) pour le second ?
Ce n'est pas garantie que malloc(sizeof(FILE)) compile. Le type FILE n'est pas forcement complet. (Je crois même qu'il peut être void, mais je ne suis pas sûr.) Je posais la question de l'initialisation, puisque le code était
furieusement incomplet. Sinon, j'avais envisagé l'objet void, mais la possibilité d'un type incomplet m'avait échappé.
Aussi, j'ai mes doutes quant à la légalité d'une expression du genre *unFile. Là non plus, je ne suis pas 100% sûr, mais je crois qu'une implémentation pourrait bien mettre des entiers arbitraires dedans, et non de véritables pointeurs. C-à-d donc que le code pourrait se compiler, mais provoquer un core lors de l'exécution. Je ne sais pas ce qu'en dit la norme, mais effectivement je ne serais
pas choqué si une implémentation de fopen() était un wrapper d'un FOPEN de l'OS qui lui-même renverrait un handle. Ce handle serait simplement mis en bijection avec le pointeur FILE* renvoyé. C'est ce que je voulais dire par "la valeur du pointeur renvoyé joue un rôle de clé d'identification".
[...]
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.
Ici, pas forcement. Ce n'est pas parce que quelque chose d'indéfini fonctionne sur une implémentation qu'il fonctionne partout. Bien entendu. Néanmoins, les deux FILE* non initialisés, sans points de
suspensions, dans ce qui ressemble quand même à un listing, ça fait désordre. Et quand j'écris "des fois ça répond à la question", je veux dire que souvent, en isolant le minimum de code contenant le problème, on résoud le problème. Et puis c'est plus sympa, non ? Pour ceux qui comme moi s'amusent avec le code posté, ou d'autres qui le passent dans une quelconque moulinette.
