Bonjour à tous,

j'ai besoin de remplacer un certain nombre d'octets à la fin d'un
fichier. Comment procéderiez-vous? Faut-il utiliser un ofstream? Un
ifstream?

Merci pour votre aide.

Guillaume GOURDIN <trash@hotmail.com> writes:

> Bonjour à tous,
>
> j'ai besoin de remplacer un certain nombre d'octets à la fin d'un
> fichier. Comment procéderiez-vous? Faut-il utiliser un ofstream? Un
> ifstream?
>
> Merci pour votre aide.

J'essayerai comme ça:

ofstream fout(path,ios::app);
fout.seekp(certain_nombre,ios::end);
fout.put(octet);
fout.close();

--
__Pascal Bourguignon__

Pascal J. Bourguignon a écrit :
> Guillaume GOURDIN <trash@hotmail.com> writes:
>
>> Bonjour à tous,
>>
>> j'ai besoin de remplacer un certain nombre d'octets à la fin d'un
>> fichier. Comment procéderiez-vous? Faut-il utiliser un ofstream? Un
>> ifstream?
>>
>> Merci pour votre aide.
>
> J'essayerai comme ça:
>
> ofstream fout(path,ios::app);
> fout.seekp(certain_nombre,ios::end);
> fout.put(octet);
> fout.close();

A noter, qu'il n'y a pas de moyen de tronquer un fichier en C++ .Donc il
faut ré-écrire tous les octets à remplacer.

Michael

Michael DOUBEZ <michael.doubez@free.fr> writes:

> Pascal J. Bourguignon a écrit :
>> Guillaume GOURDIN <trash@hotmail.com> writes:
>>
>>> Bonjour à tous,
>>>
>>> j'ai besoin de remplacer un certain nombre d'octets à la fin d'un
>>> fichier. Comment procéderiez-vous? Faut-il utiliser un ofstream? Un
>>> ifstream?
>>>
>>> Merci pour votre aide.
>> J'essayerai comme ça:
>> ofstream fout(path,ios::app);
>> fout.seekp(certain_nombre,ios::end);
>> fout.put(octet);
>> fout.close();
>
> A noter, qu'il n'y a pas de moyen de tronquer un fichier en C++ .Donc
> il faut ré-écrire tous les octets à remplacer.

On peut toujours appeler ::truncate, sur un système POSIX avec extension XSI.

--
__Pascal Bourguignon__

> ofstream fout(path,ios::app);

Pourquoi 'ios::app'? Je n'ajoute pas des octets, mais je les remplace.

Merci.

Guillaume GOURDIN <trash@hotmail.com> writes:

>> ofstream fout(path,ios::app);
>
> Pourquoi 'ios::app'? Je n'ajoute pas des octets, mais je les remplace.

Pour se positionner dès l'ouverture en fin de fichier, en supposant
qu'un certain nombre est assez petit.. Mais un ios:ut irait aussi
bien, je suppose.

--
__Pascal Bourguignon__

On Apr 7, 2:08 pm, Guillaume GOURDIN <tr...@hotmail.com> wrote:

> j'ai besoin de remplacer un certain nombre d'octets à la fin
> d'un fichier. Comment procéderiez-vous? Faut-il utiliser un
> ofstream? Un ifstream?

La plupart du temps, dans de tels cas, j'utilise carrément
l'interface Posix, avec des ostringstream pour formatter. Mais
je n'ai pas besoin de portabilité (du moment que le code marche
et sous Solaris et sous Linux), et j'ai besoins des écritures
synchronisées. On peut bien le faire avec un fstream, en prenant
des précautions nécessaires.

Plusieurs points importants :

-- L'ouverture en écriture seulement vide toujours le fichier,
s'il existe déjà. Il faut absolument ouvrir en
bidirectionnel, si tu veux y écrire, mais tu ne veux pas
détruire tout le contenu précédant.

-- Si tu veux utiliser seek pour aller à un endroit arbitraire,
il faut ouvrir en mode binaire ; sinon, tu n'as droit à
seeker qu'au deux bouts ou à un endroit où tu as fait un
tell.

-- Enfin, tu ne peux changer la taille du fichier qu'en
ajoutant des octets à la fin. Si tu veux remplacer un
enrégistrement dans le fichier, il faut que la taille du
remplacement soit identique à la taille de ce que tu
remplaces.

Donc, en supposant que tu saches déjà exactement où tu veux
écrire, le code devient quelque chose comme :

std:fstream dest(
name, std::ios::in | std::ios:ut | std::ios::binary ) ;
dest.seekp( position, std::ios::beg ) ;
// Sorties vers dest, en prenant bien soin du nombre
// des octets générés.

Note que ce dernier point argue fort en faveur de l'utilisation
d'un std:stringstream pour le formattage, afin de pouvoir
contrôle très exactement le nombre d'octets écrits (avec par
exemple dest.write, plutôt que des opérateurs <<).

--
James Kanze (GABI Software) email:james.kanze@gmail.com
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

