-
Notifications
You must be signed in to change notification settings - Fork 182
FAQ
A: Especially when using the fs::recursive_directory_iterator the iteration often is stopped by an exception due to missing access rights.
Often in forums the suggestion is then to wrap the loop or the inside of the loop with try-catch to handle these cases, but
as long as there are no memory issues or the filesystem is corrupt, the easiest way is the rarely seen in real-world-projects
option skip_permission_denied. To use this
for (auto& de : fs::recursive_directory_iterator(dir, fs::directory_options::skip_permission_denied)) {
// .. do something
}Still it might be useful to explicitly handle errors, in that case a regular for loop should be used, where
the use of the increment(std::error_code& ec) method allows to increment the iterator exception-less.
Q: Is there a way to reduce overhead per usage and avoid getting all kinds of system includes dragged into global namespace by using ghc::filesystem?
A: ghc::filesystem can not hide its implementation details when used in header-only mode. Using it as forwarding/implementation pair helps avoiding these issues.
There are additional helping headers included within the include directory, to help with separation of the system specific details out of ghc::filesystem. Including <ghc/fs_fwd.hpp> everywhere but one cpp of the project, and including <ghc/fs_impl.hpp> inside that one, keeps almost all of the system specific headers inside that cpp. An easy way is to add an extra cpp to the project (e.g. filesystem.cpp) and just include <ghc/fs_impl.hpp> in there and linking that to the project.
Q: When using filenames or path names with international characters I can't access my files or directories.
A: ghc::filesystem was created with UTF8-everywhere in mind.
The implementation supports UTF16 or UTF32 strings as well, but all std::string interfaces are expecting or returning UTF8 encoded strings and expect to run on a system with UTF8 (for POSIX backends). Even when using C++20, where the new char8_t and std::u8string was introduced, are following that principle, for ghc::filesystem these types are expected contain the same encoding. I admit, this is not always the best way to handle things, but I simply would not want to open the can of worms of supporting every encoding out there
and in practice it works pretty well. Still, this might be a reason ghc::filesystem is not the right solution for your project.