Discussion :

[toutounesan]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
CStdioFile f2 ("C://mesures//mesures_temp.txt", CFile::modeRead | CFile::typeText );
 
 
 
	fichier.close();
	CString s1, s2
	f2.ReadString(s1); // s1 contient "premiere ligne"
	f2.ReadString(s2); // s2 contient "deuxieme ligne"
 
 
   CString strTemp=s1;
   char *pWord = strtok(strTemp.GetBuffer(0), ";");
   while( pWord != NULL )
   {
        pWord = strtok( NULL, ";" );
   }

Je récupére les données sans séparateurs (je spécifie le séparateur),
mais je dois savoir combien il y a de lignes dans le fichier.
Comment faire?

[poukill]

[yan]

est tu obligé d'utiliser les CString ??
Attention strtok
char *pWord = strtok(strTemp.GetBuffer(0), ";");
strok va modifier la mémoire de strTemp. ce qui n'est pas propre, et certainement créer des problème de memoire plustard

[toutounesan]

non mais je pourrais utiliser quoi d'autres?

Pour l'insant j'ai que des mesures mais après j'aurais des chaînes de caractères aussi

[Médinoc]

Pour savoir ou non s'il y a un inconvénient à employer strtok() ici, il faudrait savoir ce que tu vais de strTemp par la suite.

Quant au comptage de ligne, ben... Une boucle de ReadString() devrait faire l'affaire, non ?

[poukill]

je dois savoir combien il y a de lignes dans le fichier.
Comment faire?

J'ai déjà dit :
Dans la FAQ : il y a deux méthodes. Tu vas dans la FAQ de temps en temps?
http://cpp.developpez.com/faq/cpp/?p..._compte_lignes

[yan]

non mais je pourrais utiliser quoi d'autres?

Pour l'insant j'ai que des mesures mais après j'aurais des chaînes de caractères aussi

Ben les std::string justement. La faq est basé sur La SL (donc plustôt portable) et non les MFC (beurk pas beau) .
Je comprend ton problème avec la FAQ, vue que tu utilise des class windows... Si tu as le choix, utilise les string, ifstream, ofstream de la std. Qui sont bien expliqué dans la FAQ et je pense de meilleur qualité que ces les MFC

[yan]

Pour savoir ou non s'il y a un inconvénient à employer strtok() ici, il faudrait savoir ce que tu vais de strTemp par la suite.

Quant au comptage de ligne, ben... Une boucle de ReadString() devrait faire l'affaire, non ?

Vue que strtok modifie la mémoire du tableau de char* passé en paramètre. Il y as un gros inconvénient !! Même si cela plantera peut être pas, utilisé comme cela, on va modifier la mémoire d'un objet, sans qu'il en soit conscient. Ce qui n'est pas du tout propre et une grosse source de bug futur

[yan]

EN faite y as une FAQ pour le MFC
http://cpp.developpez.com/faq/vc/?page=sommaire
dont cette partie :
http://cpp.developpez.com/faq/vc/?page=Fichiers
qui ressemble à ce que tu cherche

[toutounesan]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
 
CStdioFile f2 ("c:\\test.txt", CFile::modeRead | CFile::typeText );
CString s1, s2;
f2.ReadString(s1); // s1 contient "premiere ligne"
f2.ReadString(s2); // s2 contient "deuxieme ligne"
f2.Close();
 
//----------Lecture des éléments de la 1ere ligne (les éléments séparés par ";"------------//
CString strTemp=s1;
   char *pWord = strtok(strTemp.GetBuffer(0), ";");
   while( pWord != NULL )
   {
        pWord = strtok( NULL, ";" );
   }

Je ne sais pas trop comment faire pour lire tous éléments de toutes les lignes

[yan]

ca devrait être

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
CStdioFile f ("c:\\test.txt", CFile::modeRead | CFile::typeText );
CString s_ligne;
 
//lecture ligne par ligne du fichier
while(f2.ReadString(s_ligne) == true)
{
//traitement de la ligne
}
 
f2.Close();

Encore une fois si tu peut eviter d'utiliser les CString et autre class de la mfc, fait le.

Les string, ifstream de la std sont bien plus simple et propre.

[yan]

Pour le decoupage de la ligne. Il n'y as pas de methode de token avec les CString. Faut que tu le fasse a la main .
voici un lien sur une class token pour les CString (beurk pas bô)
http://www.codeguru.com/cpp/cpp/stri.../?thread=36906

[Médinoc]

Vue que strtok modifie la mémoire du tableau de char* passé en paramètre. Il y as un gros incontinent !! Même si cela plantera peut être pas, utilisé comme cela, on va modifier la mémoire d'un objet, sans qu'il en soit conscient. Ce qui n'est pas du tout propre et une grosse source de bug futur

