Récupérer le contenu d'un fichier texte ? [C] [réglé] - C - Programmation
Marsh Posté le 16-06-2005 à 13:45:39
Oui c'est du C pour le test, mais mon appli finale est en C++, je ne suis donc pas limité aux primitives C ...
Des idées ?
Marsh Posté le 16-06-2005 à 13:48:11
ben fais le en C++ alors avec des std::string et VERIFIE que les fonctions d'E/S n'échoue pas (si tu sors une seule fois un eof, je me casse)
Marsh Posté le 16-06-2005 à 13:53:45
Ca a l'air tellement simple (je ne manipule pas souvent les chaines de caractères, c'est pour ça que je ne connais que le scanf ), je vais chercher sur google , en tout cas tu me confirmes que j'aurais toutes les opérateurs pour faire ce que je souhaite ?
Merci en tout cas !
PS : pourquoi les fonctions d'IO échoueraient ?
Marsh Posté le 16-06-2005 à 15:16:05
Je déplace dans [C] car en C++ c'est un peu lourd je trouve !
Edit : bon j'ai trouvé une méthode qui marche, à base de gros fseek des familles !
Code :
|
C'est moche mais ça marche ! En attendant de trouver mieux, au moins je peux avancer
Marsh Posté le 16-06-2005 à 18:11:50
et bien pris pour que ton fichier soit bien formé ... parce que là c'est n'importe quoi
Marsh Posté le 16-06-2005 à 19:22:44
C'est ni du C++, ni du C. C'est portnawak.
Je me permets de commenter :
Code :
|
Citation : |
C'est pire que ça.
Avancer sur une telle base, c'est courir à la catastrophe. Enfin "courir à la catastrophe", disons plutôt que tu viens de t'asperger d'essence, habillé par un pagne en paille, en train de tourner tes saucisses sur le barbecue, et que non content de la situation, tu décides d'allumer une clope en prime.
Sérieusement, commence par une base solide et bien plus saine que cela, parce que là c'est ignoble.
Vu ton fichier, je lirais tout bêtement le fichier ligne à ligne, en stockant au passage toutes les lignes non vides, pourquoi pas dans une liste chaînée.
Je me débrouillerais ensuite pour tester l'intégrité des données lues.
Une fois ça fait, le plus dur est passé. Il suffit de compléter la liste chaînée, et de la stocker dans un nouveau fichier.
Marsh Posté le 16-06-2005 à 19:55:44
je ne suis pas d'accord pour
stat_file = "test";
c'est moche oui, mais le comportement n'est pas indefinis, tu affecte au pointeur l'adresse d'un tableau constant
Marsh Posté le 17-06-2005 à 00:14:52
- Oui oui pour le stat_file = "test", pas de soucis de mémoire, on mets juste à jour le pointeur vers une zone prédéfinie par le compilo !
Mais bon c'est pas fait comme ça dans le vrai soft (passage du nom par parametre, là c'est un soft de test !
- J'avais bien oublié le offset = 0 au début (pas vu car sous windows c'était mis à 0 sans init) !
- le r+, c'est parceque la suite de mon soft réécrit les infos, mais bon c'est pas mis dans la partie de test en effet
- pour fgets(), je ne connaissais pas, je vais regarder
- Et en effet, fichier mal formaté = cata
Merci pour ton analyse
J'ai fait quelques simplifications/protections
Code :
|
Marsh Posté le 18-06-2005 à 09:13:55
Je rappelle que Taz a écrit
Citation : (si tu sors une seule fois un eof, je me casse) |
==> fgets...
Tout cela est bien moche, en effet.
Marsh Posté le 18-06-2005 à 13:54:08
C'est ça, le code qui va se retrouver dans ton appli ? Et tu dis dans le titre du topic que ton pb est réglé ??
Marsh Posté le 20-06-2005 à 09:42:23
En effet le code est pourri, mais pour l'instant, comme il fonctionne et qu'il est protégé, je me concentre sur d'autres problèmes !
Je pense que la solution que m'a donné Elmoricq (merci beaucoup Elmoricq au fait ) est la plus propre (lire toutes les lignes et les stocker soit dans une liste chainée, soit dans une structure), je réécrirai le code de cette façon quand le reste fonctionnera !
Marsh Posté le 16-06-2005 à 13:29:36
Bonjour, je viens vous demander un peu d'aide car là je sèche
Petit détail de ce que je veux faire :
J'ai un fichier nommé "test" (juste pour l'instant hein ) qui contient des infos que je dois analyser (une en tout cas), et des trous à remplir par l'application !
Le fichier se présente comme celà au début (balises de changement de ligne type unix) :
J'ai choisi (mauvais choix ) de récupérer les informations non connues par mon appli et de reconstruire le fichier de zéro, ca m'a semblé le plus simple vu que l'appli met à jour ce fichier assez souvent !
j'ai fait un fichier de test pour vérifier mon analyse du fichier :
et voilà, mon problème c'est que quand le fichier est dans son état initial, la ligne pour lire les infos qui m'interessent est :
mais par la suite mon application modifie le fichier pour compléter les parties vides, et quand le fichier est completement rempli, la ligne qui lit correctement le fichier est alors :
exemple de fichier "test" rempli :
Le problème (ou j'ai cherché un moment) vient du fait que fscanf considère les retours chariots comme du vent et passe aux prochaines infos utiles => pleins de retours chariot sont équivalent à un espace par exemple ! Ca n'arrange pas du tout mes affaires, donc si vous aviez un piste pour que je m'en sorte, ça serait cool (par exemple un balise type %[] pour que fscanf considère les \n comme de l'info ou éventuellement un approche différente basée sur autre chose que du fscanf )
Merci d'avance
Sylver
Message édité par _Sylver_ le 16-06-2005 à 16:48:35