Discussion :

[Farks]

Bonjour,

j'utilise:
- Windows XP SP2
- Visual c++ 2005 Express Edition SP1

Mon programme fonctionne parfaitement quand j'utilise: g++ 3.4.4.
(Autant sous linux que sous windows)

Le programme parcours le fichier et annalyse le texte.
J'ai commenc� avec une lecture caract�re par caract�re et je constate que de temps � autre, j'ai besoin de lire des lignes.
�a ne pose pas de probl�me sur de tr�s petit fichier ( < 4'096 caract�res)

Maintenant que mon parser est quasi fini, je constate que j'ai un soucis de temps en temps au moment o� je dois revenir en arri�re sur des fichiers plus grand que 4'096 caract�res.


Ce qui se passe:
avec le debugger, j'ai pu constater que le fichier est parcourus par bloque de 4'096 caract�res.
Le programme d�passe se bloque de 4'096 en appelant la fonction get() ou getline().
Ensuite le bug survient au moment o� le programme doit revenir sur ces pas. J'utilise unget() plusieurs fois dans une boucle for (En raison d'un autre bug, voir rem ci-dessous).
A ce moment le pointeur doit se perdre car je n'arrive plus � lire de caract�res.


A) Donc est-ce que c'est possible de modifier le nombre de caract�res charg� ?
(J'ai observ� avec le debugger en me pla�ant sur pointeur de type fstream puis j'ai parcourus les �l�ments suivants /+ _Filebuffer /+ _Myfile /+ _bufsize = 4096

B) Est-ce qu'il est possible d'indiquer lorsque l'on ouvre le fichier qu'il soit totallement charg� en m�moire ? (fichier toujours plus petit que 10Mo)

C) Est-ce qu'il y a qqch � modifier ou indiquer sous Visual C++ pour utiliser correctement la classe fstream ?


REM:
Ouvrir le fichier:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
	string thefile = "nom du fichier";
	fstream * pOpenedFile;
	pOpenedFile = new fstream(thefile.c_str());

lire un caract�re:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
	char readChar;
	pOpenedFile->get(readChar);

lire une ligne:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
	string strLine;
	getline(*pOpenedFile,strLine);

retour en arri�re:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
	for(unsigned int i=0; i <= (strLine.length() - found ); i++)
	{
		pOpenedFile->unget();
	}

