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 ????
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
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.
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
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/
Dans news:3fe4562b$0$19272$626a54ce@news.free.fr,
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 mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
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/
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...
-- ;-)
On Sat, 20 Dec 2003 09:25:57 -0500, "Michel Michaud" <mm@gdzid.com>
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...
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...
-- ;-)
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
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 ???
(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
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
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 !
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
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
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 ...
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
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.
"Michel Michaud" <mm@gdzid.com> writes:
| (et les _ initiaux de tes membres, ce n'est pas un style très
| apprécié...)
| (et les _ initiaux de tes membres, ce n'est pas un style très | apprécié...)
Par une certaine catégorie de la population.
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/
Dans news:3fe47520$0$17106$626a54ce@news.free.fr,
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 mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
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/
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 ???
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 ???
(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 ???
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
Fabien LE LEZ <gramster@gramster.com> writes:
|> On Sat, 20 Dec 2003 09:25:57 -0500, "Michel Michaud" <mm@gdzid.com>
|> 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:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> 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