> -- L'ouverture en écriture seulement vide toujours le fichier,
> s'il existe déjà. Il faut absolument ouvrir en
> bidirectionnel, si tu veux y écrire, mais tu ne veux pas
> détruire tout le contenu précédant.

Effectivement, c'set que j'ai fait en premier et je ne comprenais pas
pourquoi mon fichier était systématiquement vidé.

> -- Si tu veux utiliser seek pour aller à un endroit arbitraire,
> il faut ouvrir en mode binaire ; sinon, tu n'as droit à
> seeker qu'au deux bouts ou à un endroit où tu as fait un
> tell.

Ah bon? En fait, ce que j'ai fait, c'est utilisé un fstream, que j'ouvre
avec les flags par défaut (in et out, et il me semble que le mode
binaire n'est pas activé) et j'arrive à faire des seek. Le code exact
ressemble à ça :

fstream file;
file.open( filename );
file.seekp( -count-4, ios_base::end );

file.put( 1 );
file.put( 2 );
file.put( 3 );
...

> Donc, en supposant que tu saches déjà exactement où tu veux
> écrire, le code devient quelque chose comme :
>
> std:fstream dest(
> name, std::ios::in | std::ios:ut | std::ios::binary ) ;
> dest.seekp( position, std::ios::beg ) ;
> // Sorties vers dest, en prenant bien soin du nombre
> // des octets générés.

Ici quelle est la signification précise de 'std::ios::in'? Que l'on va
faire des seek? Qu'il ne fait pas effacer le contenu du fichier?

Merci beaucoup.

On Apr 8, 11:22 am, Guillaume GOURDIN <tr...@hotmail.com> wrote:
> > -- Si tu veux utiliser seek pour aller à un endroit arbitraire,
> > il faut ouvrir en mode binaire ; sinon, tu n'as droit à
> > seeker qu'au deux bouts ou à un endroit où tu as fait un
> > tell.

> Ah bon? En fait, ce que j'ai fait, c'est utilisé un fstream,
> que j'ouvre avec les flags par défaut (in et out, et il me
> semble que le mode binaire n'est pas activé) et j'arrive à
> faire des seek.

C'est un comportement indéfini ; l'implémentation n'est pas
obligé à signaler l'erreur, et peut bien même définir le
comportement. Dans les fait, le flags binary est un no-op sous
les Unix, et les seek marchent. Sous Windows, un seek dans un
fichier texte ne provoque pas d'erreur, mais ne va pas forcément
où tu veux.

> Le code exact
> ressemble à ça :

> fstream file;
> file.open( filename );
> file.seekp( -count-4, ios_base::end );

> file.put( 1 );
> file.put( 2 );
> file.put( 3 );
> ...

> > Donc, en supposant que tu saches déjà exactement où tu veux
> > écrire, le code devient quelque chose comme :

> > std:fstream dest(
> > name, std::ios::in | std::ios:ut | std::ios::binary ) ;
> > dest.seekp( position, std::ios::beg ) ;
> > // Sorties vers dest, en prenant bien soin du nombre
> > // des octets générés.

> Ici quelle est la signification précise de 'std::ios::in'? Que
> l'on va faire des seek? Qu'il ne fait pas effacer le contenu
> du fichier?

Exacte. Aussi, il permet en principe la lecture. Seulement, dans
l'interface de ofstream, il n'y a pas de fonction pour lire ;
il faudrait donc récupérer le streambuf, et lire à travers lui.

Pour être plus précis (mais ça ne change rien à ton cas) : les
flags d'ouverture n'ont aucun effet sur le ifstream, ofstream ou
fstream, qui ne fait que les passer au filebuf. Que le flux même
soit considérer en entrée, en sortie ou bi-directionnel dépend
uniquement de son type (ifstream, ofstream ou fstream), et non
des flags passés lors de la création ou l'ouverture. Il n'y a
qu'un seul filebuf, en revanche, qui supporte toujours et les
entrées et les sorties au niveau d'interface, quitte à renvoyer
une erreur si tu essaies quelque chose non conforme aux flags
d'ouverture. Du coup, il est même possible (mais sans le moindre
intérêt) à connecter un filebuf ouverte uniquement pour
l'écriture à un istream.

Pour des raisons historiques, il s'avère en plus que l'ouverture
en écriture seulement tronque toujours, même si le flag
ios::trunc n'est pas positionné. C-à-d : ios:ut, ios:ut |
ios::trunc, et ios::in | ios:ut | ios::trunc vident tous le
fichier ; il faut bien ios::in | ios:ut (sans ios::trunc)
pour ne pas le vider. Ce n'est pas trop logique, mais c'est
comme ça. (Note que le fopen de C n'est pas plus logique.
Normalement, c'est "r" pour lire, et "w" pour écrire. Ajoute un
"+", et ça devient bidirectionnel, avec "r+" pour ne pas vider,
et "w+" pour vider.)

En gros, on peut dire que dans les deux cas (C et C++), le
composant a été conçu pour lire ou écrire un flux de texte
séquentiellement, avec l'écriture toujours vers un fichier neuf,
et que les autres fonctionnalités sont venues s'y ajouter d'une
façon plus ou moins ad hoc, et pas toujours très propre.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
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