filesystem
v1.5.14
ghc::filesystem::ifstream , ghc::filesystem::ofstream , ghc::filesystem::fstreamghc::filesystem::u8arguments นี่คือ header-file-file Single std::filesystem โดยใช้ C ++ 17 และ C ++ 20 Specs แต่นำไปใช้กับ 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 แต่ควรทำงานกับระบบอื่น ๆ มันควรทำงานร่วมกับ Android NDK, Emscripten และฉันยังมีรายงานว่ามันถูกใช้บน iOS (ภายในข้อ จำกัด ของ Sandboxing) และด้วย 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 เวลามากขึ้นถูกลงทุนในการเปรียบเทียบและเพิ่มประสิทธิภาพส่วนหนึ่งของห้องสมุด ฉันจะพยายามเพิ่มประสิทธิภาพบางส่วนและ refactor อื่น ๆ พยายามปรับปรุงให้ดีขึ้นตราบใดที่มันไม่ได้แนะนำปัญหาความเข้ากันได้ 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 ที่มี C ++ 17 หรือ C ++ 20 เต็มรูปแบบมันไม่ได้พยายามที่จะเป็น "ดีกว่า" std::filesystem เพียงแค่ดรอปอินเกือบถ้าคุณไม่สามารถใช้งานได้ (ยกเว้นการตั้งค่า UTF-8)
สำคัญ: การใช้งานนี้กำลังติดตามปรัชญา "UTF-8 ทุกที่" ในการที่ std::string ซ์สตริงทั้งหมดจะถูกตีความเช่นเดียวกับ std::u8string การเข้ารหัสที่ชาญฉลาดและอยู่ใน UTF-8 std::u16string จะถูกมองว่าเป็น UTF-16 ดู ความแตกต่างใน API สำหรับข้อมูลเพิ่มเติม
ขณะนี้การทดสอบหน่วยทำงานด้วย:
ส่วนหัวมาพร้อมกับชุดของการทดสอบหน่วยและใช้ CMake เป็นเครื่องมือสร้างและ catch2 เป็นกรอบทดสอบ การทดสอบทั้งหมดได้รับการลงทะเบียนด้วย CMake ดังนั้น Commando CTEST สามารถใช้ในการเรียกใช้การทดสอบ
การทดสอบทั้งหมดกับการใช้งานนี้ควรประสบความสำเร็จขึ้นอยู่กับสภาพแวดล้อมของคุณอาจเป็นไปได้ว่ามีคำเตือนบางอย่างเช่นหากคุณไม่มีสิทธิ์ในการสร้าง symlinks บน 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 เป็นไลบรารีส่วนหัวอย่างเดียวจึงควรเพียงพอที่จะคัดลอกส่วนหัวหรือ filesystem.hpp include/ghc ghc/filesystem.hpp ในโฟลเดอร์โครงการของคุณหรือชี้เส้นทางรวมของคุณไปยังสถานที่นี้
ทุกอย่างอยู่ในระบบ Namespace 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 ตอนนี้คุณมี fs::ofstream out(somePath); และมันก็เป็น wrapper หรือ c ++ 17 std::ofstream
โปรดระวังในฐานะที่เป็นห้องสมุดส่วนหัวเท่านั้นมันไม่ได้ซ่อนความจริงที่ว่าใช้ระบบรวมอยู่ด้วยดังนั้นพวกเขาจึง "มลพิษ" เนมสเปซทั่วโลกของคุณ ใช้วิธีการส่งต่อ/การใช้งานหัว (ดูด้านล่าง) เพื่อหลีกเลี่ยงสิ่งนี้ สำหรับ Windows มันต้องการ Windows.h และอาจเป็นความคิดที่ดีที่จะกำหนด WIN32_LEAN_AND_MEAN หรือ NOMINMAX ก่อนที่จะรวมส่วนหัว filesystem.hpp หรือ fs_std.hpp เพื่อลดมลพิษของเนมสเปซทั่วโลกของคุณและเวลาคอมไพล์ พวกเขาไม่ได้กำหนดโดย ghc::filesystem เพื่ออนุญาตให้รวมกับบริบทที่ต้องการ Windows.h แบบเต็มเช่นองค์ประกอบ UI
คำแนะนำ: มีส่วนหัวเพิ่มเติมชื่อ 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 submodule เพิ่มไดเรกทอรีลงใน CMakeLists.txt ของคุณ #include <ghc/filesystem.hpp> ด้วย add_subdirectory() จากนั้นใช้ target_link_libraries(your-target ghc_filesystem)
CMakeLists.txt มีตัวเลือกเล็กน้อยในการปรับแต่งพฤติกรรม:
GHC_FILESYSTEM_BUILD_TESTING - การทดสอบคอมไพล์ค่าเริ่มต้นจะ OFF เมื่อใช้เป็น submodule อื่น ONGHC_FILESYSTEM_BUILD_EXAMPLES - รวบรวมตัวอย่างค่าเริ่มต้นจะ OFF เมื่อใช้เป็น submodule อื่น ONGHC_FILESYSTEM_WITH_INSTALL - เพิ่มการติดตั้งเป้าหมายเพื่อสร้างค่าเริ่มต้นจะ OFF เมื่อใช้เป็น submodule อื่น ONGHC_FILESYSTEM_BUILD_STD_TESTING - คอมไพล์ std_filesystem_test ตัวแปรของชุดทดสอบที่ทำงานกับ std::filesystem เริ่มต้นเป็น 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-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 ที่เลิกใช้
หมายเหตุ: หากควรมีการบังคับใช้ C ++ 17 API แม้ในโหมด C ++ 20 ให้ใช้ define GHC_FILESYSTEM_ENFORCE_CPP17_API ถึงกระนั้นก็เป็นไปได้ที่จะสร้าง fws::path จาก std::u8string แต่ fs::path::u8string() และ fs::path::generic_u8string() ส่งคืน UTF-8 ปกติที่เข้ารหัส std::string ghc::filesystem สตริงดังนั้นรหัสที่เขียนสำหรับ C ++ 17
ส่วนเพิ่มเติมของมาตรฐานเท่านั้นที่มีการบันทึกไว้ที่นี่:
ghc::filesystem::ifstream , ghc::filesystem::ofstream , ghc::filesystem::fstream สิ่งเหล่านี้เป็น wrappers ง่าย ๆ รอบ 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 ความแตกต่างส่วนใหญ่ระหว่างสิ่งนี้กับมาตรฐาน C ++ 17/C ++ 20 API ที่ถูกลบออก
การใช้งานนี้มีพฤติกรรมที่สลับได้สำหรับข้อบกพร่องของ LWG #2682, #2935, #2936 และ #2937 พฤติกรรมที่เลือกในปัจจุบัน (เริ่มต้นจาก v1.4.0) คือการติดตาม #2682, #2936, #2937 แต่ไม่ได้ติดตาม fs::is_directory 2935 เนื่องจากฉันรู้สึกว่ามันเป็นข้อผิดพลาดที่จะรายงานข้อผิดพลาดใน create_directory() หรือ create_directories() ทำงาน. วิธีการที่ใช้งานง่ายมากขึ้นในการสร้างไดเรกทอรีการรักษาไฟล์ที่มีชื่อนั้นเป็นข้อผิดพลาดที่ได้รับการสนับสนุนโดยกระดาษรุ่นใหม่ 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-umgrade สำหรับ C ++ 11/14 เริ่มต้นด้วย v1.1.0 สิ่งเหล่านี้ได้รับการสนับสนุนเมื่อรวบรวม ghc::filesystem ภายใต้ C ++ 17 ของ C ++ 20
เริ่มต้นด้วย v1.5.2 ghc::filesystem จะพยายามอนุญาตให้ใช้ std::experimental::basic_string_view ที่ตรวจพบว่ามีความพร้อมใช้งาน นอกจากนี้หากคุณมีการใช้งาน C ++ 11 ที่เข้ากันได้กับ basic_string_view มันสามารถใช้แทน 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) หรือ char32_t codepoints unicode (ปัจจุบันแพลตฟอร์มอื่น ๆ ทั้งหมด)
เริ่มต้นด้วย v1.5.0 ghc::filesystem กำลังปฏิบัติตามมาตรฐาน C ++ 17 ในการใช้ wchar_t และ std::wstring บน Windows เป็นประเภทที่ใช้ภายในสำหรับการเป็นตัวแทนเส้นทาง ยังคงเป็นไปได้ที่จะได้รับพฤติกรรมเก่าโดยการกำหนด GHC_WIN_DISABLE_WSTRING_STORAGE_TYPE และรับ filesystem::path::string_type เป็น std::string and filesystem::path::value_type เป็น wchar_t
หากคุณต้องการโทรหา Windows API ด้วย v1.5.0 ขึ้นไปให้ใช้ w-variant ของการโทร 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 ที่แตกต่างกันซึ่งอาจส่งผลให้เกิดการกล่าวถึงที่นี่ แต่ผู้อ่านนี้พยายามที่จะจัดการกับความแตกต่างทางเลือกการออกแบบระหว่าง ghc::filesystem ฉันพยายามอัปเดตหน้า Wiki เป็นครั้งคราว
ยินดีต้อนรับการสังเกตเพิ่มเติมใด ๆ !
ตั้งแต่ v1.5.0 กลไกด้านในที่สมบูรณ์ของการใช้งานนี้ fs::path ที่เปลี่ยนเป็นรูปแบบ ดั้งเดิม เป็นตัวแทนภายใน การสร้าง Slash fs::path Object ภายใต้ Windows (เช่น "C:foo/bar" ) จะนำไปสู่เส้นทางที่สะอาดด้วย "C:foobar" ผ่าน native() และ "C:/foo/bar" ผ่านทาง generic_string() API ในแพลตฟอร์มทั้งหมดตัวคั่นเพิ่มเติมที่ซ้ำซ้อนจะถูกลบออกแม้ว่าจะไม่ได้บังคับใช้โดยมาตรฐานและการใช้งานอื่น ๆ ส่วนใหญ่ไม่ได้ทำเช่นนี้
นอกจากนี้การใช้งานนี้เป็นไปตามคำแนะนำมาตรฐานเพื่อจัดการเส้นทาง 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() จะไม่ส่ง symlinks ไปยังเป้าหมายที่ไม่มีอยู่จริง แต่ทำให้รายการมี file_type::not_found เป็นประเภทEINTR บนการวนซ้ำของไดเรกทอรี Posix และสำเนาไฟล์เพื่อหลีกเลี่ยงข้อผิดพลาดในระบบไฟล์เครือข่ายfs::copy_file() ตอนนี้ยังคัดลอกสิทธิ์fs::copy_file() ไม่สนใจตัวเลือก skip_existingGHC_NO_DIRENT_D_TYPE บนระบบที่ไม่รองรับ dirent::d_type และการกำหนดค่าการสร้างและการทดสอบคงที่เพื่อรองรับ Solaris เป็นแพลตฟอร์มใหม่PATH_MAX หนึ่งจะถูกกำหนดfs::remove_all ตอนนี้เพียงแค่ลบลิงก์สัญลักษณ์แทนการติดตามพวกเขาfs::space ที่อาจเกิดการล้นตัวเลขในการคูณfs::create_directories บน windows จะไม่หยุดพักในชื่อไฟล์ยาวอีกต่อไปghc::filesystem ที่ติดตั้งโฟลเดอร์/ปริมาตรที่ติดตั้งอย่างผิดพลาดในฐานะ Symlinks นำ fs::canonical ล้มเหลวบนเส้นทางที่มีเส้นทางเหล่านั้นrecursive_directory_iterator จะไม่พยายามป้อน symlinks ที่ตายแล้วfs::remove ล้มเหลวเมื่อพา ธ ชี้ไปที่รายการแบบอ่านอย่างเดียวดูเพิ่มเติม (Microsoft/STL #1511) สำหรับปัญหาที่เกี่ยวข้องใน std::fs บน windowsGHC_NO_DIRENT_D_TYPE อนุญาตให้ตรวจจับระบบปฏิบัติการเพื่อสนับสนุนระบบโดยไม่ต้องมีสมาชิก dirent.d_type , การสนับสนุนการคอมไพล์ QNX ครั้งแรกเป็นกรณีการใช้งานเริ่มต้นแก้ไขปัญหาด้วยระบบไฟล์ที่ส่งคืน dt_unknown (เช่น Reiserfs)string_view เมื่อตรวจพบเสียงดังจาก 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 เนื่องจากปัจจุบันไม่ได้เป็นส่วนหนึ่งของการกำหนดค่า CIGHC_FILESYSTEM_BUILD_STD_TESTING เพื่อแทนที่การสร้างเพิ่มเติมของ std::filesystem การทดสอบสำหรับการเปรียบเทียบและความเป็นไปได้ CMAKE_CXX_COMPILE_FEATURES จะใช้ GHC_FILESYSTEM_TEST_COMPILE_FEATURESdirectory_entry นำไปสู่การทดสอบประมาณ 20% -25% ในการทดสอบด้วย recursive_directory_iterator บนแผนผังไดเรกทอรีขนาดใหญ่wchar_t ไม่ได้อยู่ในรายการประเภทถ่านที่รองรับบนแบ็กเอนด์ที่ไม่ใช่หน้าต่างstring_view ที่ปรับปรุงแล้วใช้ประโยชน์จาก <string_view> หรือ <experimental/string_view> เมื่อพร้อมใช้งานและอนุญาตให้ใช้การใช้งาน basic_string_view ที่กำหนดเองเมื่อกำหนด GHC_HAS_CUSTOM_STRING_VIEW และนำเข้ามุมมองสตริงลงใน ghc::filesystemstd::filesystem ตอนนี้เชื่อมโยงกับ -lrt เพื่อหลีกเลี่ยงปัญหาfs::hard_link_count ล้มเหลวเนื่องจากพฤติกรรมระบบไฟล์กรณีทดสอบถูกปรับให้คำนึงถึงสิ่งนั้นGHC_FS_API และ GHC_FS_API_CLASS ได้รับเกียรติเมื่อตั้งเมื่อออกจากภายนอกเพื่ออนุญาตให้แทนที่พฤติกรรมmake installGHC_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-APIfs::path::native() และ fs::path::c_str() ตอนนี้สามารถเป็น noexcept เป็นเอกสารมาตรฐานwchar_t ตอนนี้เป็นค่าเริ่มต้นสำหรับ fs::path::value_type และ std::wstring เป็นค่าเริ่มต้นสำหรับ fs::path::string_typeconst ของ fs::path ไม่ได้เป็นปัญหาอีกต่อไปGHC_WIN_DISABLE_AUTO_PREFIXES สำหรับคำนำหน้าประเภทอื่น ๆ ทั้งหมดหรือเนมสเปซพฤติกรรมดังต่อ std::filesystem::pathchar / std::string สำหรับ windows สามารถเปิดใช้งานได้ด้วย GHC_WIN_DISABLE_WSTRING_STORAGE_TYPEfs::file_status รองรับ operator== แนะนำใน std::filesystem ด้วย C ++ 20fs::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 โดยโยนข้อยกเว้นที่เป็นไปได้แทนการตั้งค่า ecLWG_2936_BEHAVIOUR เปิดใช้งานแล้วโดยค่าเริ่มต้นSource ที่เป็นมุมมองสตริงconstexpr__MAC_OS_X_VERSION_MIN_REQUIRED เพื่อให้แน่ใจว่า std::filesystem ถูกเลือกเฉพาะใน MACOS หากเป้าหมายการปรับใช้อย่างน้อย Catalinadirectory_iterator และ recursive_directory_iterator มีปัญหากับตัวเลือก skip_permission_denied ซึ่งนำไปสู่การไร้ความสามารถในการข้ามโฟลเดอร์ป้องกัน SIP บน macOS_MSVC_LANG ถูกนำมาใช้เมื่อพร้อมใช้งานเพิ่มเติมจาก __cplusplus ในส่วนหัวช่วยเหลือเพื่อให้พวกเขาทำงานได้แม้จะไม่ได้ใช้ /Zc:__cplusplusfalse ใน fs::exists หรือไม่ก่อตั้งข้อผิดพลาดใน fs::status เส้นทางที่ไม่เหมาะสมจะไม่ถูกกรองอีกต่อไปTestAllocator ใน filesystem_test.cpp เสร็จสมบูรณ์เพื่อตอบสนองความต้องการในการสร้าง CentOS 7 ด้วย devtoolset-9 Centos 7 และ Centos 8 เป็นส่วนหนึ่งของ CI BuildsLWG_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 และการสนับสนุนเบื้องต้นสำหรับการรวบรวมด้วย emscriptenghc::filesystem สนับสนุนการใช้งานในโครงการที่มีข้อยกเว้นที่ปิดใช้งาน ลายเซ็น API โดยใช้ข้อยกเว้นสำหรับการจัดการข้อผิดพลาดไม่สามารถใช้ได้ในโหมดนี้ขอบคุณสำหรับ PR (สิ่งนี้แก้ไขได้ #60 และ #43)ERROR_FILE_TOO_LARGE ที่ไม่ได้กำหนดfs::lexically_relative ไม่ได้เพิกเฉยต่อการลากบนพารามิเตอร์พื้นฐานขอบคุณสำหรับ PR #57fs::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.
