filesystem
v1.5.14
ghc::filesystem::ifstream , ghc::filesystem::ofstream , ghc::filesystem::fstreamghc::filesystem::u8arguments Это только заголовок, совместимая с однофилевой библиотекой std::filesystem , основанная на спецификациях C ++ 17 и C ++ 20, но реализована для C ++ 11, C ++ 14, C ++ 17 или C ++ 20 (жестко следуя стандартному C ++ 17 с очень небольшим задокументированным исключением). В настоящее время он тестируется на MacOS 10.12/10.14/10.15/11,6, Windows 10, Ubuntu 18.04, Ubuntu 20.04, Centos 7, Centos 8, Freebsd 12, Alpine Arm/Arm64 Linux и Solaris 10, но должны работать и в других системах, до тех пор, пока у вас есть, по крайней мере, C ++ 11 -совместный композитор. Он должен работать с Android NDK, Emscripten и я даже имели сообщения о том, что он использовался на iOS (в пределах ограничений на песочницу), и с v1.5.6 существует экспериментальная поддержка для QNX. Поддержка Android NDK, Emscripten, QNX, и, поскольку 1.5.14 GNU/Hurd и Haiku не поддерживаются автоматическим тестированием, но PRS и отчеты об ошибках также приветствуются для них, и они, как сообщается, работают. Конечно, в своем собственном пространстве имен ghc::filesystem не мешает обычной std::filesystem если вы используете ее в смешанной среде C ++ 17 (что возможно).
Тестовая охват значительно выше 90%, и начиная с V1.3.6, а в V1.5.0 было инвестировано в сравнительное значение и оптимизацию частей библиотеки. Я постараюсь продолжать оптимизировать некоторые части и рефакторировать другие, стремясь улучшить их, если они не вводят дополнительные проблемы C ++ 17/C ++ 20. Обратная связь всегда приветствуется. Просто откройте проблему, если вы видите что -то отсутствующее или неправильное или не ведет себя как ожидалось, и я прокомментирую.
Я часто нуждаюсь в функциональности файловой системы, в основном fs::path , но также доступа к каталогам, и когда я начинаю использовать C ++ 11, я использовал это языковое обновление, чтобы попытаться уменьшить свои сторонние зависимости. Я мог бы отбросить большую часть того, что я использовал, но все еще пропустил некоторые вещи, которые я начал реализовать для удовольствия. Первоначально я основал этих помощников на своих собственных соглашениях о кодировании и именах. Когда C ++ 17 был завершен, я хотел использовать этот интерфейс, но потребовалось некоторое время, чтобы подтолкнуть себя, чтобы преобразовать мои занятия.
Реализация тесно основана на главе 30.10 из стандарта C ++ 17, и проект, близкий к этой версии, является рабочим проектом N4687. Это из -за стандартизации C ++ 17, но он содержит последние изменения интерфейса файловой системы по сравнению с рабочим черновиком N4659. Глядя с v1.4.0, при составлении с использованием C ++ 20, он адаптируется к изменениям в соответствии с порядком сортировки путей и обработкой std::u8string из рабочего проекта N4860.
Я хочу поблагодарить людей, работающих над улучшением C ++, мне очень понравилось, как язык развивался с C ++ 11 и следующими стандартами. Держите хорошую работу!
Если вы спросите себя, за что стоит ghc , это просто gulraks helper classes , да, я знаю, не очень творческий, но я хотел короткое пространство имен, и я использую его в некоторых из моих частных классов (так что это не имеет ничего общего с Хаскеллом , извините за столкновение с именем).
ghc::filesystem разработана на MacOS, но CI протестирована на MacOS, Windows, различных дистрибутивах Linux, FreeBSD и начиная с V1.5.12 на Solaris. Он должен работать на любом из них с компилятором C ++ 11. Кроме того, есть некоторые проверки, чтобы мы надеемся, что лучше работать над Android, но, поскольку в настоящее время я не тестирую с Android NDK, я бы еще не назвал ее поддерживаемой платформой, то же самое действительна для использования с Emscripten. Теперь он является частью обнаруженных платформ, я исправил очевидные проблемы и запустил некоторые тесты с ним, так что это должно быть хорошо. В целом, я не вижу, чтобы она заменила std::filesystem , где доступна полная C ++ 17 или C ++ 20, она не пытается быть «лучшей» std::filesystem , просто практически выпущенной, если вы не можете использовать ее (за исключением предпочтения UTF-8).
Важно: эта реализация следует философии «UTF-8 повсюду» в том, что все экземпляры std::string будут интерпретироваться так же, как и std::u8string , кодируя и находятся в UTF-8. std::u16string будет рассматриваться как UTF-16. См. Различия в API для получения дополнительной информации.
Модульные тесты в настоящее время запускаются с:
Заголовок поставляется с набором единичных тестов и использует Cmake в качестве инструмента для сборки и Catch2 в качестве тестовой структуры. Все тесты зарегистрированы в Cmake, поэтому CTEST Commando может использоваться для запуска тестов.
Все тесты против этой реализации должны быть успешными, в зависимости от вашей среды, это может быть, что есть некоторые предупреждения, например, если у вас нет прав на создание символов на Windows или, по крайней мере, тест считает так, но они просто информативны.
Чтобы создать тесты изнутри каталога проекта под MacOS или Linux просто:
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Debug ..
make
ctestЭто генерирует тестовые двоичные файлы, которые запускают тесты, и последняя команда выполняет их.
Если компилятор по умолчанию является GCC 8 или более новее, или Clang 7 или более новее, он дополнительно пытается создать версию тестового двоичного составления с GCCS/Clangs std::filesystem реализация, названная std_filesystem_test в качестве дополнительного теста соответствия. В идеале все тесты должны компилировать и добиваться успеха со всеми реализациями файловой системы, но на самом деле существуют некоторые различия в поведении, иногда из -за места для интерпретации в стандарте, и в этих реализациях могут возникнуть проблемы.
Последняя версия релиза - v1.5.14, и исходные архивы можно найти здесь.
Последняя версия до начального бакенда-v1.4.0, и исходные архивы можно найти здесь.
Последняя версия выпуска Pre-C ++ на 20-й выпуск-V1.3.10, а исходные архивы можно найти здесь.
В настоящее время только последняя незначительная версия выпуска получает ошибки, поэтому, если возможно, вам следует использовать последний релиз.
Поскольку ghc::filesystem является сначала библиотекой только для заголовка, ее должно быть достаточно, чтобы скопировать заголовок или каталог include/ghc в папку проекта или указать свой путь к этому месту и просто включить заголовок ghc/filesystem.hpp 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 Если вы хотите также использовать обертку fstream с поддержкой path в качестве запасного, вы можете использовать:
# 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 .
Имейте в виду, что как библиотека только для заголовков, она не скрывает тот факт, что она использует System, поэтому они «загрязняют» ваше глобальное пространство имен. Используйте подход, основанный на обращении, на основе заголовка (см. Ниже), чтобы избежать этого. fs_std.hpp Windows он нуждается Windows.h , и это может быть хорошей идеей определить WIN32_LEAN_AND_MEAN или NOMINMAX до включения filesystem.hpp заголовков. Они не определены ghc::filesystem , чтобы позволить комбинацию с контекстами, где необходима полная Windows.h , например, для элементов пользовательского интерфейса.
Подсказка: существует дополнительный заголовок с именем ghc/fs_std.hpp , который реализует этот динамический выбор реализации файловой системы, которую вы можете включить вместо ghc/filesystem.hpp , когда вы хотите std::filesystem где имеется, и ghc::filesystem , где нет.
В качестве альтернативы, начиная с V1.1.0 ghc::filesystem также может использоваться путем включения одного из двух дополнительных заголовков обертки. Они позволяют включать перенаправленную версию в большинство мест ( ghc/fs_fwd.hpp ), скрывая данные реализации в одном файле CPP, который включает ghc/fs_impl.hpp для реализации необходимого кода. Использование ghc::filesystem Таким образом, гарантирует, что система включает в себя только изнутри файла CPP, все остальные места являются чистыми.
Имейте в виду, что в настоящее время он не поддерживается, чтобы скрыть реализацию в Windows-DLL, так как интерфейс DLL со стандартными шаблонами C ++ на интерфейсах-это другой зверь. Если кто -то готов попробовать, я мог бы интегрировать пиар, но в настоящее время работа над этим не является приоритетом.
Если вы используете подход переадресации/реализации, вы все равно можете использовать динамическое переключение таким образом:
# 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 , которые используют эту технику, чтобы вы могли просто включить их, если вы хотите динамически выбрать реализацию файловой системы.
Начиная с v1.1.0, можно добавить ghc::filesystem в качестве подмодуля GIT, добавить каталог в свой CMakeLists.txt с помощью add_subdirectory() а затем просто используйте target_link_libraries(your-target ghc_filesystem) чтобы убедиться, что правильный путь, который разрешает #include <ghc/filesystem.hpp> .
CMakeLists.txt предлагает несколько вариантов для настройки его поведения:
GHC_FILESYSTEM_BUILD_TESTING - COMPILE TESTS, по умолчанию OFF при использовании в качестве подмодуля, ON .GHC_FILESYSTEM_BUILD_EXAMPLES - Скомпилируйте примеры, по умолчанию OFF при использовании в качестве подмодуля, ON .GHC_FILESYSTEM_WITH_INSTALL - Добавьте установку Target для сборки, по умолчанию OFF при использовании в качестве подмодуля, ON .GHC_FILESYSTEM_BUILD_STD_TESTING - COMPILE std_filesystem_test , вариант тестового набора, работающего против std::filesystem , Deflusting GHC_FILESYSTEM_BUILD_TESTING . Это сделано только в том случае, если компилятор обнаруживается как способный это сделать.GHC_FILESYSTEM_TEST_COMPILE_FEATURES filesystem_test_cpp20 быть установлен в список функций для переопределения CMAKE_CXX_COMPILE_FEATURES , когда обнаружение C ++ 17 или C ++ 20 для дополнительных тестов не работает (например, cxx_std_20 .Пожалуйста, используйте Hedronvision/Bazel-CC-Filesyystem-Backport, который автоматически настроит все для вас.
Существует версия Macro GHC_FILESYSTEM_VERSION определенная в случае, если будущие изменения могут сделать необходимым для реагирования на версию, но я не планирую что -либо ломать. Это версия как десятичное число (major * 10000 + minor * 100 + patch) .
Примечание. Только версии патчей будут использоваться для выпусков, а версия Odd Patch будет использоваться только для между коммитами при работе над следующей версией.
В этом выпуске практически нет документации, так как любая документация std::filesystem filestem будет работать, помимо нескольких различий, объясненных в следующем разделе. Таким образом, вы можете отправиться в 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 .
ПРИМЕЧАНИЕ. Если API C ++ 17 должен быть применен даже в режиме C ++ 20, используйте Define GHC_FILESYSTEM_ENFORCE_CPP17_API . Даже тогда можно создать fws::path от std::u8string , но fs::path::u8string() и fs::path::generic_u8string() возвращать обычные UTF-8, кодируемые std::string Acts, так что код, написанный для C ++ 17, все еще может работать с ghc::filesystem при составлении с C ++.
Единственные дополнения к стандарту задокументированы здесь:
ghc::filesystem::ifstream , ghc::filesystem::ofstream , ghc::filesystem::fstream Это простые обертки вокруг std::ifstream , std::ofstream и std::fstream . Они просто добавляют метод open() и конструктор с аргументом ghc::filesystem::path как варианты fstream в C ++ 17.
ghc::filesystem::u8argumentsЭто вспомогательный класс, который в настоящее время проверяет кодирование UTF-8 на платформах, не являющихся Windows, но в Windows он извлекает аргументы командной строки как строки Unicode из ОС с
::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 ;
} Таким образом, argv кодируется UTF-8 до тех пор, пока объем main действителен.
ПРИМЕЧАНИЕ. На MacOS, в то время как отладка под xcode в настоящее время код будет возвращать false , поскольку XCode запускает приложение с US-ASCII в качестве кодирования, независимо от того, какое кодирование на самом деле используется, и даже установление LC_ALL в схеме продукта ничего не меняет. Мне все еще нужно исследовать это.
Поскольку эта реализация основана на существующем коде, из моих частных вспомогательных классов, она получила некоторые ограничения. Начиная с V1.5.0 Большинство различий между этим и стандартным API C ++ 17/C ++ 20, где удаляется.
Эта реализация имеет переключаемое поведение для дефектов LWG #2682, #2935, #2936 и #2937. В настоящее время выбранное поведение (начиная с v1.4.0) следует #2682, #2936, #2937, но не следуя #2935, так как я чувствую, что это ошибка, не сообщая об ошибках на create_directory() или create_directories() , где обычный файл с тем же именем запрещает использование каталога и заставляет пользователь из-за двойного перепроекта по fs::is_directory letire. Более интуитивно понятный подход к созданию каталога обработки файла с этим именем в качестве ошибки также выступает за более новую статью WG21 P1164R0, ревизия P1161R1 была согласована на собрании Kona 2019, см. Merge и 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 ++ 17-облегчение для C ++ 11/14. Начиная с v1.1.0, они поддерживаются при составлении ghc::filesystem под C ++ 17 из C ++ 20.
Начиная с V1.5.2 ghc::filesystem будет попытаться разрешить использование std::experimental::basic_string_view , где она обнаруживает, является доступностью. Кроме того, если у вас есть реализация basic_string_view C ++ 11, она может использоваться вместо std::basic_string_view , определив GHC_HAS_CUSTOM_STRING_VIEW и импортируя реализацию в ghc::filesystem с помощью:
namespace ghc {
namespace filesystem {
using my::basic_string_view;
}
}Прежде чем включить заголовок файловой системы.
Чтобы не зависеть от каких-либо внешних сторонних библиотек и до сих пор оставаться портативными и компактными, эта реализация следует философии «UTF-8 везде» в том, что все экземпляры std::string будут интерпретироваться так же, как и std::u8string , кодируя и находятся в UTF-8. std::u16string будет рассматриваться как UTF-16, а std::u32string будет рассматриваться как кодепоян Unicode. В зависимости от размера символов std::wstring , он будет обрабатывать std::wstring как UTF-16 (например, Windows) или char32_t Unicode Codepoints (в настоящее время все другие платформы).
Начиная с V1.5.0 ghc::filesystem состоит из стандарта C ++ 17 в использовании wchar_t и std::wstring на Windows в качестве типов, используемых для представления пути. По -прежнему возможно получить старое поведение, определив GHC_WIN_DISABLE_WSTRING_STORAGE_TYPE и GET filesystem::path::string_type AS std::string и filesystem::path::value_type as wchar_t .
Если вам нужно позвонить в некоторые API Windows, с v1.5.0 и выше, просто используйте W-вариант вызова Windows-API (например, 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 .
Я создал запись в вики о больших поведенческих различиях между различными реализациями std::filesystem , которые могут привести к упоминанию здесь, но это только Readme пытается устранить различия в выборе дизайна между ghc::filesystem и этими. Я пытаюсь время от времени обновлять страницу вики.
Любые дополнительные наблюдения приветствуются!
Поскольку v1.5.0 Полная внутренняя механика этой реализации fs::path , где изменился на собственный формат как внутреннее представление. "C:foo/bar" native() "C:foobar" "C:/foo/bar" fs::path generic_string() На всех платформах избыточные сепараторы удаляются, даже если это не применяется стандартными, а другие реализации в основном не делают этого.
Кроме того, эта реализация следует за предложением стандартов для обработки путей POSIX формы "//host/path" и пути USC в Windows, также имеющем имени корневой имени (например "//host" ). Реализация GCC не выбрала это при тестировании на Ubuntu 18.04 и MacOS с GCC 8.1.0 или Clang 7.0.0. Эта разница покажет как предупреждения в соответствии с std::filesystem . Это приводит к изменению алгоритма, описанного в стандарте для operator/=(path& p) , где любой путь p с p.is_absolute() будет делиться до задания, в то время как эта реализация имеет исключение, где *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 плохо переводится на маску битов с разрешением POSIX, используемую в интерфейсе файловой системы C ++ 17. Поэтому разрешения, возвращаемые в file_status , в настоящее время синтезируются для user -уровня и скопированы в group -и other -уровне. По -прежнему существует некоторый потенциал для большего взаимодействия с системой разрешений Windows, но в настоящее время настройка или чтение разрешений с этой реализацией, безусловно, не приведет к ожидаемому поведению.
extension() вернул не пустой результат для имени каталога ".."ghcFilesystem::ghc_filesystem теперь установлен безоговорочноstem() , filename() и extension() из fs::path вернет неправильный результат, если толстая кишка была в имени файлаfs::last_write_time(path, time, ec) Setter на iOS, TVOS и WatchOSfs::directory_entry::refresh() Теперь, последовательно со status() не будет добавлять символики на не существующие цели, но сделайте запись иметь file_type::not_found как типEINTR на итерации Directory Directory и копию файла, чтобы избежать ошибок в сетевых файловых системахfs::copy_file() теперь также копирует разрешенияfs::copy_file() игнорирование опции skip_existing .GHC_NO_DIRENT_D_TYPE в системах, которые не поддерживают dirent::d_type и фиксированная конфигурация сборки и тесты для поддержки Solaris в качестве новой платформы.PATH_MAX , один определен.fs::remove_all Теперь просто удаляет символические ссылки вместо того, чтобы следить за ними.fs::space , где числовое переполнение может произойти при умножении.fs::create_directories в Windows больше не ломается на длинных именах файлов.ghc::filesystem обработанная монтированная папка/объемы ошибочно как символики, ведущие fs::canonical , чтобы сбой на пути, содержащих их.recursive_directory_iterator не будет пытаться ввести мертвые символики.fs::remove сбой, когда путь указал на запись только для чтения, см. Также (Microsoft/STL #1511) для соответствующей проблемы в std::fs в Windows.GHC_NO_DIRENT_D_TYPE позволяет обнаружить ОС для поддержки систем без элемента dirent.d_type , экспериментальная поддержка первой QNX Compile в качестве начального варианта использования, фиксированная проблема с файловыми системами, возвращающими DT_UNKNOWN (EG Reiserfs).string_view при обнаружении Clang с Libstdc ++.<Availability.h> было включено до <ghc/fs_std.hpp> или <ghc/fs_std_fwd.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 , чтобы предварительно предварительно предварительно не дает никаких функций COMPALITITING TO CMAKE_CXX_COMPILE_FEATURES .directory_entry приводит к примерно 20% -25% в тестах с recursive_directory_iterator над более крупным деревом каталогов.wchar_t не был в списке поддерживаемых типов ChAR на бэкэндах, не являющихся Windows.string_view использует <string_view> или <experimental/string_view> когда доступен, и позволяет использовать пользовательскую реализацию basic_string_view при определении GHC_HAS_CUSTOM_STRING_VIEW и импорта строкового представления в ghc::filesystem Space перед включением файлового масштаба.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 , где реализовано, запланировали их из родительского проекта при использовании этого через add_subdirectory , это исправление позволяет установить их снова.fs::path Первоначально была создана из реализации на основе POSIX, была адаптацией входящих и исходящих строк. Это привело к изменчивому кешу внутри fs::path On Windows, который по своей природе не был защищенно, даже для методов const . Чтобы не добавлять дополнительные патчи в субоптимальное решение, на этот раз я переработал код path , чтобы теперь сохранить нативное представление. Это изменило много кода, но в сочетании с wchar_t AS value_type помог избежать большого количества конверсии для вызовов в Win-API.fs::path::native() и fs::path::c_str() теперь может быть noexcept как стандартные мандатыwchar_t теперь по умолчанию для fs::path::value_type и std::wstring - это по умолчанию для fs::path::string_type .const методов fs::path больше не является проблемойGHC_WIN_DISABLE_AUTO_PREFIXES , для всех других типов префиксов или пространств имен поведение следует за поведением MSVC std::filesystem::pathchar , основанный на std::string для Windows, все еще необходим, его можно активировать с помощью GHC_WIN_DISABLE_WSTRING_STORAGE_TYPEfs::file_status теперь поддерживает operator== Представлено в std::filesystem с C ++ 20.fs::path::parent_path() имел проблему с производительностью, так как он все еще использовал подход, основанный на петле, для воссоздания родителей из элементов. Это создало много временных и было слишком медленным, особенно на длинных путях.char8_t и std::u8string поддерживаются там, где Source является типом параметраfs::path::u8string() и fs::path::generic_u8string() Теперь верните std::u8string<=> теперь поддерживается для fs::pathGHC_FILESYSTEM_ENFORCE_CPP17_API ghc::filesystem вернется к старому fs::path::u8string() и fs::path::generic_u8string()fs::proximate(p, ec) , где внутренний вызов fs::current_path() не использовал вариант error_code , бросая возможные исключения вместо настройки ec .LWG_2936_BEHAVIOUR теперь включено по умолчанию.Source , которые являются представлениями строки.constexpr .__MAC_OS_X_VERSION_MIN_REQUIRED , чтобы убедиться, что std::filesystem выбирается только на MacOS только в том случае, если цель развертывания является по крайней мере каталина.directory_iterator и recursive_directory_iterator была проблема с опцией skip_permission_denied , которая приводит к неспособности пропустить защищенные папки SIP на macOS._MSVC_LANG теперь используется, когда доступно, дополнительно до __cplusplus , в заголовках помощи, чтобы они могли работать, даже когда /Zc:__cplusplus не используется.false на fs::exists или не основан на ошибках на fs::status . Пути с именами больше не отфильтрованы.TestAllocator в filesystem_test.cpp был завершен для выполнения требований для строительства на Centos 7 с devtoolset-9 . CentOS 7 и CentOS 8 в настоящее время являются частью сборки CI.LWG_2936_BEHAVIOUR , который позволяет включить Post C ++ 17 fs::path::compare поведения, где сравнение, как если бы это было сравнение элемента, как описано в LWG 2936 и C ++ 20 [fs.path.compare] . Это по умолчанию в V1.3.6 и будет по умолчанию, начиная с V1.4.0, когда он меняет заказ.wchar_t std::fstream от ghc::filesystem::fstream Обертки в Windows, если используют GCC с Libc ++.fs::directory_options::skip_permission_denied и начальная поддержка компиляции с помощью emscripten.ghc::filesystem теперь поддерживает использование в проектах за исключением отключений. Подписи API, использующие исключения для обработки ошибок, недоступны в этом режиме, спасибо за PR (это разрешает #60 и #43)ERROR_FILE_TOO_LARGE CONSUTANT.fs::lexically_relative не игнорировал сцепление на базовый параметр, спасибо за PR #57.fs::create_directories вернули true когда ничего не нужно создавать, потому что каталог уже существовал.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.
