C++

STL: ifstream

Recherche :

Mot : Pseudo : Filtrer
Page : 1 2 Page Suivante Page Précédente Bas de page
Auteur	Sujet : STL: ifstream

LetoII

Le dormeur doit se réveiller

Ca va apraitre con comme question mais j'ai aps trouvé de doc là dessus: est ce qu'il y a un comportement standard de l'objet quand le buffer est trop petit pour prendre la ligne entière lors d'un appel à getline? (à part tronqué la ligne)

c surtout pour pouvoir soit récupérer la suite de la ligne ou modifier le buffer et relire la ligne.

---------------
Le Tyran

Publicité

farib

comprend pas trop....

LetoII

Le dormeur doit se réveiller

farib a écrit a écrit :

comprend pas trop....

Imagine que t'as un buffer de 512 caractaires et une ligne de 1024 caractaires. Si tu fais:

Code :

buffer [513];//512 caractaires + le \0 de fin
ifstream file("mon_fichier",ios_base::in);
file.getline(buffer,513);

La ça prend pas toute la ligne, et si tu fais un autre getline ensuite ça fait pas la même chose suivant les implémentations de la stl (j'ai déjà vu ça te cole tout le temps une chaine vide dans le buffer et ça te relis la même ligne depuis le début)

D'où ma questino y a-t-il un moyen standard de s'en sortir?

---------------
Le Tyran

LeGreg

Si tu veux t'epargner de gerer a la main les buffers de taille variable tu as la string de la STL
et la fonction du namespace std
std::getline()

A+
LeGreg

LeGreg

au fait ca ne marche effectivement
que sur le basic_istream et basic_string de la STL <istream> et <string> et non pas sur l'implantation microsoft obsolete <iostream.h>

A+
LeGreg

LetoII

Le dormeur doit se réveiller

Ok je vais regarder ça de plus pret, merci

---------------
Le Tyran

LetoII

Le dormeur doit se réveiller

Ca a l'air de bien marcher, encore merci.

Ps: plus je m'en sert moin je trouve ça bien la STL, c normal ou je suis un grand malade?

---------------
Le Tyran

El_gringo

letoII a écrit a écrit :

Ca a l'air de bien marcher, encore merci.

Ps: plus je m'en sert moin je trouve ça bien la STL, c normal ou je suis un grand malade?

J'ai jammais utilisé. J'ai jammais trouvé une documentation claire de la STL. Sur la MSDN Library, c une horreur (surement volonatirement de la part de Microsoft et ses MFC).

LetoII

Le dormeur doit se réveiller

El_Gringo a écrit a écrit :

J'ai jammais utilisé. J'ai jammais trouvé une documentation claire de la STL. Sur la MSDN Library, c une horreur (surement volonatirement de la part de Microsoft et ses MFC).

Y a plein de sites documentant la STL, le pb c qu'il faut savoir ce qu'on cherche, de plus sur visual 6 l'implémentation de la STL est pourrie.

---------------
Le Tyran

El_gringo

letoII a écrit a écrit :

Y a plein de sites documentant la STL, le pb c qu'il faut savoir ce qu'on cherche, de plus sur visual 6 l'implémentation de la STL est pourrie.

Tient !? Microsoft ne respecterai pas bien un standard !? étonnant ça...
Donc g bien raison de ne pas m'en servir, puisque mon IDE est justement VC++ 6

Publicité

LetoII

Le dormeur doit se réveiller

El_Gringo a écrit a écrit :

Tient !? Microsoft ne respecterai pas bien un standard !? étonnant ça...

Donc g bien raison de ne pas m'en servir, puisque mon IDE est justement VC++ 6

On peut le voir comme ça
Tant que tu fais que de la prog windows je pense que tu peux t'en passer, mais bon c pas top pour la portabilité

---------------
Le Tyran

LeGreg

la STL c'est pas sorcier, c'est l'une des bases du C++,

en plus tu peux ecrire des trucs style

Code :

vector<MonType *> monArray;
/*...*/
for_each(monArray.begin(), monArray.end(), Deleter());

avec Deleter un "foncteur" qui va appeler delete sur chaque element de ton tableau.

Ou alors, pour trier un ensemble:

Code :

vector<MonType> monArray;
/*...*/
sort(monArray.begin(), monArray.end(), MonComparateur());

Et contrairement a qsort c'est totalement typesafe.

Evidemment pour arriver a cela il y a une certaine complexité sous-jacente, mais le programmeur débutant n'a pas a maitriser cette complexité, lui il doit juste savoir ce qu'est un iterateur (un objet qui permet de naviguer entre les elements), de savoir la difference entre une liste, une array, une map et un set (c'est de l'algo de base) et basta la syntaxe est la meme pour tous les conteneurs.

De meme pour les entrees sorties en C++, elles se font toutes par le ios qui fait partie de la STL
cout << "hello world";
La chaine de base en C++ est une std::string, etc.. etc..

Bref, difficile de passer a coté.

LeGreg

LeGreg

Desolé, je fais court parce que c'est un vaste sujet..
mais y'a plethore de bouquins sur le C++ qui te parleront de la STL (effective C++ par Meyer si je me souviens bien)

LeGreg

El_gringo

Pour de la prog windows, c très facile de passer à coté.
Grâce aux MFC nottament...
Pour le reste, j'en sais rien, et pr l'instant, ça ne me concerne pas !

Message édité par El_gringo le 19-08-2002 à 14:02:49

LeGreg

El_Gringo a écrit a écrit :

Tient !? Microsoft ne respecterai pas bien un standard !? étonnant ça...

En fait le probleme est que le standard en question (le C++ iso)
est changeant, et que le temps qu'une version d'un compilateur sorte la norme a changé ce qui fait que les compilateurs ont tous plus ou moins de difficultés avec le standard. De plus, certaines fonctionalités necessitent des interventions tres lourdes et non détaillées par le standard (export sur les templates par exemple), ce qui fait que les editeurs rechignent a les implementer.

Ceci dit, avec la version 6, tu n'as pas trop de probleme sauf si tu veux utiliser les dernieres librairies style boost et autre et je crois que la version 7 (ou 7.1) implante correctement certaines fonctions manquantes, ainsi que des hash_map et hash_set etc...

Les MFC aussi sont changeante: ainsi dans la derniere version les CString sont partagées par les MFC et ATL sous forme d'un template CStringT< >, mais c'est un detail.

A+
LeGreg

boborde

au lieu de créer un nouveau topic je continue sur celui ci

J'utilise la stl , avec les fstream

pas de pb , je lis correctement une ligne via getline vers un char*

Mai g besoin d'un coup de pouce SVP

Code :

list <string> chaines_caractere ; //une liste de basic_string
list <string>::iterator i ; // l'itérateur ki va avec

cette écriture ne donne pas d'erreur à la compilation
string étant des basic_string, classe elle meme utilisant la stl

Mon idée étant d'utiliser une string pour chaque ligne de fichier lue

ou autre chose

Code :

char* c ;
while ( !fichier.eof() )
{
getline(c,[100],'\n');
// et la il faudrait insérer la ligne récup vers un élément
//string de la liste

.. dans la doc basic_string il est chait ref à une classe Template charT*.... une classe pour implémenter la stl avec tout ce ki fo ( constructeur de recopie etc ...)

ke dois - je utiliser pour ke ca marche ??

qqun pourrait m'expliquer si il faut un autrre iterateur dans les strings plutot que dans les chaines ??

merci pour votre réponse, je vaincrais les listes chainees un jour..

SoWhatIn22

boborde a écrit a écrit :

au lieu de créer un nouveau topic je continue sur celui ci

J'utilise la stl , avec les fstream

pas de pb , je lis correctement une ligne via getline vers un char*

Mai g besoin d'un coup de pouce SVP

Code :

list <string> chaines_caractere ; //une liste de basic_string
list <string>::iterator i ; // l'itérateur ki va avec

Code :

char* c ;
while ( !fichier.eof() )
{
getline(c,[100],'\n');
// et la il faudrait insérer la ligne récup vers un élément
//string de la liste

Si je comprends bien, tu veux lire les lignes du fichier et les mettres dans une liste de string.

Code :

#if defined WIN32 && defined _MSC_VER
#pragma warning( disable : 4786) /// F@ck the MS STL warnings ;-)
#endif
#include <iostream>
#include <fstream>
#include <list>
#include <string>
using namespace std;
int main( )
{
string my_str;
list <string> my_list;
list <string>::iterator my_it;
ifstream my_stream;
/// Open the file
my_stream.open( "toto.txt", std::ios::in | ios::binary );
if( my_stream.fail() )
{
cerr << "Failure while opening file. Exit..." << endl;
cin.get();
return 1;
}
/// Go to the very beginning
my_stream.seekg( 0, std::ios::beg );
/// Read every line and put them in the list
while( !my_stream.eof() )
{
//my_str << my_stream.getline();
getline(my_stream, my_str, '\n');
my_list.push_back( my_str );
}
/// Write the list content to the standard output
for( my_it=my_list.begin(); my_it!=my_list.end(); my_it++ )
{
my_str = *my_it;
cout << my_str << endl;
}
/// Wait and see...
cin.get();
return 0;
}

boborde

Merci beaucoup

sous Builder, le seconde paramètre de getline pour fstream est documenté comme étant le nombre de caractères à lire ???

est surtout documenté pour utilisé des char* au lieu de string

ca marche nickel merci

Message édité par boborde le 23-08-2002 à 16:43:33

SoWhatIn22

boborde a écrit a écrit :

Merci beaucoup

sous Builder, le seconde paramètre de getlmine pour fstream est documenté comme étant le nombre de caractères à lire

je vous dis si ca marche

hum... C'est pas la méthode getline de la classe fstream qui est utilisée. C'est la fonction std::getline.

Sinon, j'aurrait du écrire my_stream.getline(...)
Et la méthode getline de la classe fstream prends bien le nombre de caractères à lire en 2nd argument.

Avantage de la fonction que j'ai utilisé par rapport à la méthode de la classe fstream: je n'ai pas à me soucier de la taille de la ligne, et je n'ai aucune allocation mémoire à faire. Tout est fait dans les classes de la STL.

LetoII

Le dormeur doit se réveiller

SoWhatIn22 a écrit a écrit :

hum... C'est pas la méthode getline de la classe fstream qui est utilisée. C'est la fonction std::getline.

Sinon, j'aurrait du écrire my_stream.getline(...)
Et la méthode getline de la classe fstream prends bien le nombre de caractères à lire en 2nd argument.

Avantage de la fonction que j'ai utilisé par rapport à la méthode de la classe fstream: je n'ai pas à me soucier de la taille de la ligne, et je n'ai aucune allocation mémoire à faire. Tout est fait dans les classes de la STL.

Ouai, par ce que comme dit plus haut quand le buffer est trop petit ça chie grave!

---------------
Le Tyran

boborde

Je comprends mieux le dilemme maintenant juste une question ,

dite moi si je me trompe mais pour cet exemple , et dans le cas de fichiers ASCII , ios::binary et nécessaire ?? ou non ? :hap:

LetoII

Le dormeur doit se réveiller

boborde a écrit a écrit :

Je comprends mieux le dilemme maintenant juste une question ,

dite moi si je me trompe mais pour cet exemple , et dans le cas de fichiers ASCII , ios::binary et nécessaire ?? ou non ? :hap:

Non

boborde

g une autre question

pour un string dans ma liste, je n'arrive pas a supprimer le dernier élément ,

meme si

Code :

erase(it.end)

par exemple ne pose pas d'érreur le car est bien présent

qqun a déja eu ce pb.. demain je poste le code

Willyzekid

A propos (désolé pour le pourissage de topic): une question que je me suis toujours posé sans jamais oser aller chercher la réponse

Quand on ouvre un fichier en utilisant la STL (et ca doit être open la fct mbre?), tout le fichier est mis en mémoire en mémoire centrale, non?

---------------
Horizon pas Net, reste à la buvette!!

LetoII

Le dormeur doit se réveiller

boborde a écrit a écrit :

Code :

erase(it.end)

Si, c'est une erreur. i.end() n'est pas un élément valide

---------------
Le Tyran

boborde

oki

LeGreg

Willyzekid a écrit a écrit :

Quand on ouvre un fichier en utilisant la STL (et ca doit être open la fct mbre?), tout le fichier est mis en mémoire en mémoire centrale, non?

Reponse: ca depend.
les acces peuvent etre bufferises et donc sur des petits
fichiers tous les acces seront fait depuis la memoire vive
par contre comme la STL peut donner acces a des fichiers
de taille infinie, cela vaut mieux que tout le fichier ne soit pas en memoire .

Donc Non, tout le fichier n'est pas mis en memoire sauf s'il est suffisamment petit pour tenir dans un buffer.

LeGreg

Joel F

Real men use unique_ptr

boborde a écrit a écrit :

g une autre question

pour un string dans ma liste, je n'arrive pas a supprimer le dernier élément ,

meme si

Code :

erase(it.end)

par exemple ne pose pas d'érreur le car est bien présent

qqun a déja eu ce pb.. demain je poste le code

utilise plutot :

Code :

erase(it.back())

end() pointe APRES le dernier element, on s'en sert comme ceci :

Code :

#include <vector>
#include <iostream>
using namespace std;
vector<int> tab;
vector<int>::iterator pos;
// Ici tu remplis ton tab avec
// tab.push_back( valeur );
//
for( pos = tab.begin(); pos < tab.end() ; pos++)
{
cout << *pos << endl;
(*pos) = 2* (*pos);
cout << *pos << endl;
}

Perso, la STL resout enormement de problemes qui ont tendance à etre recurrent. Programmer une Table de hacahge ou un arbre AVL equilibré ca se chie pas comme ça, on bien content d'avoir multimap ou heap tout fait qui marche.

Pour els utilisateurs de VC++ 6.0 et superieur, je vous conseil de telecharger la version Rogue Wave de la STL qui remplace avantageusement l'implantation de Micro$oft ... moins de bug et plus optimisée surtout.

LetoII

Le dormeur doit se réveiller

Joel F a écrit a écrit :

...

Ca change ce nickname. Tjrs le même mot de passe?

Joel F

Real men use unique_ptr

Même pas ...
tu vois qd je veux je peux ...

(enfin bon c pas original non plus ...)

Willyzekid

Hum...Ca dépend, c'est pas satisfaisant ca
Je fais des recherche pour écrire un compilo/traducteur et j'aimerais être sûr d'avoir les accés les plus rapides.

En fait, comment faire pour être sur que mon fichier soit tout en mémoire centrale (et recevoir un pointeur sur le début du fichier)?

Dans le Scanner, je parcours le fichier caractère par caractère pour obtenir les lexèmes. Au lieu d'appeler une fonction pour obtenir le caractère suivant, j'aimerai juste incrémenter le pointeur.

Enfin quel est le mieux:
- mettre tout le fichier en mémoire, l'analyser (et pdt ce temps lancer eventuellement le chargement du fichier suivant)
- utiliser un système de double buffer (similaire) plus petit?

---------------
Horizon pas Net, reste à la buvette!!

Joel F

Real men use unique_ptr

Bon ben la on droppe la STL

Code :

FILE* fichier;
int pos;
char* tampon;
string contenu;
fichier = fopen( "fichier.txt", "r" );
if( fichier )
{
fseek( fichier, SEEK_END);
pos = ftell( fichier );
fseek( fichier, SEEK_SET );
tampon = new char[pos];
if( tampon )
{
fread( tampon, pos, 1, fichier );
fclose( fichier );
}
contenu = tampon;
}

On passe par les bons vieux char* pour lire tout le fichier d'un bloc puis on le recopie dans une string...

Bon cpas super niveau perf au chargement mais bon ... c a toi d e voir.
Sino avec Win32, tu peux jongler avec les GlobalAlloc etc mais la je n'en sais pas plus.

LetoII

Le dormeur doit se réveiller

Voir les filemapping aussi.

Willyzekid

Joel F a écrit a écrit :

Bon ben la on droppe la STL

On passe par les bons vieux char* pour lire tout le fichier d'un bloc puis on le recopie dans une string...

Bon cpas super niveau perf au chargement mais bon ... c a toi d e voir.
Sino avec Win32, tu peux jongler avec les GlobalAlloc etc mais la je n'en sais pas plus.

C'est ce que je me disais aussi...Si je passe une heure a lire un fichier pdt ce temps là, le proce, il fait rien pour moi (du moins au premier fichier, au deuxième, il pourra analyser ce qui est déjà chargé).
(Cela dit, sur des fichiers de code, ca doit pas être bien méchant? j'en ai aucune idée en fait)
D'où l'idée d'utiliser deux buffers plus petit gérés par deux processus: l'un est rempli pdt que l'autre est analysé...

Autre chose aussi...plus tard dans la compilation (en deux passes), on a donc le scanner et le paser qui travaille ensemble. Le scanner produit une unité léxicale et le paser la consomme en en faisant l'analyse syntaxique.
Est-il utile ici de créer 2 processus sur le modèle producteur/consommateur se partageant une section critique (un tampon contenant les léxèmes). Gagne-t-on vraiment en perf?

---------------
Horizon pas Net, reste à la buvette!!

Willyzekid

Ah et on parle pas encore de bi-processeur

---------------
Horizon pas Net, reste à la buvette!!

LetoII

Le dormeur doit se réveiller

Willyzekid a écrit a écrit :

C'est ce que je me disais aussi...Si je passe une heure a lire un fichier pdt ce temps là, le proce, il fait rien pour moi (du moins au premier fichier, au deuxième, il pourra analyser ce qui est déjà chargé).
(Cela dit, sur des fichiers de code, ca doit pas être bien méchant? j'en ai aucune idée en fait)
D'où l'idée d'utiliser deux buffers plus petit gérés par deux processus: l'un est rempli pdt que l'autre est analysé...

Autre chose aussi...plus tard dans la compilation (en deux passes), on a donc le scanner et le paser qui travaille ensemble. Le scanner produit une unité léxicale et le paser la consomme en en faisant l'analyse syntaxique.
Est-il utile ici de créer 2 processus sur le modèle producteur/consommateur se partageant une section critique (un tampon contenant les léxèmes). Gagne-t-on vraiment en perf?

C qui qui se plaignait qu'on avait que des newbyes?

Ca peut être intéressant comme aproche.

Willyzekid

letoII a écrit a écrit :

C qui qui se plaignait qu'on avait que des newbyes?

C'est un compliment?

letoII a écrit a écrit :

Ca peut être intéressant comme aproche.

C'est exactement ce que je dis et ca fait pas avancé le schimlblique.
Mon problème en fait, c'est le surcoût du à la gestion des commutation de processus. Cela vaut-il le coup (sachant que pour l'instant, le bi-proce n'est pas considéré) de l'avoir? (a priori non! )

Mais bon j'ouvrirais un autre topic quand j'aurai un prb insoluble parce que là on devait parler de stl

---------------
Horizon pas Net, reste à la buvette!!

LetoII

Le dormeur doit se réveiller

Willyzekid a écrit a écrit :

C'est un compliment?

C'est exactement ce que je dis

et ca fait pas avancé le schimlblique.
Mon problème en fait, c'est le surcoût du à la gestion des commutation de processus. Cela vaut-il le coup (sachant que pour l'instant, le bi-proce n'est pas considéré) de l'avoir? (a priori non!

)

Mais bon j'ouvrirais un autre topic quand j'aurai un prb insoluble parce que là on devait parler de stl

Un thread peut être plus qu'un autre processus. Mais je suis pas sûr que tu gagne. La faut faire des tests de perf.

Et oui ct un compliment, ça change de "comment je fais pour déterminer la longueur d'une chaine" (j'egsagère un poil )

---------------
Le Tyran

Musaran

Cerveaulté

Willyzekid a écrit :

Est-il utile ici de créer 2 processus sur le modèle producteur/consommateur se partageant une section critique (un tampon contenant les léxèmes). Gagne-t-on vraiment en perf?

Avec deux processeurs tu gagnerais, à condition que les threads soient intelligemment placés par l'OS.
Avec un processeur, le seul avantage serait de parser plus tôt, et de détecter plus tôt les erreurs.
Quoique... si le scanner et le parser sont suffisamment synchronisés, la mise en cache des données communes pourrait être bénéfique.
Mais plutôt que deux threads, on peut gérer cela soi-même: traiter des symboles, quand n ou tous sont consommés, passer la main au module suivant.

Note: Le conteneur STL deque gère le tampon à deux accès.

Citation :

Enfin quel est le mieux:
- mettre tout le fichier en mémoire, l'analyser (et pdt ce temps lancer eventuellement le chargement du fichier suivant)
- utiliser un système de double buffer (similaire) plus petit?

Le mappage de fichier en mémoire virtuelle est insurpassable.
Le système s'occupe de tout: taille du tampon, écritures et lectures (effectuées seulement si accès effectif), optimisation du cache disque...
Et de façon transparente: l'intégralité du fichier est disponible en mémoire en un bloc.
Par contre, c'est forcémment des APIs.
Sous Linux c'est mmap je crois.
Sous Windows c'est un peu compliqué. Si tu veux je resors ça.

Joel F a écrit :

Bon ben la on droppe la STL

Oui mais non !
La STL dispose de tout ce qu'il faut...
Je dirais ouvrir le fichier en ifstream binaire, créer un vector de la taille du fichier, copier avec copy.
Malheureusement, je ne sais pas déterminer la taille du fichier.

Message édité par Musaran le 29-08-2002 à 03:05:16

---------------
Bricocheap: Montage de ventilo sur paté de mastic silicone

HelloWorld

Salut tout le monde!

Quelques questions/suggestions

Se dire qu'en utilisant la STL ou un buffer de la taille du fichier on aura pas de probleme de buffer trop petit lors du get_line est AMHA pas très acceptable.
Le problème n'est que reporté, pas éliminé.
Un tableau a une limite. Celle-ci peut etre atteinte.
Augmenter la taille du tableau ne change en rien le fait que sa limite peut toujours être atteinte.
Du coup : que se passe-t-il avec la version *all STL* si le fichier est trop gros/la ligne trop longue/pas assez de mémoire (au choix ) ?
Tu n'as pas à te soucier de l'alloc de place, mais tu dois tout de même te soucier du cas ou y'a pas assez de place.

Pour le modele producteur/conso, je pense que ca peut etre benefique. Notament si ton programme n'est pas le seul à acceder au disque (genre une copie de gros fichier est en cours).
Le fichier mappé ... perso je suis pas cho (c'est pas destiné à un autre usage ?)
Le fait d'avoir un buffer d'une taille donnée (taille que tu décide en fonction du temps que ca prend à parser ... histoire de tenir 10 secondes par exemple tout en restant dans les limites de l'acceptable nivo memoire, genre 1 Mo) que le premier thread s'occupe de maintenir plein et que le second s'acharne à vider ne doit pas être sorcier à coder.
En utilisation classique je ne pense pas que ca apporte grand chose.
Mais ton programme resistera mieux a un acces disque perturbé et autre avantage que je trouve a utiliser des thread pour les acces disque : ton programme est plus réactif.
Perso je deteste qu'un programme se fige quand il accede au lecteur de disquette ou qu'il soit lent a la detente quand il sollicite fortement le disque. (genre Word quand on enregistre un gros doc... plus rien ne répond :fou: ).
La, seul ton thread d'acces disque sera bloque et pas ton programme principal.

Au fait, c'est un parser de quoi ? (ca m'a echapé)

---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite

Publicité

Page : 1 2

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Programmation

C++

STL: ifstream

Sujets relatifs
[C++] délimiteur sous ifstream	[C++ STL] Quelles sont les différences entre vector et list?
[C++]: Problèmes de templates avec la STL	[STL fstream]
gcc et la STL: pb de link	[VC++] Dll et STL: probleme de recopie (???)
[C++ STL] map	Classe graphe en C++ et utilisation de STL
[C++] STL/Libraire pour ouvrir des images
Plus de sujets relatifs à : STL: ifstream

Page générée en 0.116 secondes