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 ، ARM ARM/ARM64 Linux و Solaris 10 ولكن يجب أن تعمل على أنظمة أخرى أيضًا ، طالما كان لديك ما لا يقل عن C ++ Pendermiler. يجب أن تعمل مع 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 ، أردت استخدام هذه الواجهة ، لكن الأمر استغرق بعض الوقت ، لدفع نفسي لتحويل فصولي.
يعتمد التنفيذ بشكل وثيق على الفصل 30.10 من معيار C ++ 17 ومسودة قريبة من هذا الإصدار يعمل مشروع N4687. إنه من بعد توحيد C ++ 17 ولكنه يحتوي على أحدث تغييرات واجهة نظام الملفات مقارنة بمسودة العمل N4659. يحدق مع V1.4.0 ، عند تجميعه باستخدام C ++ 20 ، يتكيف مع التغييرات وفقًا لترتيب فرز المسار ومعالجة std::u8string من مشروع N4860.
أود أن أشكر الأشخاص الذين يعملون على تحسين C ++ ، لقد أحببت حقًا كيف تطورت اللغة مع C ++ 11 والمعايير التالية. استمر في العمل الجيد!
إذا سألت نفسك ، فما الذي تمثله ghc ، فهو ببساطة gulraks helper classes ، نعم ، أنا أعلم ، ليست مبتكرة للغاية ، لكنني أردت مساحة اسم قصيرة وأستخدمها في بعض فصولي الخاصة (لذلك لا علاقة لها بـ Haskell ، آسف على صدام الاسم).
تم تطوير ghc::filesystem على MacOS ولكن CI تم اختباره على MacOS ، Windows ، توزيعات Linux المختلفة ، FreeBSD وبدء V1.5.12 على Solaris. يجب أن تعمل على أي من هذه مع برنامج التحويل البرمجي C ++ 11 قادر. هناك أيضًا بعض الشيكات التي نأمل أن تعمل بشكل أفضل على Android ، لكن بما أنني لا أختبر حاليًا مع نظام Android NDK ، فلن أسميها نظامًا متدعمًا حتى الآن ، نفس الشيء صالح لاستخدامه مع emscripten. إنه الآن جزء من المنصات المكتشفة ، لقد أصلحت المشكلات الواضحة وقمت بإجراء بعض الاختبارات معها ، لذلك يجب أن تكون على ما يرام. الكل في الكل ، لا أراه يحل محل std::filesystem حيث يتوفر Full 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 أو الأحدث ، فإنه يحاول بالإضافة إلى ذلك إنشاء إصدار من الاختبار الثنائي الذي تم تجميعه مقابل تنفيذ std::filesystem والذي يسمى std_filesystem_test كاختبار إضافي للتوافق. من الناحية المثالية ، يجب أن تتجمع جميع الاختبارات وتنجح مع جميع تطبيقات نظام الملفات ، ولكن في الواقع ، هناك بعض الاختلافات في السلوك ، ويرجع ذلك في بعض الأحيان إلى مجال التفسير في المعيار ، وقد تكون هناك مشكلات في هذه التطبيقات أيضًا.
أحدث إصدار من الإصدار هو v1.5.14 ويمكن العثور على أرشيف المصدر هنا.
أحدث إصدار قبل الولادة هو V1.4.0 ويمكن العثور على أرشيف المصدر هنا.
أحدث إصدار من إصدار ما قبل C ++ 20 هو V1.3.10 ويمكن العثور على أرشفة المصدر هنا.
حاليًا فقط أحدث إصدار من الإصدار الثانوي يتلقى bugfixes ، لذلك إذا أمكن ، يجب عليك استخدام أحدث إصدار.
نظرًا لأن 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 إذا كنت ترغب أيضًا في استخدام Wrapper 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 .
كن على دراية ، كمكتبة رأس فقط ، لا تخفي الحقيقة ، حيث يستخدم نظام ، بحيث "تلوث" مساحة الاسم العالمية الخاصة بك. استخدم النهج القائم على رأس التوجيه/التنفيذ (انظر أدناه) لتجنب ذلك. بالنسبة لنظام التشغيل Windows ، فإنه يحتاج إلى Windows.h وقد يكون من الجيد تحديد WIN32_LEAN_AND_MEAN أو NOMINMAX قبل تضمين رؤوس filesystem.hpp أو fs_std.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 - اختبارات التجميع ، يتم OFF الافتراضي عند استخدامها كوحدة فرعية ، ON .GHC_FILESYSTEM_BUILD_EXAMPLES - تجميع الأمثلة ، يتم OFF الافتراضي عند استخدامها كوحدة فرعية ، ON .GHC_FILESYSTEM_WITH_INSTALL - إضافة هدف تثبيت إلى الإنشاء ، يتم OFF الافتراضي عند استخدامه كوحدة فرعية ، ON .GHC_FILESYSTEM_BUILD_STD_TESTING - ترجمة std_filesystem_test ، البديل في مجموعة الاختبار التي تعمل ضد std::filesystem ، يتخلف عن GHC_FILESYSTEM_BUILD_TESTING . يتم ذلك فقط إذا تم اكتشاف المترجم على أنه قادر على القيام بذلك.GHC_FILESYSTEM_TEST_COMPILE_FEATURES على قائمة الميزات لتجاوز CMAKE_CXX_COMPILE_FEATURES عند عدم عمل C ++ 17 أو C ++ 20 للاختبارات الإضافية (مثل cxx_std_20 لفرض بناء filesystem_test_cpp20 مع C ++ 20).يرجى استخدام HedronVision/Bazel-CC-Filesystem-Backport ، والتي ستقوم تلقائيًا بإعداد كل شيء لك.
يوجد إصدار Macro GHC_FILESYSTEM_VERSION المحدد في حالة أن التغييرات المستقبلية قد تجعل من الضروري أن تتفاعل على الإصدار ، لكنني لا أخطط لكسر أي شيء. إنه الإصدار كرقم عشري (major * 10000 + minor * 100 + patch) .
ملاحظة: سيتم استخدام إصدارات التصحيح فقط للإصدارات وسيتم استخدام إصدار التصحيح الفردي فقط بين الالتزامات أثناء العمل على الإصدار التالي.
لا يوجد أي وثائق تقريبًا في هذا الإصدار ، حيث ستعمل أي وثائق std::filesystem ، إلى جانب الاختلافات القليلة الموضحة في القسم التالي. لذلك يمكنك التوجه إلى https://en.cppreference.com/w/cpp/filesystem للحصول على وصف لمكونات هذه المكتبة.
عند التجميع مع C ++ 11 أو C ++ 14 أو C ++ 17 ، تتبع واجهة برمجة التطبيقات (C ++ 17) ، حيثما أمكن ، باستثناء معلمات std::string_view فقط على C ++ 17. عند التجميع مع C ++ 20 ، ghc::filesysytem تتخلف عن واجهة API C ++ 20 ، مع واجهات 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 ، لذلك يمكن أن تعمل الكود المكتوب لـ C ++ 17 مع ghc::filesystem عند الترجم مع C ++ 20.
تم توثيق الإضافات الوحيدة للمعيار هنا:
ghc::filesystem::ifstream ، ghc::filesystem::ofstream ، ghc::filesystem::fstream هذه مغلفة بسيطة حول std::ifstream ، std::ofstream و std::fstream . إنهم ببساطة يضيفون طريقة open() ومُنشئ مع ghc::filesystem::path assum as then the fstream in in 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 كما تتم الاتفاق على النهج الأكثر سهولة لإنشاء الدليل لعلاج ملف بهذا الاسم كخطأ من قبل أحدث الورقة 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/4. بدءًا من 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 ستعتبر نقاط codepoints Unicode. اعتمادًا على حجم أحرف std::wstring ، فسوف يتعامل مع std::wstring باعتباره UTF-16 (على سبيل المثال Windows) أو CodePoints char32_t Unicode (حاليًا جميع الأنظمة الأساسية الأخرى).
بدءًا من V1.5.0 ghc::filesystem يتبع معيار C ++ 17 في استخدام wchar_t و std::wstring على Windows كأنواع تستخدم داخليًا لتمثيل المسار. لا يزال من الممكن الحصول على السلوك القديم عن طريق تحديد GHC_WIN_DISABLE_WSTRING_STORAGE_TYPE والحصول على filesystem::path::string_type as std::string and filesystem::path::value_type as wchar_t .
إذا كنت بحاجة إلى استدعاء بعض واجهة برمجة تطبيقات Windows ، مع V1.5.0 وما فوق ، فما عليك سوى استخدام W-tariant لمكالمة Windows-API (على سبيل المثال GetFileAttributesW(p.c_str()) ).
ملاحظة: عند استخدام السلوك القديم عن طريق تحديد GHC_WIN_DISABLE_WSTRING_STORAGE_TYPE ، استخدم عضو path::wstring() (على سبيل المثال GetFileAttributesW(p.wstring().c_str()) ). يمنحك هذا متغير Unicode مستقلًا عن Macro 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 المختلفة التي قد تؤدي إلى ذكر هنا ، لكن هذا ReadMe يحاول فقط معالجة اختلافات اختيار التصميم بين ghc::filesystem . أحاول تحديث صفحة الويكي من وقت لآخر.
أي ملاحظات إضافية مرحب بها!
منذ v1.5.0 ، فإن الميكانيكا الداخلية الكاملة لهذه التطبيقات fs::path حيث تم تغييرها إلى التنسيق الأصلي كتمثيل داخلي. سيؤدي إنشاء أي كائن مختلط fs::path تحت Windows (على سبيل المثال مع "C:foo/bar" ) إلى "C:foobar" عبر native() و "C:/foo/bar" عبر API 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 expend expend ، للسماح:
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) نادراً ما يتم استخدامه ، ولا يزال يتم دعمهم مع هذا التنفيذ.
تترجم ميزة إذن ACL Windows بشكل سيء إلى قناع بت 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) على iOS ، tvos و watchosfs::directory_entry::refresh() الآن ، لن يلقي بشكل متسق مع status() على أهداف غير موجودة ، ولكن اجعل الإدخال يحتوي على file_type::not_found كنوعEINTR على تكرار دليل POSIX ونسخ الملف لتجنب الأخطاء على أنظمة ملفات الشبكةfs::copy_file() الآن نسخ الأذونات الآنfs::copy_file() تجاهل خيار skip_existing .GHC_NO_DIRENT_D_TYPE على الأنظمة التي لا تدعم dirent::d_type وتكوين البناء الثابت واختباراتها لدعم سولاريس كمنصة جديدة.PATH_MAX ، يتم تعريف واحد.fs::remove_all الآن يحذف الروابط الرمزية بدلاً من متابعتها.fs::space حيث يمكن أن يحدث سعة عددية في الضرب.fs::create_directories على Windows يكسر أسماء الملفات الطويلة.ghc::filesystem المعالجة المجلد/المجلدات المعالجة بشكل خاطئ مثل الارتباطات ، مما يؤدي إلى fs::canonical للفشل على المسارات التي تحتوي على تلك.recursive_directory_iterator إدخال Symlinks الميتة.fs::remove عندما يشير المسار إلى إدخال للقراءة فقط ، انظر أيضًا (Microsoft/STL #1511) للمسألة المقابلة في std::fs على Windows.GHC_NO_DIRENT_D_TYPE اكتشاف نظام التشغيل لدعم الأنظمة بدون عضو dirent.d_type ، دعم تجميع QNX الأول التجريبي كحالة الاستخدام الأولي ، مع مشكلة ثابتة مع إرجاع أنظمة الملفات DT_UNKNOWN (مثل 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.CMAKE_CXX_COMPILE_FEATURES GHC_FILESYSTEM_TEST_COMPILE_FEATURES إضافة خيار GHC_FILESYSTEM_BUILD_STD_TESTING لتجاوز بناء المزيد من إصدارات std::filesystemdirectory_entry المنخفض إلى حوالي 20 ٪ -25 ٪ في الاختبارات مع recursive_directory_iterator عبر شجرة دليل أكبر.wchar_t في قائمة أنواع char المدعومة على الخلفية غير النافذة.string_view المحسّن باستخدام <string_view> أو <experimental/string_view> عندما يكون متاحًا ، ويسمح باستخدام تنفيذ Custom basic_string_view عند تحديد GHC_HAS_CUSTOM_STRING_VIEW واستيراد طريقة عرض السلسلة في مساحة ghc::filesystem قبل تضمين رأس ملفات الملفات.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 على Windows ، لم يكن بطبيعته آمنًا لخيط ، حتى بالنسبة لطرق 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 .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() API إذا كان ذلك مفضلاً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 الذي يسمح بتمكين ما بعد 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 Wrappers على Windows إذا كنت تستخدم GCC مع LIBC ++.fs::directory_options::skip_permission_denied والدعم الأولي للتجميع مع emscripten.ghc::filesystem يدعم الآن الاستخدام في المشاريع مع استثناءات معطلة. لا تتوفر توقيعات API باستخدام استثناءات لمعالجة الأخطاء في هذا الوضع ، شكرًا على العلاقات العامة (هذا يحل رقم 60 و #43)ERROR_FILE_TOO_LARGE غير المحدد.fs::lexically_relative لم يتجاهل القطع المدمرة على المعلمة الأساسية ، شكرًا على PR #57.fs::create_directories returned true when nothing needed to be created, because the directory already existed.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.
