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.

comprend pas trop....

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

 
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?

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

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

Ok je vais regarder ça de plus pret, merci

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?

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).

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

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é

la STL c'est pas sorcier, c'est l'une des bases du C++,  
 
en plus tu peux ecrire des trucs style
 

 
avec Deleter un "foncteur" qui va appeler delete sur chaque element de ton tableau.
 
Ou alors, pour trier un ensemble:

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

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

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 !

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

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
 

 
 
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
 

.. 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..

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

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

 
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!

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 ?

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 ?

 
Non

g une autre question
 
pour un string dans ma liste, je n'arrive pas a supprimer le dernier élément ,
 
meme si

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

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?

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

oki

 
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

 
utilise plutot :
 

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

 
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.
 

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

Même pas ...
tu vois qd je veux je peux ...
 
(enfin bon c pas original non plus ...)

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?

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.

Voir les filemapping aussi.

 
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?

Ah et on parle pas encore de bi-processeur

 
C qui qui se plaignait qu'on avait que des newbyes?
 
Ca peut être intéressant comme aproche.

 
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

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 )

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.
 

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.
 

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.

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 ).
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é)