Bonjour,
Je souhaiterais récupérer, dans un tableau, la liste de tous les fichiers *.txt présents dans un répertoire de Windows, pour pouvoir les ouvrir un par un et leur appliquer un traitement.
Comment dois-je m'y prendre ?
Merci.
Tapiou.
Version imprimable
Bonjour,
Je souhaiterais récupérer, dans un tableau, la liste de tous les fichiers *.txt présents dans un répertoire de Windows, pour pouvoir les ouvrir un par un et leur appliquer un traitement.
Comment dois-je m'y prendre ?
Merci.
Tapiou.
Boost.Filesystem serait tout indiqué dans cette situation.
Voici, pour exemple, un code qui affiche tout les fichiers présents dans un répertoire.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18 #include <boost/filesystem.hpp> #include <iostream> int main(int argc, char* argv[]) { if(argc == 2) { boost::filesystem::path directory(argv[1]); if(boost::filesystem::exists(directory) && boost::filesystem::is_directory(directory)) { boost::filesystem::directory_iterator begin(directory); boost::filesystem::directory_iterator end; while(begin != end) { std::cout << *begin << " "; ++begin; } std::cout << "\n"; } }
Merci pour la réponse mais sans utiliser boost, est-ce que c'est possible ?
Tapiou.
Il est quand même ahurissant qu'une librairie <filesystem> ne soit toujours pas présente dans C++11...
Je suis parfaitement d'accord. J'attend avec impatience qu'un nouveau technical report (TR2?) soit publier et vienne combler les lacunes de la bibliothèque standard. Il ne manque pas qu'une bibliothèque de gestion des systèmes de fichier, il est grand temps d'avoir une bibliothèque complète de gestion du temps et des dates (basé sur std::chrono?), un système de signal/slot et peut-être même une bibliothèque de communication par socket (je sais, je pousse un peut le bouchon...).
Personnellement, je crois que C++11 est venu apporter énormément au langage mais que, à présent, il est temps de se consacrer à la bibliothèque standard.
@cob59: La quasi-totalité du TR2 n'est pas inclue au C++11, ca sera plus probablement pour la prochaine version de la norme, dans pas trop longtemps (comparé au temps séparant les deux normes précédentes).
Et pour mon problème initial :
Je souhaiterais récupérer, dans un tableau, la liste de tous les fichiers *.txt présents dans un répertoire de Windows, pour pouvoir les ouvrir un par un et leur appliquer un traitement. Sans utiliser boost.
Est-ce quelqu'un pourrait m'aider ?
Merci.
Salut,
FindFirstFile et ses copains sont tes amis (F.A.Q Win 32 : Comment lister le contenu d'un dossier ?)
:
Code:
1
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 #include <windows.h> #include <iostream> #include <string> template<class op_t> void process_files(std::wstring path_, op_t op) { HANDLE hdl; WIN32_FIND_DATA fd_data; hdl = FindFirstFile(path_.c_str(), &fd_data); if (hdl != INVALID_HANDLE_VALUE) { do { op(fd_data.cFileName); }while (FindNextFile(hdl, &fd_data)); FindClose(hdl); } } struct print_file { void operator()(std::wstring file_name_) { std::wcout<<file_name_<<"\n"; } }; int main() { process_files(L"C:\\some\\dir\\*.txt",print_file()); return 0; }
Super !
Merci pour la réponse 3DArchi.
Tapiou.
Pas forcément...
Tu peux parfaitement fournir des règles dont l'implémentation sera effectivement du système ou de l'implémentation ;)
Regarde, simplement, l'implémentation des flux d'entrée / sortie standard, des tailles des types primitifs ou des allocateurs : il y a déjà une grande partie de l'implémentation qui est système dépendante car la "sortie standard", la taille des primitifs ou la gestion de mémoire se fait de manière fort différente (un simple exemple : la console nux et la console windows n'utilisent déjà pas le meme standard!!! Sans parler de tous ces systèmes qui n'utilisent pas une console, mais... autre chose :D )
Il n'empêche que, cout est défini par la norme comme étant le périphérique de sortie standard, et que tout fonctionne de manière parfaitement standard :D
La norme pourrait parfaitement définir l'ensemble des comportements dont, au final, seul celui correspondant à la récupération de la chaine de caractères représentant le chemin d'accès (et le nom du fichier) serait système dépendant!!!
Je présumes que c'est uniquement par manque de temps et parce que l'on parlait déjà de la "nouvelle norme" depuis trop longtemps (il aura vraiment fallu très longtemps pour qu'elle sorte: on en parle déjà depuis plus de cinq ans !!! ) qu'ils ont préféré supprimer certaines parties, dont <filesystem>.
Si tu remontes aux messages qui datent de deux ou trois ans dans ce forum, tu constateras, par exemple, que c'est le sort qu'ont subit plusieurs nouvelles fonctionnalités, telles que les concepts, par exemple ;)
Cela ne veut absolument pas dire que ce soit définitivement abandonné, cela veut simplement dire que c'est reporté "sine die" (en gros, jusqu'à la prochaine refonte, qu'elle prenne la forme d'un technical report, ou celle de la prochaine révision en profondeur ;) )
D'une certaine façon, les flux sont des concepts plus hauts qu'un système de fichier. Je peut avoir des flux sur un système embarqué (par exemple pour les périphériques d'E/S) sans pour autant avoir de notion de fichiers.
Oui, j'en suis bien conscient, mais...
N'oublie pas que tu as les *fstream qui sont explicitement des flux sur des fichiers, ce qui introduit quand meme un peut la notion de fichiers (bien que n'étant pas spécialiste de l'embarqué, je ne sais pas si ces flux là sont absents ou non :aie:)
Les flux E/S en embarqué restent malgré tout le parfait exemple d'implémentation laissée au choix de l'implémentation ;)
Je n'aurais, personnellement, aucune objection au fait que <filesystem> soit intégré en subissant les mêmes "restrictions" que celle que l'on trouve (peut etre, car je n'ai pas vérifié comment cela apparait dans la norme) pour *fstream ;)
Maintenant, n'ayant (du tout) pas suivi les débats du comité sur ce point, il y a peut d'être d'autres raisons (certainement des plus valables :D) qui l'auront incité à ne pas intégrer filesystem dans la SL :aie: