OVH Cloud OVH Cloud

probleme de relecture de fichier

17 réponses
Avatar
ricky
bonjour

comme a mon habitude, je dois m'y prendre comme une tanche sur un
probleme particulier...

j ai defini une classe Fichier (ayant pour but de mettre le contenu d un
fichier dans un vector) qui contient en particulier :

void Fichier::ouvre(string nomFichier)
{
_codeRetour=OK;
_Ios_Openmode typeFichier=ios_base::in;
_fichier.open(nomFichier.c_str(),typeFichier);
stockageFichier();
_fichier.close();
}

void Fichier::stockageFichier()
{
// on balaye le fichier
string buffer;
if (_fichier.is_open())
while(!_fichier.eof()) // <== le gag est la :-P
{
getline(_fichier, buffer);
_cacheFichier.push_back(buffer);
}
else
_codeRetour=PB_FICHIER;
}

dans le main, je fais :
fichier.ouvre("./a.txt");

ok tout se passe bien, le _cacheFichier contient bien tout le contenu du
fichier...

mais si je fais
fichier.ouvre("./a.txt");
fichier.ouvre("./b.txt");

tout se passe bien pour le a.txt, par contre le _fichier.eof() est deja
positionne pour le "./b.txt" et les suivant, donc on ne rentre pas dans
le while !!!!!
Pourquoi le pointeur est il deja positionne en fin de fichier, alors que
j'ai bien fait un close apres la lectuyre du premier fichier, suivi d
'un open ????

merci si vous arrivez a me lire :-)

@+
ricky

10 réponses

1 2
Avatar
Loïc Joly
ricky wrote:

bonjour

comme a mon habitude, je dois m'y prendre comme une tanche sur un
probleme particulier...

j ai defini une classe Fichier (ayant pour but de mettre le contenu d un
fichier dans un vector) qui contient en particulier :

[...]


void Fichier::stockageFichier()
{
// on balaye le fichier
string buffer;
if (_fichier.is_open())
while(!_fichier.eof()) // <== le gag est la :-P
{
getline(_fichier, buffer);
_cacheFichier.push_back(buffer);
}


C'est pas comme ça qu'on lit, on dirait plutôt :

while (getline(_fichier, buffer))


[...]

mais si je fais
fichier.ouvre("./a.txt");
fichier.ouvre("./b.txt");

tout se passe bien pour le a.txt, par contre le _fichier.eof() est deja
positionne pour le "./b.txt" et les suivant, donc on ne rentre pas dans
le while !!!!!
Pourquoi le pointeur est il deja positionne en fin de fichier, alors que
j'ai bien fait un close apres la lectuyre du premier fichier, suivi d
'un open ????


Parce que close et open ne jouent par sur l'état d'erreur d'un fichier
(sinon, comment pourrais-tu détecter qu'un fichier s'est fermé
malproprement ?). Un _fichier.clear() devrait arranger ça (on encore
détruire et reconstruire _fichier.

--
Loïc

Avatar
Michel Michaud
Dans news:3fe4562b$0$19272$,
bonjour
if (_fichier.is_open())
while(!_fichier.eof()) // <== le gag est la :-P
{
getline(_fichier, buffer);


Ce n'est pas la bonne façon de lire le fichier au
complet. Remplace par while (getline(...)).

Mais ce n'est pas le problème majeur...

mais si je fais
fichier.ouvre("./a.txt");
fichier.ouvre("./b.txt");

tout se passe bien pour le a.txt, par contre le _fichier.eof() est
deja positionne pour le "./b.txt" et les suivant, donc on ne rentre
pas dans le while !!!!!


Il faut que tu fasses un clear() sur ton fichier, après le close()
pour enlever l'état eof().

Mais pourquoi as-tu mis le _fichier en membre au lieu d'en faire
une variable locale de la fonction qui l'utilise ?

(et les _ initiaux de tes membres, ce n'est pas un style très
apprécié...)

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Avatar
Fabien LE LEZ
On Sat, 20 Dec 2003 09:25:57 -0500, "Michel Michaud"
wrote:

(et les _ initiaux de tes membres, ce n'est pas un style très
apprécié...)


Mais bizarrement assez répandu, je ne sais pas bien pourquoi...

--
;-)

Avatar
ricky
bonjour

(et les _ initiaux de tes membres, ce n'est pas un style très
apprécié...)



Mais bizarrement assez répandu, je ne sais pas bien pourquoi...



La ou je travail, cela fait parti de la normalisation du developpement,
afin de voir au premier coup d'oeil ce qui est membre de ce qui ne l'est
pas...

En quoi cette notation est elle peu appreciee, et par quoi faudrait il
la remplacer ?

j'avoue ne pas comprendre cette reticence, les variables plus systeme
etant generalement precedees de 2 __, et les variables de tests de la
stl etant en majuscule, donc cette notation ne me semble par rentrer en
collision avec autre chose ???

@+
ricky


Avatar
ricky
bonjour

Ce n'est pas la bonne façon de lire le fichier au
complet. Remplace par while (getline(...)).


c est corrige :-)

Il faut que tu fasses un clear() sur ton fichier, après le close()
pour enlever l'état eof().


en effet, tout marche bcp mieux maintenant :-)

