Version imprimable
Bonjour,
Résultat: s n'est pas vide (1 espace, comme record). Je pensais que le manipulateur skipws était sensé faire sauter les espaces à l'opérateur d'extraction !Code:
2
3
Cela marche si record = " 4" par exemple, on aboutit à s = "4". Mais pas quand record est complètement fait d'espaces.
J'ai raté qqe chose ou c'est un bug de Cygwin (lidstd++ plutôt..).
Merci.
Salut,
Avec Express VC++ et gcc, j'ai bien une chaine vide :
J'ai bien 0!Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
bah moi aussi avec ton programme !Citation:
Envoyé par 3DArchi
En fait ce que je fait c'est ça (parsing d'un fichier au format très simple) :
Et avec ça, si j'ai une ligne avec seulement des espaces, j'ai des choses comme ça en output :Code:
2
3
4
5
6
7
8
9
10
11
12
13
!Code:| |
Pär contre en ajoutant un s.clear() entre record.str(s) et record >> skipws >> s :là ça marche !Code:record.str(s); s.clear(); record >> skipws >> s;
J'ai constaté avec mes tests qu'il fallait des record.clear() et record.seekg en début de boucle sans quoi du débris s'accumule dans record, mais pour s, je ne comprends pas pourquoi il y a besoin d'un clear(). Son scope est dans le try{ }, donc on a un s tout frais en début de boucle normalement !
J'ai un horrible pressentiment.
Vérifie que " 4" marche toujours avant de crier victoire...
A un moment donnée, j'avais eu quelque soucis avec des stringstream et, de mémoire, on m'avait conseillé de ne pas les réutiliser. Donc en modifiant ton code comme ça :
Qu'en est-il?Code:
2
3
4
5
6
7
8
9
10
11
12
13ifstream mapFile ( fname, ifstream::in ); // Read text while( ! mapFile.eof() ) { // Leaves \n in input try { string s; getline( mapFile, s ); // \n is discarded istringstream record(s); record.str(s); record >> skipws >> s; cout << "|" << s << "|" <<endl; record.seekg( 0, ios::beg ); ... catch(ifstream::failure e) {...} }
Je sais à quoi tu penses :mouarf:Citation:
Envoyé par Médinoc
L'analyse de l'enregistrement en cours se fait avec le contenu de record et non de s. s sert seulement pour tester si la ligne est vide (vide ou ne contenant que des blancs) - s.empty().
Maintenant que je fais des getline( record, s, ' ' ); (dans une autre fonction - parseRecord()), je vois en effet que getline se croute sur recod.eof pour une ligne comme " 4", et s reste vide.. 8O
Das suggestions pour découper " 4 152 198365672" selon les espaces (sans Boost ou classe Tokenizer méchante! :mrgreen:)
@3DArchi : qu'est ce que tu crois ? que les clear() et les seekg() m'amusent ?!
bien sûr que j'aurais préféré un record tout frais en début de boucle (comme pour s). Mais yé pé pas ! (tu veux le n° de mon boss ? :sm:)
Salut,
La réponse est subtile et se trouve ici.
Le principe: toute surcharge de l'opérateur >> (ou << pour l'output) doit passer par std::sentry. Or std::sentry va, entre autre, nettoyer les espaces du flux si skipws est positionné. Donc lorsque tu fais record >> s;, il commence par nettoyer les espaces, aboutit à un flux vide qu'il positionne en erreur. Donc s n'est même pas réinitialisé et reste avec sa valeur précédente! La seule solution que je vois consisterait à tester l'erreur sur la lecture de s et positionner celle-ci à vide en ce cas. C'est assez bancale, pour ne pas dire plus :
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17ifstream mapFile ( fname, ifstream::in ); // Read text while( ! mapFile.eof() ) { // Leaves \n in input try { string s; getline( mapFile, s ); // \n is discarded istringstream record(s); record.str(s); record >> skipws; if((record >> s).fail()){ s.clear(); } cout << "|" << s << "|" <<endl; record.seekg( 0, ios::beg ); ... catch(ifstream::failure e) {...} }
Formulé autrement, tu demandes d'avancer jusqu'à trouver un caractère que ne soit pas une espace. Il arrive en fin de flux sans en trouver, ce dernier passe donc en erreur, et toute opération dessus devient une no-op.Citation:
Envoyé par 3DArchi
Je n'ai pas lu la totalité du code, mais a priori, le plus simple me semble encore d'utiliser une première variable pour lire l'ensemble de la ligne, et une seconde pour en extraire l'information.Citation:
Envoyé par 3DArchi
Code:
2
3
4
5
Ce fil est résolu !Citation:
Envoyé par 3DArchi
@JolyLoic; Je préfère faire s.clear() systématiquement, c'est plus paresseux et me fait l'économie d'une variable.
Merci à tous les contributeurs et au plaisir !
Si je peux me permettre, n'oublie pas Boost si les choses se compliquent. Ca te permettra de garder la main sur ta conception et sur la modularité tout en réalisant pleinement le parsing que tu souhaites faire (je pense à Tokenizer, Regexp et Spirit).
Bien sûr que j'y pense, mais j'essaie de coller au standard autant que faire se peut, et je peux m'en tirer dans ce cas sans trop de dégâts. Ma fonction de parsing reste sous contôle (une 40aine de ligne - cf. ci-bas).Citation:
Envoyé par Alp
En même temps, un standard qui ne supporte pas les regexp en est-il un ?!
Autant je considère les regexp comme le point d'échec d'un langage (le point le plus éloigné du langage naturel - ici l'anglais - vers lequel doit tendre au maximum tout langage de programmation, le langage de programmation ultime étant de pouvoir causer à un ordi en bon anglais/français/allemand/...), autant il y a des situations où une regexp fait gagner tellement de lignes de code que ça justifie largement le cout en termes de "code-mystification"..
C'est vrai que pour un format simple à parser, si ma fonctioin commençait à tendre vers la 100aine de lignes, je me poserais sérieusement la question de Booster ou pas mon code !Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Vu que tu parles de Regex et de boost, va voir ici, c'est un tuto que je viens juste de finir d'écrire
Les Regex sont dans le technical report 1 il me semble, qui est fourni avec les dernières versions de g++ et VC++, au moins.
Dans tous les cas, le prochain standard contiendra bien plus de choses ;)