filesystem
v1.5.14
ghc::filesystem::ifstream ， ghc::filesystem::ofstream ， ghc::filesystem::fstreamghc::filesystem::u8arguments这是一个仅基于C ++ 17和C ++ 20规格的仅标头单文件std::filesystem兼容辅助库库，但针对C ++ 11，C ++ 14，C ++ 17或C ++ 20（遵循C ++ 17的紧密遵循C ++ 17，遵循C ++ 17的紧密记录，很少有记录的标准）。目前已在MACOS 10.12/10.14/10.15/11.6，Windows 10，Ubuntu 18.04，Ubuntu 20.04，Centos 7，Centos 7，Centos 8，FreeBSD 12，Alpine ARM/ARM64 Linux和Solaris 10中进行测试，但只要您至少可以使用C++Compatible Commible Commible Complible compitible Commible and Solaris 10。它应该与Android NDK，Emscripten和我什至有报道有关iOS上使用的报告（在沙盒限制内），并且与v1.5.6进行了对QNX的实验支持。 Android NDK，Emscripten，QNX的支持，并且由于1.5.14 GNU/Hurd和Haiku并未得到自动测试的支持，但也欢迎提供PRS和BUG报告，并且据报道它们可以正常工作。当然，它在其自己的命名空间ghc::filesystem中不干扰常规的std::filesystem ，如果您在混合的C ++ 17环境中使用它（可能是可能的）。
测试覆盖范围远高于90％，从v1.3.6开始，并在v1.5.0中投入了更多时间来进行基准测试和优化图书馆的某些部分。我将尝试继续优化某些零件和重构其他零件，只要不引入其他C ++ 17/C ++ 20兼容性问题，就可以努力改进它。总是欢迎反馈。如果您看到缺少或错误或不按预期行为的情况，只需打开问题，我会发表评论。
我通常需要文件系统功能，主要是fs::path ，但目录访问也是如此，当我开始使用C ++ 11时，我使用该语言更新来减少我的第三方依赖性。我可以放下大部分使用的东西，但仍然错过了一些我开始实施的东西。最初，我将这些帮助者基于我自己的编码和命名惯例。当C ++ 17最终确定时，我想使用该界面，但是花了一段时间才推动自己转换我的课程。
该实施是基于C ++ 17标准的第30.10章，而接近该版本的草案是工作草案N4687。它来自C ++ 17的标准化之后，但与工作草案N4659相比，它包含最新的文件系统接口变化。使用v1.4.0凝视，使用C ++ 20编译时，它会根据路径排序顺序和std::u8string处理N4860的操作来适应更改。
我要感谢致力于改进C ++的人们，我真的很喜欢语言如何以C ++ 11和以下标准演变。保持良好的工作！
如果您问自己， ghc代表是什么，那只是gulraks helper classes ，是的，我知道，不是很有想象力，但是我想要一个短名称空间，并且在我的某些私人课程中使用了它（所以它与Haskell无关，对不起，对Clash的名字clash）。
ghc::filesystem是在MACOS上开发的，但是在MACOS，Windows，各种Linux发行版，FreeBSD和Solaris上的v1.5.12上测试了CI。它应该使用C ++ 11强的编译器对其中的任何一个工作。另外，还有一些检查可以更好地在Android上工作，但是由于我目前没有使用Android NDK测试，因此我不称其为受支持的平台，对于与Emscripten一起使用它也是有效的。现在它是检测到的平台的一部分，我解决了明显的问题并进行了一些测试，因此应该没问题。总而言之，我看不到它替换完整的C ++ 17或C ++ 20的std::filesystem ，它不会尝试成为“更好的” std::filesystem ，如果您不能使用它，则几乎可以下车（除UTF-8偏好外）。
重要的是：该实现遵循“无处不在的UTF-8”哲学，因为所有std::string实例都将被解释与std::u8string编码Wise和在UTF-8中相同。 std::u16string将被视为UTF-16。有关更多信息，请参见API的差异。
目前运行的单位测试：
标题配备了一组单位测试，并将CMAKE用作构建工具，而Catch2作为测试框架。所有测试均在CMAKE中注册，因此CTEST突击队可用于运行测试。
所有针对此实施的测试都应成功，具体取决于您的环境，可能会有一些警告，例如，如果您没有在Windows上创建符号链接或至少是测试的权利，那么这些都只是有益的。
从MACOS或Linux下的项目目录内部构建测试：
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Debug ..
make
ctest这会生成运行测试的测试二进制文件，最后一个命令执行它们。
如果默认编译器是GCC 8或更新或更新的较新的编译器，则它还尝试构建针对GCC/Clangs std::filesystem实现的测试二进制编译版本，称为std_filesystem_test ，作为额外的测试。理想情况下，所有测试都应通过所有文件系统实现进行编译并取得成功，但实际上，行为存在一些差异，有时由于标准中的解释空间，并且这些实现也可能存在问题。
最新版本的版本是v1.5.14，可以在此处找到源档案。
最新的本地前后版本是v1.4.0，可以在此处找到源档案。
最新的Pre-C ++ 20支持版本是v1.3.10，可以在此处找到源档案。
当前，只有最新的次要版本版本会收到错误缀），因此，如果可能的话，您应该使用最新版本。
由于ghc::filesystem首先是仅标头库，因此将标题或include/ghc目录复制到您的项目文件夹中或指向您的inceply inclage to to filesystem.hpp hepp hepter（或ghc/filesystem.hpp ）应该足以将其复制到您的项目文件夹中。
一切都在命名空间ghc::filesystem中，因此仅作为后备可能是：
# if _MSVC_LANG >= 201703L || __cplusplus >= 201703L && defined(__has_include)
// ^ Supports MSVC prior to 15.7 without setting /Zc:__cplusplus to fix __cplusplus
// _MSVC_LANG works regardless. But without the switch, the compiler always reported 199711L: https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/
# if __has_include(<filesystem>) // Two stage __has_include needed for MSVC 2015 and per https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
# define GHC_USE_STD_FS
// Old Apple OSs don't support std::filesystem, though the header is available at compile
// time. In particular, std::filesystem is unavailable before macOS 10.15, iOS/tvOS 13.0,
// and watchOS 6.0.
# ifdef __APPLE__
# include < Availability.h >
// Note: This intentionally uses std::filesystem on any new Apple OS, like visionOS
// released after std::filesystem, where std::filesystem is always available.
// (All other __<platform>_VERSION_MIN_REQUIREDs will be undefined and thus 0.)
# if __MAC_OS_X_VERSION_MIN_REQUIRED && __MAC_OS_X_VERSION_MIN_REQUIRED < 101500
|| __IPHONE_OS_VERSION_MIN_REQUIRED && __IPHONE_OS_VERSION_MIN_REQUIRED < 130000
|| __TV_OS_VERSION_MIN_REQUIRED && __TV_OS_VERSION_MIN_REQUIRED < 130000
|| __WATCH_OS_VERSION_MAX_ALLOWED && __WATCH_OS_VERSION_MAX_ALLOWED < 60000
# undef GHC_USE_STD_FS
# endif
# endif
# endif
# endif
# ifdef GHC_USE_STD_FS
# include < filesystem >
namespace fs = std::filesystem;
# else
# include " filesystem.hpp "
namespace fs = ghc::filesystem;
# endif如果您还要使用带有path支持作为后备的fstream包装器，则可以使用：
# if _MSVC_LANG >= 201703L || __cplusplus >= 201703L && defined(__has_include)
// ^ Supports MSVC prior to 15.7 without setting /Zc:__cplusplus to fix __cplusplus
// _MSVC_LANG works regardless. But without the switch, the compiler always reported 199711L: https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/
# if __has_include(<filesystem>) // Two stage __has_include needed for MSVC 2015 and per https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
# define GHC_USE_STD_FS
// Old Apple OSs don't support std::filesystem, though the header is available at compile
// time. In particular, std::filesystem is unavailable before macOS 10.15, iOS/tvOS 13.0,
// and watchOS 6.0.
# ifdef __APPLE__
# include < Availability.h >
// Note: This intentionally uses std::filesystem on any new Apple OS, like visionOS
// released after std::filesystem, where std::filesystem is always available.
// (All other __<platform>_VERSION_MIN_REQUIREDs will be undefined and thus 0.)
# if __MAC_OS_X_VERSION_MIN_REQUIRED && __MAC_OS_X_VERSION_MIN_REQUIRED < 101500
|| __IPHONE_OS_VERSION_MIN_REQUIRED && __IPHONE_OS_VERSION_MIN_REQUIRED < 130000
|| __TV_OS_VERSION_MIN_REQUIRED && __TV_OS_VERSION_MIN_REQUIRED < 130000
|| __WATCH_OS_VERSION_MAX_ALLOWED && __WATCH_OS_VERSION_MAX_ALLOWED < 60000
# undef GHC_USE_STD_FS
# endif
# endif
# endif
# endif
# ifdef GHC_USE_STD_FS
# include < filesystem >
namespace fs {
using namespace std ::filesystem ;
using ifstream = std::ifstream;
using ofstream = std::ofstream;
using fstream = std::fstream;
}
# else
# include " filesystem.hpp "
namespace fs {
using namespace ghc ::filesystem ;
using ifstream = ghc::filesystem::ifstream;
using ofstream = ghc::filesystem::ofstream;
using fstream = ghc::filesystem::fstream;
}
# endif现在您有EG fs::ofstream out(somePath);它是包装纸或C ++ 17 std::ofstream 。
请注意，作为仅限标题库，它并没有隐藏它使用系统的事实，因此它们“污染”了您的全局名称空间。使用基于转发/实现头的方法（请参见下文）避免这种情况。对于Windows，它需要Windows.h ，在包含filesystem.hpp或fs_std.hpp标头之前，定义WIN32_LEAN_AND_MEAN或NOMINMAX可能是一个好主意，以减少您的全局名称空间的污染和编译时间。它们不是由ghc::filesystem定义的，以与需要完整Windows.h上下文组合。
提示：还有一个名为ghc/fs_std.hpp的标题，它实现了文件系统实现的动态选择，当您想要std::filesystem时，您可以将其包含在内，而不是ghc::filesystem ghc/filesystem.hpp 。
另外，从v1.1.0 ghc::filesystem开始也可以通过包括其他两个包装器标头之一来使用。这些允许在大多数位置（ ghc/fs_fwd.hpp ）中包含转发版本，而将实现详细信息隐藏在单个CPP文件中，其中包括ghc/fs_impl.hpp来实现所需的代码。使用ghc::filesystem以这种方式确保系统包含仅在CPP文件中可见，所有其他位置均干净。
请注意，当前不支持将实现隐藏到Windows-dll中，因为接口中具有C ++标准模板的DLL接口是不同的野兽。如果有人愿意尝试一下，我可能会整合一个PR，但目前正在研究自己并不是当务之急。
如果使用转发/实现方法，您仍然可以使用这样的动态切换：
# if _MSVC_LANG >= 201703L || __cplusplus >= 201703L && defined(__has_include)
// ^ Supports MSVC prior to 15.7 without setting /Zc:__cplusplus to fix __cplusplus
// _MSVC_LANG works regardless. But without the switch, the compiler always reported 199711L: https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/
# if __has_include(<filesystem>) // Two stage __has_include needed for MSVC 2015 and per https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
# define GHC_USE_STD_FS
// Old Apple OSs don't support std::filesystem, though the header is available at compile
// time. In particular, std::filesystem is unavailable before macOS 10.15, iOS/tvOS 13.0,
// and watchOS 6.0.
# ifdef __APPLE__
# include < Availability.h >
// Note: This intentionally uses std::filesystem on any new Apple OS, like visionOS
// released after std::filesystem, where std::filesystem is always available.
// (All other __<platform>_VERSION_MIN_REQUIREDs will be undefined and thus 0.)
# if __MAC_OS_X_VERSION_MIN_REQUIRED && __MAC_OS_X_VERSION_MIN_REQUIRED < 101500
|| __IPHONE_OS_VERSION_MIN_REQUIRED && __IPHONE_OS_VERSION_MIN_REQUIRED < 130000
|| __TV_OS_VERSION_MIN_REQUIRED && __TV_OS_VERSION_MIN_REQUIRED < 130000
|| __WATCH_OS_VERSION_MAX_ALLOWED && __WATCH_OS_VERSION_MAX_ALLOWED < 60000
# undef GHC_USE_STD_FS
# endif
# endif
# endif
# endif
# ifdef GHC_USE_STD_FS
# include < filesystem >
namespace fs {
using namespace std ::filesystem ;
using ifstream = std::ifstream;
using ofstream = std::ofstream;
using fstream = std::fstream;
}
# else
# include " fs_fwd.hpp "
namespace fs {
using namespace ghc ::filesystem ;
using ifstream = ghc::filesystem::ifstream;
using ofstream = ghc::filesystem::ofstream;
using fstream = ghc::filesystem::fstream;
}
# endif在实施中隐藏CPP中，您可以使用（在任何包含ghc/fs_fwd.hpp的包含之前，都要优先：
# if _MSVC_LANG >= 201703L || __cplusplus >= 201703L && defined(__has_include)
// ^ Supports MSVC prior to 15.7 without setting /Zc:__cplusplus to fix __cplusplus
// _MSVC_LANG works regardless. But without the switch, the compiler always reported 199711L: https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/
# if __has_include(<filesystem>) // Two stage __has_include needed for MSVC 2015 and per https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
# define GHC_USE_STD_FS
// Old Apple OSs don't support std::filesystem, though the header is available at compile
// time. In particular, std::filesystem is unavailable before macOS 10.15, iOS/tvOS 13.0,
// and watchOS 6.0.
# ifdef __APPLE__
# include < Availability.h >
// Note: This intentionally uses std::filesystem on any new Apple OS, like visionOS
// released after std::filesystem, where std::filesystem is always available.
// (All other __<platform>_VERSION_MIN_REQUIREDs will be undefined and thus 0.)
# if __MAC_OS_X_VERSION_MIN_REQUIRED && __MAC_OS_X_VERSION_MIN_REQUIRED < 101500
|| __IPHONE_OS_VERSION_MIN_REQUIRED && __IPHONE_OS_VERSION_MIN_REQUIRED < 130000
|| __TV_OS_VERSION_MIN_REQUIRED && __TV_OS_VERSION_MIN_REQUIRED < 130000
|| __WATCH_OS_VERSION_MAX_ALLOWED && __WATCH_OS_VERSION_MAX_ALLOWED < 60000
# undef GHC_USE_STD_FS
# endif
# endif
# endif
# endif
# ifndef GHC_USE_STD_FS
# include " fs_impl.hpp "
# endif提示：还有其他辅助助手标头，名为ghc/fs_std_fwd.hpp和ghc/fs_std_impl.hpp使用此技术，因此，如果您想动态选择Filesystem实现，则只需包含它们即可。
Starting from v1.1.0, it is possible to add ghc::filesystem as a git submodule, add the directory to your CMakeLists.txt with add_subdirectory() and then simply use target_link_libraries(your-target ghc_filesystem) to ensure correct include path that allow #include <ghc/filesystem.hpp> to work.
CMakeLists.txt提供了一些定制其行为的选项：
GHC_FILESYSTEM_BUILD_TESTING编译测试，用作subsodule时默认OFF不在else ON 。GHC_FILESYSTEM_BUILD_EXAMPLES编译示例，将默认OFF当作subsodule时，否则ON 。GHC_FILESYSTEM_WITH_INSTALL添加安装目标以构建，当用作subsodule时，默认值是OFF ON 。GHC_FILESYSTEM_BUILD_STD_TESTING编译std_filesystem_test ，与std::filesystem运行的测试套件的变体，默认为GHC_FILESYSTEM_BUILD_TESTING 。只有将编译器检测到能够做到这一点时才完成。GHC_FILESYSTEM_TEST_COMPILE_FEATURES可以将cxx_std_20设置为覆盖CMAKE_CXX_COMPILE_FEATURES filesystem_test_cpp20功能列表。请使用Hedronvision/Bazel-CC-Filesystem-Backport，它将自动为您设置所有内容。
如果将来的更改可能会使版本对此进行反应，则有一个版本的宏GHC_FILESYSTEM_VERSION定义了定义的版本，但我不打算破坏任何内容。它是十进制数字的版本(major * 10000 + minor * 100 + patch) 。
注意：仅在发布下一个版本时，仅将修补版本用于发行版，并且仅在提交之间使用奇数补丁版本。
除了下一节中所述的一些差异之外，此版本中几乎没有任何文档，因为任何std::filesystem文档都可以起作用。因此，您可以转到https://en.cppreference.com/w/cpp/filesystem，以描述此库的组件。
当使用C ++ 11，C ++ 14或C ++ 17编译时，API在可能的情况下遵循C ++ 17标准，除了std::string_view参数仅在C ++ 17上支持。使用C ++ 20编译时， ghc::filesysytem默认为C ++ 20 API，带有char8_t和std::u8string接口以及不推荐使用的fs::u8path Factory方法。
注意：如果应在C ++ 20模式下执行C ++ 17 API，请使用Define GHC_FILESYSTEM_ENFORCE_CPP17_API 。 Even then it is possible to create fws::path from std::u8string but fs::path::u8string() and fs::path::generic_u8string() return normal UTF-8 encoded std::string instances, so code written for C++17 could still work with ghc::filesystem when compiled with C++20.
此处记录了标准的唯一补充：
ghc::filesystem::ifstream ， ghc::filesystem::ofstream ， ghc::filesystem::fstream这些是围绕std::ifstream ， std::ofstream和std::fstream简单包装器。他们只需添加一个open()方法和一个带有ghc::filesystem::path参数的构造函数，因为C ++ 17中的fstream变体具有它们。
ghc::filesystem::u8arguments这是一个辅助类，当前在非Windows平台上检查UTF-8编码
::CommandLineToArgvW (::GetCommandLineW(), &argc)然后将它们转换为UTF-8，然后替换argc和argv 。这是一个类似警卫的课程，在超出范围时会恢复其变化。
因此，基本用法是：
namespace fs = ghc::filesystem;
int main ( int argc, char * argv[])
{
fs::u8arguments u8guard (argc, argv);
if (!u8guard. valid ()) {
std::cerr << " Bad encoding, needs UTF-8. " << std::endl;
exit (EXIT_FAILURE);
}
// now use argc/argv as usual, they have utf-8 encoding on windows
// ...
return 0 ;
}这样，只要main的范围有效，就可以对argv进行UTF-8编码。
注意：在MacOS上，在XCode下进行调试时，当前代码将返回false ，因为XCode以US-ASCII启动应用程序作为编码，无论实际使用什么编码，甚至在产品方案中设置LC_ALL都不会更改任何编码。我仍然需要调查。
由于此实现基于我的私人助手类中的现有代码，因此它得出了其一些限制。从v1.5.0开始，该差异与标准C ++ 17/C ++ 20 API之间的大部分差异。
该实现具有LWG缺陷＃2682，＃2935，＃2936和＃2937的可切换行为。 The currently selected behavior (starting from v1.4.0) is following #2682, #2936, #2937 but not following #2935, as I feel it is a bug to report no error on a create_directory() or create_directories() where a regular file of the same name prohibits the creation of a directory and forces the user of those functions to double-check via fs::is_directory if it really worked.较新的纸张WG21 P1164R0也提倡将目录创建以该名称为错误的文件创建更直观的方法，在KONA 2019会议上同意了修订P1161R1，请参阅Merge and GCC，现在已转换为遵循其提案（GCC＃86910）。
// methods in ghc::filesystem::path:
path& operator +=(basic_string_view<value_type> x);
int compare (basic_string_view<value_type> s) const ;这些并未在C ++ 11和C ++ 14下实现，因为没有std::basic_string_view可用，我确实想保持此实现自动化，并且不为C ++ 11/14编写完整的C ++ 17升级。从v1.1.0开始，当C ++ 20的C ++ 17下编译ghc::filesystem时，这些都得到了支持。
从v1.5.2 ghc::filesystem开始，将尝试使用std::experimental::basic_string_view在其中检测到可用性。此外，如果您具有basic_string_view兼容C ++ 11实现GHC_HAS_CUSTOM_STRING_VIEW std::basic_string_view实现导入ghc::filesystem namespace with：
namespace ghc {
namespace filesystem {
using my::basic_string_view;
}
}在包含文件系统标头之前。
为了不依赖任何外部第三方库，并且仍然保持便携式和紧凑，此实现遵循“ utf-8无处不在”理念，因为所有std::string实例都将被解释与std::u8string编码明智和在UTF-8中相同。 std::u16string将被视为UTF-16和std::u32string将被视为Unicode Codepoint。根据std::wstring字符的大小，它将将std::wstring处理为UTF-16（例如Windows）或char32_t UNICODE CODEPORTS（当前所有其他平台）。
从v1.5.0 ghc::filesystem开始，遵循C ++ 17标准，即使用wchar_t和std::wstring作为内部用于路径表示的类型。通过定义GHC_WIN_DISABLE_WSTRING_STORAGE_TYPE和get filesystem::path::string_type as std::string and filesystem::path::value_type as wchar_t as wchar_t 。
如果您需要使用v1.5.0及以上的一些Windows API调用Windows API，只需使用Windows-API调用的W-Variant（例如GetFileAttributesW(p.c_str()) ）。
注意：通过定义GHC_WIN_DISABLE_WSTRING_STORAGE_TYPE使用旧行为时，请使用path::wstring()成员（例如GetFileAttributesW(p.wstring().c_str()) ）。这为您提供了独立于UNICODE宏的Unicode变体，并使Windows，Linux和MacOS之间的共享代码更加容易，并且可以与std::filesystem和ghc::filesystem一起使用。
std::string path::u8string () const ;
std::string path::generic_u8string () const ;
vs.
std::u8string path::u8string () const ;
std::u8string path::generic_u8string () const ;这两种方法的返回类型取决于使用的C ++标准，如果定义了GHC_FILESYSTEM_ENFORCE_CPP17_API 。在C ++ 11，C ++ 14和C ++ 17上，或定义GHC_FILESYSTEM_ENFORCE_CPP17_API时，返回类型为std::string ，并且在没有定义的C ++ 20上，它是std::u8string 。
我创建了一个Wiki条目，内容涉及可能导致此处提及的不同std::filesystem实现之间的许多行为差异，但是此读数只试图解决ghc::filesystem与这些设计之间的设计选择差异。我尝试不时更新Wiki页面。
欢迎任何其他观察结果！
由于v1.5.0，该实现的完整内部力学fs::path在其中更改为本机格式为内部表示。创建Windows下方的任何混合斜线fs::path对象（例如，使用"C:foo/bar" ）通过generic_string() API通过native()和"C:/foo/bar"带领"C:foobar"带领干净路径。在所有平台上，即使标准和其他实现都不执行此操作，删除了冗余的其他分离器。
此外，此实现遵循标准建议，以处理Windows上"//host/path"和USC路径的POSIX路径，也具有root-name（例如"//host" ）。 GCC实施在Ubuntu 18.04上测试时没有选择这样做，而MACOS则使用GCC 8.1.0或Clang 7.0.0进行测试。此差异将显示为std::filesystem下的警告。这导致了operator/=(path& p) ，其中任何带有p.is_absolute()的路径p都会降低为作业，而此实现的例外是*this == *this.root_name()和p == preferred_separator将完成正常的附录，以便允许。
fs::path p1 = " //host/foo/bar/file.txt " ;
fs::path p2;
for ( auto p : p1) p2 /= p;
ASSERT (p1 == p2);对于所有非宿主领导路径，该行为将与标准描述的行为匹配。
作为Windows上的符号链接，由于Windows Vista（具有严格的安全性限制）或多或少受到支持，并且由于Windows 10的一些较早构建（当激活“开发人员模式”被激活时）很少使用（2018年），但很少使用，但仍受到此实施的支持。
Windows ACL权限功能很糟糕地转化为C ++ 17文件系统接口中使用的POSIX权限位蒙版。因此，当前在user级别合成file_status中返回的权限，并将其复制到group和other级别。仍然有一些与Windows许可系统进行更多互动的潜力，但是当前使用此实现的设置或阅读权限肯定不会导致预期的行为。
extension()确实返回了目录名称".."的非空结果。ghcFilesystem::ghc_filesystem现在无条件地设置stem()上， filename()和fs::path的extension() ，如果结肠在文件名中，将返回错误的结果fs::last_write_time(path, time, ec) iOS，TVOS和WatchOS上的设置器fs::directory_entry::refresh()现在，始终如一status()不会将符号链接到不存在的目标上，但是使该条目具有file_type::not_found作为类型EINTR ，以避免网络文件系统上的错误fs::copy_file()现在还复制了权限fs::copy_file()忽略skip_existing选项。dirent::d_type并修复构建配置和测试以支持Solaris作为新平台的系统上删除了GHC_NO_DIRENT_D_TYPE的需求。PATH_MAX ，则将定义一个。fs::remove_all现在只是删除符号链接而不是关注它们。fs::space ，其中可能会在乘法中发生数值溢出。fs::create_directories不再在长文件名上打破。ghc::filesystem处理的已安装文件夹/卷作为符号链接，导致fs::canonical在包含这些的路径上失败。recursive_directory_iterator将不会尝试输入DEAD SYMLINKS。fs::remove失败，另请参见（Microsoft/STL＃1511）有关Windows上的std::fs中的相应问题。GHC_NO_DIRENT_D_TYPE允许操作系统检测能够支持系统，而无需dirent.d_type成员，实验性的第一个QNX编译支持作为初始用例，固定问题的固定问题返回dt_unknown的文件系统（例如，reiserfs）。string_view支持。<ghc/fs_std.hpp>或<Availability.h> ghc/fs_std_fwd.hpp>/ <ghc/fs_std_fwd.hpp>或<ghc/fs_std.hpp>或<ghc/fs_std_impl.hpp> 。std::filesystem功能得到支持，因此使用标准章节号码是误导的，并由在版本上（大部分）保持一致的标签式章节名称所取代。recursive_directory_iterator的性能，在libc ++和libstdc ++之间的大树上的递归迭代。ghc::filesystem的增强功能现在对Cygwin具有初步支持。进行更改以允许测试成功地进行编译和运行（使用GCC 10.2.0测试），反馈和其他PRS欢迎，因为它目前不属于CI配置。GHC_FILESYSTEM_BUILD_STD_TESTING以覆盖std::filesystem测试的其他构建，以进行比较，并且有可能使用GHC_FILESYSTEM_TEST_COMPILE_FEATURES预填充使用comake_cxxx_coxx_cox__cypilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilesepilespilespile_feater CMAKE_CXX_COMPILE_FEATURESdirectory_entry Creation在用recursive_directory_iterator在较大的目录树上的测试中导致约20％-25％。wchar_t不在非Windows后端的支持char类型列表中。string_view支持可用于<string_view>或<experimental/string_view>在可用时使用，并在定义GHC_HAS_CUSTOM_STRING_VIEW时允许使用自定义basic_string_view实现实现，并将String View导入到ghc::filesystem namespace之前。std::filesystem测试现在与-lrt链接以避免问题。fs::hard_link_count的测试用例由于文件系统行为而失败，测试案例已被调整为考虑到这一点。GHC_FS_API和GHC_FS_API_CLASS现在在设置外部时被尊重以允许行为覆盖。make install文件。GHC_FILESYSTEM_BUILD_TESTING ， GHC_FILESYSTEM_BUILD_EXAMPLES和GHC_FILESYSTEM_WITH_INSTALL实现的情况，禁止在使用此this add_subdirectory时，可以将其设置为“ facter” fix，允许将它们设置为facte fix fix fix，允许将它们设置为它们。fs::path的Windows版本最初是由基于POSIX的实现创建的。这导致窗户上的fs::path内部的可变缓存，即使对于const方法，这本质上也不是线程安全。为了不在次优的解决方案中添加其他补丁，这次我将path代码重新设计为现在存储本机路径代表。这更改了很多代码，但是当与wchar_t结合使用时，作为value_type ，有助于避免了对Win-API的通话进行大量转换。fs::path::native()和fs::path::c_str()现在可以noexcept标准任务wchar_t是fs::path::value_type和std::wstring的默认值是fs::path::string_type的默认值。fs::path的const方法上的线程安全不再是问题GHC_WIN_DISABLE_AUTO_PREFIXES来禁用Windows上长路径的自动前缀，对于所有其他类型的前缀或名称空间，该行为遵循MSVC std::filesystem::path的行为。char / std::string的方法，则可以使用GHC_WIN_DISABLE_WSTRING_STORAGE_TYPE激活它fs::file_status的增强功能现在支持operator== std::filesystem中带有C ++ 20。fs::path::parent_path()有一个性能问题，因为它仍在使用基于循环的方法从元素中重新创建父级。这造成了许多临时性，尤其是在漫长的道路上太慢。char8_t和std::u8string在Source为参数类型的情况下支持U8Stringfs::path::u8string()和fs::path::generic_u8string()现在返回std::u8stringfs::path支持太空飞船操作员<=>GHC_FILESYSTEM_ENFORCE_CPP17_API ghc::filesystem将落回旧的fs::path::u8string()和fs::path::generic_u8string() api（如果首选）fs::proximate(p, ec)的BugFix，其中内部呼叫fs::current_path()不使用error_code变体，而是抛出可能的异常而不是设置ec 。LWG_2936_BEHAVIOUR现在正在打开。Source参数的问题。constexpr文件系统位掩码的位操作。__MAC_OS_X_VERSION_MIN_REQUIRED ，以确保仅在部署目标至少在catalina时才在MacOS上选择std::filesystem 。directory_iterator和recursive_directory_iterator的BugFix与skip_permission_denied选项有一个问题，这导致无法跳过MacOS上的SIP Protected文件夹。_MSVC_LANG的增强功能，除了__cplusplus ，在帮助标头中，即使在/Zc:__cplusplus不使用时，也可以在__cplusplus中使用。fs::exists false或fs::status上的false或未找到的eRrors。名称空间路径不再过滤。filesystem_test.cpp中的TestAllocator已完成，以满足使用devtoolset-9在CentOS 7上构建的要求。 Centos 7和Centos 8现在已成为CI构建的一部分。LWG_2936_BEHAVIOUR ，该开关允许启用C ++ 17 fs::path::compare行为，其中比较就像是元素明智的路径比较，如LWG 2936和C ++ 20 [fs.path.compare] 。它在v1.3.6中为默认值，并且将从v1.4.0开始，因为它会更改排序。std::fstream的wchar_t版本，如果将gcc与libc ++一起使用，则在Windows上使用Windows上的ghc::filesystem::fstream包装器。fs::directory_options::skip_permission_denied和使用Emscripten编译的初步支持时，更好地处理目录迭代器的权限问题。ghc::filesystem现在支持在残疾人异常的项目中使用。在此模式下，使用错误处理异常的API签名，感谢PR（此解决＃60和＃43）ERROR_FILE_TOO_LARGE常数而发生错误。fs::lexically_relative的bugfix并没有忽略基本参数的落后斜线，感谢PR＃57。fs::create_directories for n of Inde Indie true返回的bugfix，因为目录已经存在。error_code was not reset, if cached result was returned.fs::path from a stream.timespec fields to avoid warnings.ghc::filesystem is re-licensed from BSD-3-Clause to MIT license. (see #47)fs::rename on Windows didn't replace an existing regular file as required by the standard, but gave an error. New tests and a fix as provided in the issue was implemented.fs_fwd.hpp or fs_std_fwd.hpp there was a use of DWORD in the forwarding part leading to an error if Windows.h was not included before the header. The tests were changed to give an error in that case too and the useage of DWORD was removed.GetProcAddress gave a warning with -Wcast-function-type on MSYS2 and MinGW GCC 9 builds.CMakeLists.txt will automatically exclude building examples and tests when used as submodule, the configuration options now use a prefixed name to reduce risk of conflicts.ghcFilesystemConfig.cmake in ${CMAKE_INSTALL_LIBDIR}/cmake/ghcFilesystem for find_package that exports a target as ghcFilesystem::ghc_filesystem .error: redundant redeclaration of 'constexpr' static data member deprecation warning in C++17 mode.fs::create_directories , thanks for the PR!GHC_FILESYSTEM_WITH_INSTALL that is defaulted to OFF if ghc::filesystem is used via add_subdirectory .fs::path::lexically_normal() that leaves a trailing separator in case of a resulting path ending with .. as last element.BUILD_TESTING and BUILD_EXAMPLES to NO , OFF or FALSE .std::string_view when available was added.std::string_view is available.fs::path::preferred_separator declaration was not compiling on pre C++17 compilers and no test accessed it, to show the problem. Fixed it to an construction C++11 compiler should accept and added a test that is successful on all combinations tested.fs::copy_options where not forwarded from fs::copy to fs::copy_file in one of the cases.strerror_r signature was expected. The complex preprocessor define mix was dropped in favor of the usual dispatch by overloading a unifying wrapper.ghc::filesystem missed a <vector> include in the windows case.wchar_t/std::wstring interface when compiling on Windows with defined GHC_WIN_WSTRING_STRING_TYPE , this is default when using the ghc/fs_std*.hpp header, to enhance compatibility.GHC_RAISE_UNICODE_ERRORS (instead of replacing invalid code points or UTF-8 encoding errors with the replacement character U+FFFD ).fs::copy_file .readdir/readdir_r code of fs::directory_iterator ; as readdir_r is now deprecated, I decided to drop it and the resulting code is much easier, shorter and due to more refactoring fasterstd::filesystemfs::path::lexically_normal() had some issues with ".." -sequences.fs::recursive_directory_iterator could run into endless loops, the methods depth() and pop() had issues and the copy behavior and input_iterator_tag conformance was broken, added testsstd::filesystem builds of tests and examples for interoperability checks.fs::weakly_canonical() tests against std::fsdu example showing the recursive_directory_iterator used to add the sizes of files in a directory tree.fs::file_time_type test helpersfs::copy() now conforms LWG #2682, disallowing the use of `copy_option::create_symlinks' to be used on directorieshpp as extension to be marked as c++ and they where moved to include/ghc/ to be able to include by <ghc/filesystem.hpp> as the former include name might have been to generic and conflict with other files.ghc::filesystem now can be used as a submodul and added with add_subdirectory and will export itself as ghc_filesystem target. To use it, only target_link_libraries(your-target ghc_filesystem) is needed and the include directories will be set so #include <ghc/filesystem.hpp> will be a valid directive. Still you can simply only add the header file to you project and include it from there.ghc::filesystem declarations ( fs_fwd.hpp ) and to wrap the implementation into a single cpp ( fs_impl.hpp )std::basic_string_view variants of the fs::path api are now supported when compiling with C++17.ghc::filesystem::path::generic_string()filesystem.h was renamed filesystem.hpp to better reflect that it is a c++ language header.ghc::filesystem::remove() and ghc::filesystem::remove_all() both are now able to remove a single file and both will not raise an error if the path doesn't exist.ghc::filesystem::remove() under Windows.ghc::filesystem::directory_iterator now releases resources when reaching end() like the POSIX one does.ghc::filesystem::copy() and ghc::filesystem::remove_all fixed.ghc::filesystem::recursive_directory_iterator::difference_type .-Wall -Wextra -Werror and fixed resulting issues.fs.op.permissions test to work with all tested std::filesystem implementations (gcc, clang, msvc++).ghc::filesystem::u8arguments as argv converter, to help follow the UTF-8 path on windows. Simply instantiate it with argc and argv and it will fetch the Unicode version of the command line and convert it to UTF-8. The destructor reverts the change.examples folder with hopefully some usefull example usage. Examples are tested (and build) with ghc::filesystem and C++17 std::filesystem when available.std::filesystem for comparison.fstream include.timespec / timeval usage.chrono conversion issues in test and example on clang 7.0.0.ghc::filesystem::canonical now sees empty path as non-existant and reports an error. Due to this ghc::filesystem::weakly_canonical now returns relative paths for non-existant argument paths. （＃1）ghc::filesystem::remove_all now also counts directories removed (#2)recursive_directory_iterator tests didn't respect equality domain issues and dereferencapable constraints, leading to fails on std::filesystem tests.noexcept tagged methods and functions could indirectly throw exceptions due to UFT-8 decoding issues.std_filesystem_test is now also generated if LLVM/clang 7.0.0 is found. This was the first public release version. It implements the full range of C++17 std::filesystem , as far as possible without other C++17 dependencies.
