Hi Angus,
That's two separate requirements. 1. A simple iterator. By 'simple', you mean one using the underlying API. Right?
The standard fs::directory_iterator iterates over everything (files, directories, links, devices) in a directory. My assumption is that most applications are only interested in a subset of the entries and that the filtering in most cases is "simple". e.g. only files ending with ".txt" or only directories. This has nothing to do with the underlying API. Currently I have to do somthing like this for portable code. for (fs::directory_iterator itr(p); p!= fs::direcory_iterator(); ++p) if (fs::is_directory(p, true) || // my own non-throwing overload #ifdef BOOST_POSIX fs::extension(p) == ".txt" #else algorithm::iequals(fs::extension(p), ".txt") #endif ) constinue; ... I have no problem with the above code but I was hoping that the glob_iterator would simplify it. It just seem like an overkill to pull in a glob/regex parser to just match "*.txt" on files in one directory when that function is already available in both windows "FindFirstFile" and posix "fnmatch".
Again, how do you *limit* them? That implies that you must prescan the pattern, presumably throwing once you've determined that the thing is breaking your "reasonable" limits.
For me it is enough if the pattern is just passed to FindFirstFile/fnmatch without parsing. An option could be to do it like the fs library and have different pattern checkers (e.g. native, posix, windows, portable). Since your library is intended for much more complicated things than what I have ever had the need for I think I end the discussion here. Good Luck with your library submission.