1

If I have a folder that has, say, 5 sub-folders, and I want to search for certain files inside each sub-folder(my program is present inside the main folder). How do I make my program traverse into and out of those folders in C++?

I need my program to run on Windows platforms.

Thanks!

Björn Pollex
  • 75,346
  • 28
  • 201
  • 283
Lockhead
  • 2,423
  • 7
  • 35
  • 48
  • [](https://en.cppreference.com/w/cpp/filesystem) has made it into C++17 standard; check it out. – KaiserKatze Mar 12 '20 at 03:33
  • Appears to be a duplicate of [How can I get the list of files in a directory using C or C++? - Stack Overflow](https://stackoverflow.com/questions/612097/how-can-i-get-the-list-of-files-in-a-directory-using-c-or-c) – user202729 Sep 02 '21 at 13:55

3 Answers3

3

The most obvious route is to use FindFirstFile and FindnextFile, along with SetCurrentDirectory. One obvious way to traverse the subdirectories is to make your directory traversal routine recursive.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
  • 2
    If I wanted to use those terrible, terrible Windows functions I'd just use C#. – Lockhead Mar 26 '11 at 21:13
  • 3
    If you *didn't* want to use the Windows API, it probably would have made sense to mention that in the question. One alternative would be `boost::filesystem`. http://www.boost.org/doc/libs/1_46_0/libs/filesystem/v3/doc/index.htm – Jerry Coffin Mar 26 '11 at 21:16
  • Isn't there any way to traverse without non-standard libraries? – Lockhead Mar 26 '11 at 21:19
  • There has to be some way. If there isn't, how was boost::filesystem made? – Lockhead Mar 26 '11 at 21:24
  • 1
    No, there doesn't. Boost::filesystem simply includes non-portable code for a number of underlying systems (e.g., one for POSIX, another for Win32, etc.) Realistically, given the systems in significant use today, POSIX and Win32 probably covers as much as most people are likely to care about. – Jerry Coffin Mar 26 '11 at 21:27
  • I'm pretty sure that boost also uses the Windows API to check the file system ;) – Roy T. Mar 26 '11 at 21:29
  • Well then, how is the Windows API written? – Lockhead Mar 26 '11 at 21:52
  • 1
    @MisterSir Windows is a C program written by software developers at Microsoft. – David Heffernan Mar 26 '11 at 21:56
  • @MisterSir: entirely non-portably. The Win32 API functions talk to a native NT function (probably `zwQueryDirectoryFile`). That will go through several layers (I/O manager, file system driver, device class driver, possibly some filter drivers, and eventually down to a device minidriver) to read the actual directory data from the disk. Unless you're going to write device drivers (or use the native API) none of that matters much though. – Jerry Coffin Mar 26 '11 at 22:02
  • Using the native API sounds interesting.. How do I do that? – Lockhead Mar 26 '11 at 22:05
  • @mistersir why would you want to? Why don't you use the functions that windows offers? Are you trying to make life hard for yourself? – David Heffernan Mar 26 '11 at 22:09
  • I'm trying to make life interesting :D This is all for educational purposes, obviously. The more to learn the better! – Lockhead Mar 26 '11 at 22:09
  • 1
    @MisterSir: Googling for "NT native API" should turn up at least a few results. It's not officially documented though, and the people who had released much of what was available have since been bought out by MS, and it's now generally much more difficult to find. If memory serves, you can extrapolate a fair amount for the Windows DDK documentation. Without a lot better reason than this, however, using the native API strikes me as pretty ridiculous. – Jerry Coffin Mar 26 '11 at 22:11
  • I suppose I should add that it's possible to bypass most of that in a slightly different direction: you can use CreateFile to open an entire partition using a name like `\\.\\X:`, and read raw sectors from there. It's then up to you to decode the contents and find the data you care about. For FAT/FAT32, that's fairly easy; for NTFS it's *much* less trivial (to put it mildly). – Jerry Coffin Mar 26 '11 at 22:18
  • Jerry, could you show me how do to something like that? It sounds really interesting! – Lockhead Mar 27 '11 at 11:30
3

Just use boost's recursive_directory_iterator, and filter the files/directory you want.

boost::filesystem::recursive_directory_iterator iter("your\path");
boost::filesystem::recursive_directory_iterator end;
for (; iter != end; ++iter) {
    // check for things like is_directory(iter->status()), iter->filename() ....
    // optionally, you can call iter->no_push() if you don't want to
    // enter a directory
    // see all the possibilities by reading the docs.
}
BatchyX
  • 4,986
  • 2
  • 18
  • 17
-1

Just use a stack and implement Depth-First-Search (see wiki) http://en.wikipedia.org/wiki/Depth-first_search

This way you can (with a small as possible stack) traverse any tree like structure (and Windows' file system is tree-like).

Roy T.
  • 9,429
  • 2
  • 48
  • 70
  • Or you let the compiler handle the stack and just use recursion. – Björn Pollex Mar 26 '11 at 21:23
  • That's a really odd comment since DFS can both be implemented using recursion and using a for-loop and your own stack and I didn't push the question asker to any of the two implementations. For both implementations it's true that the stack (either your own or the call stack) is smaller with DFS than with BFS). – Roy T. Mar 26 '11 at 21:25
  • @Roy: I did not say recursion is the only way, I just believe that it is much simpler to implement using recursion. Compilers are really good these days, so anytime you can leave something up to the compiler, it is probably a good idea to do so (unless you have a specific reason to do otherwise). – Björn Pollex Mar 26 '11 at 21:32
  • it's not guaranteed that DFS will have a smaller stack than BFS. if walking a\very\long\path\toward\hell\like\this\one\except\hell\is\nicer\than\the\path_max\limitation, a DFS's stack will get as much entry as there is recursion, where BFS will only have one stack entry at a time if this directory thread is the sole one. – BatchyX Mar 26 '11 at 21:34
  • Well it's true that compilers can optimize a lot more than humans these days, but recursion is really hard to optimize since the interesting stuff happens at run time, recursion can not be analyzed thoroughly at compile time I think. It would make for an interesting topic. – Roy T. Mar 26 '11 at 21:36
  • this is a rather pointless discussion. Who cares about such optimisations when you are traversing a file system? I don't thinks the CPU is going to be the bottleneck. Using the stack results in simple to understand code. That's good enough for me. – David Heffernan Mar 26 '11 at 21:46