Avec CString::GetBuffer(), l'objet est conscient qu'on modifie ses données.
Mais il faut faire un ReleaseBuffer() quand on a fini...

[yan]

Avec CString::GetBuffer(), l'objet est conscient qu'on modifie ses données.
Mais il faut faire un ReleaseBuffer() quand on a fini...

??? peut etre mais c'est pas propre

[Médinoc]

Ben si.
C'est la façon que donne MFC pour avoir un accès en écriture sur les caractères, quand le besoin s'en fait sentir.

Cela évite d'avoir à faire un new char[], une recopie, puis peut-être une seconde...

Bien sûr, je dois reconnaître qu'il n'est pas courant de l'employer avec une fonction comme strtok()...
Mais ça reste tout-à-fait valide, d'autant qu'on SAIT que strtok() n'augmentera jamais la taille de la chaîne...

[yan]

Ben si.
C'est la façon que donne MFC pour avoir un accès en écriture sur les caractères, quand le besoin s'en fait sentir.

Cela évite d'avoir à faire un new char[], une recopie, puis peut-être une seconde...

Bien sûr, je dois reconnaître qu'il n'est pas courant de l'employer avec une fonction comme strtok()...
Mais ça reste tout-à-fait valide, d'autant qu'on SAIT que strtok() n'augmentera jamais la taille de la chaîne...

Mouais. Je viens de trouver ça dans la FAQ http://cpp.developpez.com/faq/vc/?pa...ons#MakeStrtok

Utiliser strtok avec CString je pense que c'est du Goret Force 7.... Du moins ca peut donner de mauvais habitude...
mais bon c'est mon avis.

[Médinoc]

Pour moi, utiliser strtok() quant strtok_r() est disponible est du code de goret.
Sachant que strtok_r() n'est pas disponible sous Visual, et un équivalent n'existe que depuis la CRT 8.0 (ils l'ont appelée strtok_s()).

Bien sûr, la bonne méthode serait de réimplémenter strtok_r() quand elle n'est pas là, mais il y a le facteur flemme qui entre en jeu.


...Ah, ce n'est pas de ça que tu parlais ?
Si c'est juste parce que strtok() modifie la chaîne, je pense que tes préjugés sont injustifiés.

[yan]

Pour moi, utiliser strtok() quant strtok_r() est disponible est du code de goret.
Sachant que strtok_r() n'est pas disponible sous Visual, et un équivalent n'existe que depuis la CRT 8.0 (ils l'ont appelée strtok_s()).

Bien sûr, la bonne méthode serait de réimplémenter strtok_r() quand elle n'est pas là, mais il y a le facteur flemme qui entre en jeu.


...Ah, ce n'est pas de ça que tu parlais ?
Si c'est juste parce que strtok() modifie la chaîne, je pense que tes préjugés sont injustifiés.

1- tu n'a aucune idée de comment est implémenté CString
2- tu n'a aucune idée de comment est implémenté strtok

Imagine qu'un jours le code interne de CString change. Et la paf plus rien ne marche...
Tant qu'as faire, si je suis ta logique

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
std::string string("aze;az;r;t;y;u");
 char *pWord = strtok((char*)string.data(),";");
 
   while( pWord != NULL )
   {
        pWord = strtok( NULL, ";" );
   }

est correct....
Ben ça doit être l'une des pire chose à faire en C++; A mon avis

[Médinoc]

1. On se fout de l'implémentation, c'est la doc de GetBuffer()/ReleaseBuffer() qui est importante. Chez Microsoft comme chez la plupart des professionnels, si c'est documenté, ça ne doit pas changer (sauf cas de force vraiment majeure).
2. Là, il est possible que tu marques un point. Il faudrait que je relise la spécification de strtok()...
   Edit: La doc POSIX ne dit pas explicitement que strtok() et strtok_r() ne doivent rien modifier après la chaîne. Mais si une telle fonction faisait cela, elle serait inutilisable car elle ne permet pas de spécifier la taille de buffer (comme gets()).
   Il est donc raisonnable de supposer que cette fonction ne peut modifier que l'intérieur de la chaîne, comme la fonction fclean() qu'on trouve sur ce forum.
   Tant que cette hypothèse est vérifiée, strtok() sur un buffer de CString est safe.

GetBuffer()/ReleaseBuffer() est bien plus que std::string::data() : C'est un vrai mécanisme de verrouillage, d'où la nécessité du ReleaseBuffer().

[yan]

GetBuffer()/ReleaseBuffer() est bien plus que std::string::data() : C'est un vrai mécanisme de verrouillage, d'où la nécessité du ReleaseBuffer().

C'est donc pas propre de modifier la mémoire donné par GetBuffer()