Si j'utilise pas les fonctions tellg() et seekg() c'est que les pointeurs retourn� n'ont aucun sens lors que les fins de lignes sont signal�es par Line Feed ( 0x0A ou '\n' )
(Un autre bug sous Visual C++ 2005 enfin, j'en suis pas certain.)

Et comme je souhaite pouvoir annalyser des fichiers texte au format UNIX ou Dos, je ne me limite pas au fin de ligne: Carriage Return et Line Feed ( 0x0D 0x0A ou "\r\n" ) donc, je n'ai pas utilis� ces 2 fonctions (tellg et seekg).

Voir: http://forums.microsoft.com/MSDN/Sho...08912&SiteID=1
(Message concernant ce probl�me.)

PS:
Si vous avez des conseilles pour annalyser (parser) un fichier texte, je suis preneur. Mais, je ne pense pas pouvoir les mettre tout de suite en pratique car je souhaite �viter de devoir r��crire la moiti� de mon code pour les mettre en pratique.


PS2:
S'il vous manque des infos, n'h�sitez pas � me l'indiquer.

[loufoque]

Pourrais-tu fournir un exemple minimal r�duit, qui compile et qui pr�sente le probl�me ?

[Farks]

Voil�, j'ai ajout� un fichier zip contenant:

exemple.cpp
parsersvf.h
parsersvf.cpp
flux.tester
exemple.txt

[Jean-Marc.Bourguet]

J'utilise unget() plusieurs fois dans une boucle for

C'est ton bug.

[JolyLoic]

Pour le coup des unget, je crois (je n'arrive plus � retrouver de r�f�rences, et ne suis pas sp�cialiste des iostreams) que la seule garantie est de pouvoir revenir en arri�re d'un cran uniquement, et pas plus loin. Il me semble raisonnable qu'une impl�mentation permette de revenir en arri�re de la taille de son buffer interne, et pas plus.

Pour ce qui est de forcer la lecture totale en m�moire, je ne vois gu�re que de passer par un stringstream, comme indiqu� dans http://c.developpez.com/faq/cpp/?pag...RS_full_buffer

Pour ce qui est des tellg/seekg, je ne sais pas trop ce que tu entends quand tu dis que les valeurs n'ont aucun sens. La valeur de tellg n'est sens�e avoir de sens que pour seekg, et pour personne d'autre.

Pour ce qui est du parsing, je suis surpris d'un format qui demande parfois � travailler en mode caract�res, et parfois en mode ligne. Souvent, c'est l'un ou l'autre. A part �a, si je devais parser un fichier, la m�thode employ�e d�pendrait principalement du format de celui-ci. Dans l'ordre :

• Pour un truc simpliste, genre fichier ini, lecture ligne � ligne, puis analyse de celle-ci � l'aide des fonctions de recherche de cha�ne.
• Pour des fichiers au format que je peux d�cider moi-m�me, n'ayant pas besoin d'�tre �crits � la main, boost::serialisation
• Pour des fichiers xml, v�rifier que c'est vraiment une bonne id�e, puis libxml++.
• Pour des fichiers avec une grammaire int�ressante, mais pas trop grosse, boost::spirit (pas encore eu l'occasion de mettre en oeuvre)
• Pour des fichiers avec une grosse grammaire, de la g�n�ration de code � l'aide d'outils comme antlr ou (lex/yacc)/(flex/bison)

Quelque part dans cette liste, il y aurait aussi un parseur r�cursif �crit � la mimine, mais je ne sais pas trop o� je le placerais...

[Farks]

J'utilise unget() plusieurs fois dans une boucle for

C'est ton bug.

Euh, je ne vois pas en quoi c'est mon bug ?

Car si tu utilises les fichiers contenu dans le zip et que tu modifies dans le fichier: parser.cpp

#define NB_LINE_READ 80
#define NB_PREVIOUS_CHAR 30


Le programme fonctionne correctement.
Il lit les 80 premi�res lignes.
Affiche la derni�re ligne lue.
Il revient en arri�re de 30 caract�res.
Affiche 8 caract�res.
Et affiche la fin de la ligne.


Tandis qu'avec:
#define NB_LINE_READ 73
#define NB_PREVIOUS_CHAR 10

Le programme n'agit pas correctement.
Il lit les 73 premi�res ligne.
Affiche la derni�re ligne lue.
Il revient en arri�re de 10 caract�res. => le pointeur se perd
Affiche 8x le m�me caract�re.
Et affiche la ligne qu'il avait lu pr�c�demment.

[Farks]

Pour le coup des unget, je crois (je n'arrive plus � retrouver de r�f�rences, et ne suis pas sp�cialiste des iostreams) que la seule garantie est de pouvoir revenir en arri�re d'un cran uniquement, et pas plus loin. Il me semble raisonnable qu'une impl�mentation permette de revenir en arri�re de la taille de son buffer interne, et pas plus.

Ah ok, �a expliquerai mon soucis...
Dsl Jean-Marc.Bourguet, d'avoir mis en doute ton indication.

Est-ce que quelqu'un peut m'indiquer la r�f�rence expliquant que le unget a un fonctionnement non garanti ?
Car en utilisant: g++, j'obtiens une application qui fonctionne parfaitement...

Pour ce qui est de forcer la lecture totale en m�moire, je ne vois gu�re que de passer par un stringstream, comme indiqu� dans http://c.developpez.com/faq/cpp/?pag...RS_full_buffer

Merci pour cette info et pour les explications de comment tu ferais.

Pour ce qui est des tellg/seekg, je ne sais pas trop ce que tu entends quand tu dis que les valeurs n'ont aucun sens. La valeur de tellg n'est sens�e avoir de sens que pour seekg, et pour personne d'autre.

En fait, quand on r�cup�re la valeur de tellg, elle signifie le nombre de caract�res depuis le d�but si on l'utilise sous forme num�rique. C'est ce qui permet de savoir le nombre de caract�res d'un fichier (C'est possible que ce soit un peu une magouille... Je ne connais pas assez la classe fstream pour garantir �a.).

Par contre, le bug que j'ai constat�, c'est que je ne reviens pas � la bonne position en utilisant tellg puis seekg.
Tu peux essayer en utilisant le petit exemple, il y a une partie en commentaire dans le fichier: exemple.cpp qui permet de faire des tests.

Plus d'info sur ce probl�me:
http://forums.microsoft.com/MSDN/Sho...08912&SiteID=1

[Jean-Marc.Bourguet]

Pour le coup des unget, je crois (je n'arrive plus � retrouver de r�f�rences, et ne suis pas sp�cialiste des iostreams) que la seule garantie est de pouvoir revenir en arri�re d'un cran uniquement, et pas plus loin. Il me semble raisonnable qu'une impl�mentation permette de revenir en arri�re de la taille de son buffer interne, et pas plus.

Je confirme. (Et je n'ai pas le temps de chercher les references, si j'ai bonne memoire le raisonnement etait assez indirect).

Pour ce qui est de forcer la lecture totale en m�moire, je ne vois gu�re que de passer par un stringstream, comme indiqu� dans http://c.developpez.com/faq/cpp/?pag...RS_full_buffer

J'ai ecrit une fois un streambuf qui garantissait le repositionnement n'importe ou.

Pour ce qui est du parsing, je suis surpris d'un format qui demande parfois � travailler en mode caract�res, et parfois en mode ligne. Souvent, c'est l'un ou l'autre. A part �a, si je devais parser un fichier, la m�thode employ�e d�pendrait principalement du format de celui-ci. Dans l'ordre :

• Pour un truc simpliste, genre fichier ini, lecture ligne � ligne, puis analyse de celle-ci � l'aide des fonctions de recherche de cha�ne.
• Pour des fichiers au format que je peux d�cider moi-m�me, n'ayant pas besoin d'�tre �crits � la main, boost::serialisation
• Pour des fichiers xml, v�rifier que c'est vraiment une bonne id�e, puis libxml++.
• Pour des fichiers avec une grammaire int�ressante, mais pas trop grosse, boost::spirit (pas encore eu l'occasion de mettre en oeuvre)
• Pour des fichiers avec une grosse grammaire, de la g�n�ration de code � l'aide d'outils comme antlr ou (lex/yacc)/(flex/bison)

Quelque part dans cette liste, il y aurait aussi un parseur r�cursif �crit � la mimine, mais je ne sais pas trop o� je le placerais...

Ca permet plus de souplesse. Parmi les avantages:
- pas necessaire de maitriser un generateur -- donc si on ne connait pas de generateur, c'est bien pour de petite choses
- on controle mieux les erreurs -- donc pour une grammaire figee, dans un contexte ou donner des messages d'erreurs clairs est important
- moins de contraintes sur la grammaire -- pour des langages comme le C et le C++, ca evite des hacks pour faire passer la grammaire dans le moule accepte par le generateur;