Mais pourquoi as-tu mis le _fichier en membre au lieu d'en faire
une variable locale de la fonction qui l'utilise ?


parceque ce n'est que le point de depart d'un projet plus complexe, qui
permettra par la suite de fournir un accesseur, des traitements ,
heritage etc...
bref qu'il s'agit d'une varibale qui fait vraiment parti des
caracteristiques de l'objet et non pas simplement d'une variable
intermediaire ...
enfin, c etait comme cela que je voyais la chose .... pour le moment :-)

(et les _ initiaux de tes membres, ce n'est pas un style très
apprécié...)


la j'ai du mal a voir pourquoi (est ce en rapport avec une norme, un
usage ou simplement une question de point de vue ?)...
De toute facon, cette forme m'est imposée, et jusqu a maintenant, je ne
la trouvait pas si mal ... peut etre ais je tort, mais je ne vois pas ou !

@+
ricky

Avatar
ricky
salut

while (getline(_fichier, buffer))


corrige

mais il y a une petite nuance : ma facon de faire (pas elegante, je suis
d acocrd avec ca) me permettait de "stocker" aussi les lignes vides,
alors que le getline mis comme ca ne les differencie pas d'une fin de
lecture :)

Parce que close et open ne jouent par sur l'état d'erreur d'un fichier
(sinon, comment pourrais-tu détecter qu'un fichier s'est fermé
malproprement ?). Un _fichier.clear() devrait arranger ça (on encore
détruire et reconstruire _fichier.


le clear a tout resolu... merci a toi :)

il est vrai que je pensais betement que le close detruisait _fichier (ou
plus exactement faisait disparaitre toute reference) et donc que je
n'avais plus de probleme apres ...

@+
ricky

Avatar
Gabriel Dos Reis
"Michel Michaud" writes:

| (et les _ initiaux de tes membres, ce n'est pas un style très
| apprécié...)

Par une certaine catégorie de la population.
Avatar
Michel Michaud
Dans news:3fe47520$0$17106$,
salut

while (getline(_fichier, buffer))


corrige

mais il y a une petite nuance : ma facon de faire (pas elegante, je
suis d acocrd avec ca) me permettait de "stocker" aussi les lignes
vides, alors que le getline mis comme ca ne les differencie pas
d'une fin de lecture :)


En fait, il est fort probable, au contraire, qu'avec la boucle
sur eof, tu lisais une fois de trop, quand il ne restait plus
rien que le getline ne donnait rien et que tu mettais ce rien
dans tes données...


--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/


Avatar
Loïc Joly
ricky wrote:

bonjour

(et les _ initiaux de tes membres, ce n'est pas un style très
apprécié...)




Mais bizarrement assez répandu, je ne sais pas bien pourquoi...



La ou je travail, cela fait parti de la normalisation du developpement,
afin de voir au premier coup d'oeil ce qui est membre de ce qui ne l'est
pas...

En quoi cette notation est elle peu appreciee, et par quoi faudrait il
la remplacer ?


La norme réserve certain noms de variable ue les implémenteur ont le
droit d'utiliser comme bon leur semble, mais pas les utilisateurs.
Ces nom sont ceux commencés par _ et suivis d'une majuscule, ou tous les
noms contenant __. Malheureusement, certaines implémentations utilisent
aussi des noms commençant par _ suivi d'une minuscule.

Si tu désire porter ton code sur une telle implémentation, tu risque
d'avoir des soucis (imagine par exemple qu'elle ait défini #define
_fichier 0).

Le désir de nommer les variables membre différemment existe souvent, et
jusqu'à présent, les trois formes que j'ai vu le plus souvent sont (dans
le désordre) :

m_variable
variable_
myVariable (ma préférée, car elle se lit bien à voix haute, n'a pas
besoin d'autre choses que des lettres pour être tappé, et se lit mieux
AMA à l'écran qu'un _)



j'avoue ne pas comprendre cette reticence, les variables plus systeme
etant generalement precedees de 2 __,


Là, ce n'est pas autorisé par la norme.

et les variables de tests de la
stl etant en majuscule, donc cette notation ne me semble par rentrer en
collision avec autre chose ???




Avatar
James Kanze
Fabien LE LEZ writes:

|> On Sat, 20 Dec 2003 09:25:57 -0500, "Michel Michaud"
|> wrote:

|> >(et les _ initiaux de tes membres, ce n'est pas un style très
|> >apprécié...)

|> Mais bizarrement assez répandu, je ne sais pas bien pourquoi...

Parce qu'on aime la risque ?

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
1 2