filesystem
v1.5.14
ghc::filesystem::ifstream , ghc::filesystem::ofstream , ghc::filesystem::fstreamghc::filesystem::u8arguments Ini adalah pustaka helper yang kompatibel dengan file tunggal std::filesystem , berdasarkan pada spesifikasi C ++ 17 dan C ++ 20, tetapi diimplementasikan untuk C ++ 11, C ++ 14, C ++ 17 atau C ++ 20 (dengan ketat mengikuti standar C ++ 17 dengan sangat sedikit pengecualian yang terdokumentasi). Saat ini diuji pada 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 dan Solaris 10 tetapi harus bekerja pada sistem lain juga, selama Anda memiliki setidaknya C ++ 11 C ++. Ini harus bekerja dengan Android NDK, Emscripten dan saya bahkan memiliki laporan tentang itu digunakan pada iOS (dalam kendala sandboxing) dan dengan v1.5.6 ada dukungan eksperimental untuk QNX. Dukungan Android NDK, Emscripten, QNX, dan karena 1.5.14 GNU/Hurd dan Haiku tidak didukung oleh pengujian otomatis tetapi laporan PR dan bug dipersilakan untuk itu juga dan mereka dilaporkan bekerja. Tentu saja dalam Namespace ghc::filesystem sendiri untuk tidak mengganggu std::filesystem jika Anda menggunakannya dalam lingkungan C ++ 17 campuran (yang dimungkinkan).
Cakupan uji jauh di atas 90%, dan dimulai dengan v1.3.6 dan di v1.5.0 lebih banyak waktu diinvestasikan dalam pembandingan dan mengoptimalkan bagian -bagian perpustakaan. Saya akan mencoba untuk terus mengoptimalkan beberapa bagian dan refactor yang lain, berusaha untuk memperbaikinya selama tidak memperkenalkan masalah kompatibilitas C ++ 17/C ++ 20 tambahan. Umpan balik selalu diterima. Cukup buka masalah jika Anda melihat sesuatu yang hilang atau salah atau tidak berperilaku seperti yang diharapkan dan saya akan berkomentar.
Saya sering membutuhkan fungsionalitas sistem file, sebagian besar fs::path , tetapi akses direktori juga, dan ketika mulai menggunakan C ++ 11, saya menggunakan pembaruan bahasa itu untuk mencoba mengurangi dependensi pihak ketiga saya. Saya bisa menjatuhkan sebagian besar dari apa yang saya gunakan, tetapi masih melewatkan beberapa hal yang saya mulai terapkan untuk bersenang -senang. Awalnya saya mendasarkan pembantu ini pada konvensi pengkodean dan penamaan saya sendiri. Ketika C ++ 17 diselesaikan, saya ingin menggunakan antarmuka itu, tetapi butuh beberapa saat, untuk mendorong diri saya untuk mengonversi kelas saya.
Implementasinya didasarkan pada Bab 30.10 dari standar C ++ 17 dan draf yang dekat dengan versi itu bekerja draft N4687. Ini dari setelah standarisasi C ++ 17 tetapi berisi perubahan antarmuka sistem file terbaru dibandingkan dengan draft kerja N4659. Menatap dengan v1.4.0, saat dikompilasi menggunakan C ++ 20, itu beradaptasi dengan perubahan sesuai dengan urutan penyortiran jalur dan penanganan std::u8string dari draft kerja N4860.
Saya ingin mengucapkan terima kasih kepada orang -orang yang bekerja untuk meningkatkan C ++, saya sangat menyukai bagaimana bahasa berevolusi dengan C ++ 11 dan standar berikut. Terus bekerja dengan baik!
Jika Anda bertanya pada diri sendiri, apa yang diperjuangkan ghc , itu hanyalah gulraks helper classes , ya, saya tahu, tidak terlalu imajinatif, tapi saya ingin namespace pendek dan saya menggunakannya di beberapa kelas pribadi saya (jadi tidak ada hubungannya dengan Haskell , maaf atas nama Bentrok).
ghc::filesystem dikembangkan pada macOS tetapi CI diuji pada macOS, windows, berbagai distribusi linux, freeBSD dan dimulai dengan v1.5.12 di solaris. Ini harus bekerja pada semua ini dengan kompiler C ++ 11-CaPable. Juga ada beberapa cek untuk semoga bekerja lebih baik di Android, tetapi karena saya saat ini tidak menguji dengan Android NDK, saya tidak akan menyebutnya platform yang didukung, sama berlaku untuk menggunakannya dengan Emscripten. Sekarang menjadi bagian dari platform yang terdeteksi, saya memperbaiki masalah yang jelas dan menjalankan beberapa tes dengannya, jadi seharusnya baik -baik saja. Secara keseluruhan, saya tidak melihatnya menggantikan std::filesystem di mana C ++ 17 atau C ++ 20 lengkap tersedia, itu tidak mencoba menjadi "lebih baik" std::filesystem , hanya drop-in hampir jika Anda tidak dapat menggunakannya (dengan pengecualian preferensi UTF-8).
PENTING: Implementasi ini mengikuti filosofi "UTF-8 Everywhere" dalam bahwa semua instance std::string akan ditafsirkan sama dengan std::u8string encoding bijaksana dan sebagai berada di UTF-8. std::u16string akan dilihat sebagai UTF-16. Lihat perbedaan API untuk informasi lebih lanjut.
Tes unit saat ini dijalankan dengan:
Header dilengkapi dengan satu set unit-tes dan menggunakan CMake sebagai alat build dan catch2 sebagai kerangka kerja tes. Semua tes terdaftar di CMake, sehingga CTEST Commando dapat digunakan untuk menjalankan tes.
Semua tes terhadap implementasi ini harus berhasil, tergantung pada lingkungan Anda, mungkin ada beberapa peringatan, misalnya jika Anda tidak memiliki hak untuk membuat symlink pada jendela atau setidaknya tes berpikir demikian, tetapi ini hanya informatif.
Untuk membangun tes dari dalam direktori proyek di bawah macOS atau linux hanya:
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Debug ..
make
ctestIni menghasilkan binari uji yang menjalankan tes dan perintah terakhir mengeksekusi mereka.
Jika kompiler default adalah GCC 8 atau yang lebih baru, atau dentang 7 atau yang lebih baru, ia juga mencoba membangun versi biner uji yang dikompilasi terhadap GCCS/Clangs std::filesystem , bernama std_filesystem_test sebagai tes tambahan kesesuaian. Idealnya semua tes harus dikompilasi dan berhasil dengan semua implementasi sistem file, tetapi pada kenyataannya, ada beberapa perbedaan dalam perilaku, kadang -kadang karena ruang untuk interpretasi dalam standar, dan mungkin ada masalah dalam implementasi ini juga.
Versi rilis terbaru adalah v1.5.14 dan arsip sumber dapat ditemukan di sini.
Versi pra-pra-backend terbaru adalah v1.4.0 dan arsip sumber dapat ditemukan di sini.
Versi rilis pra-C ++ 20-dukungan terbaru adalah v1.3.10 dan arsip sumber dapat ditemukan di sini.
Saat ini hanya versi rilis minor terbaru yang menerima perbaikan bug, jadi jika memungkinkan, Anda harus menggunakan rilis terbaru.
Karena ghc::filesystem pada awalnya adalah perpustakaan header saja, itu harus cukup untuk menyalin header atau direktori include/ghc ke folder proyek Anda atau arahkan jalur termasuk Anda ke tempat ini dan cukup sertakan header filesystem.hpp (atau ghc/filesystem.hpp jika Anda menggunakan subdirektori).
Semuanya ada di Namespace ghc::filesystem , jadi salah satu cara untuk menggunakannya hanya sebagai fallback bisa:
# 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 Jika Anda juga ingin menggunakan pembungkus fstream dengan dukungan path sebagai fallback, Anda dapat menggunakan:
# 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 Sekarang Anda memiliki EG fs::ofstream out(somePath); dan itu adalah pembungkus atau C ++ 17 std::ofstream .
Waspadai, sebagai perpustakaan header saja, tidak menyembunyikan fakta, bahwa ia menggunakan sistem termasuk, sehingga mereka "mencemari" namespace global Anda. Gunakan pendekatan berbasis penerusan/implementasi-header (lihat di bawah) untuk menghindari ini. Untuk Windows, perlu Windows.h dan mungkin ide yang baik untuk mendefinisikan WIN32_LEAN_AND_MEAN atau NOMINMAX sebelum memasukkan header filesystem.hpp atau fs_std.hpp untuk mengurangi polusi namespace global Anda dan waktu kompilasi. Mereka tidak didefinisikan oleh ghc::filesystem untuk memungkinkan kombinasi dengan konteks di mana Windows.h lengkap diperlukan, misalnya untuk elemen UI.
Petunjuk: Ada header tambahan bernama ghc/fs_std.hpp yang mengimplementasikan pemilihan dinamis dari implementasi sistem file ini, yang dapat Anda sertakan alih -alih ghc/filesystem.hpp saat Anda ingin std::filesystem di mana tersedia dan ghc::filesystem di mana tidak.
Atau, mulai dari V1.1.0 ghc::filesystem juga dapat digunakan dengan memasukkan salah satu dari dua header pembungkus tambahan. Ini memungkinkan untuk memasukkan versi yang diteruskan di sebagian besar tempat ( ghc/fs_fwd.hpp ) sambil menyembunyikan detail implementasi dalam satu file CPP yang mencakup ghc/fs_impl.hpp untuk mengimplementasikan kode yang diperlukan. Menggunakan ghc::filesystem dengan cara ini memastikan sistem termasuk hanya terlihat dari dalam file CPP, semua tempat lain bersih.
Waspadai, saat ini tidak didukung untuk menyembunyikan implementasi menjadi Windows-DLL, sebagai antarmuka DLL dengan templat standar C ++ dalam antarmuka adalah binatang yang berbeda. Jika seseorang bersedia mencobanya, saya mungkin mengintegrasikan PR tetapi saat ini mengerjakannya sendiri bukanlah prioritas.
Jika Anda menggunakan pendekatan penerusan/implementasi, Anda masih dapat menggunakan switching dinamis seperti ini:
# 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 Dan dalam implementasi yang menyembunyikan CPP, Anda dapat menggunakan (sebelum termasuk yang termasuk ghc/fs_fwd.hpp untuk diutamakan:
# 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 Petunjuk: Ada header helper tambahan, bernama ghc/fs_std_fwd.hpp dan ghc/fs_std_impl.hpp yang menggunakan teknik ini, sehingga Anda dapat memasukkannya dengan mudah jika Anda ingin secara dinamis memilih implementasi sistem file.
Mulai dari v1.1.0, dimungkinkan untuk menambahkan ghc::filesystem sebagai submodule git, tambahkan direktori ke CMakeLists.txt Anda dengan add_subdirectory() dan kemudian cukup gunakan target_link_libraries(your-target ghc_filesystem) ghc_filestem) untuk memastikan jalur yang benar termasuk #include <ghc/filesystem.hpp> .
CMakeLists.txt menawarkan beberapa opsi untuk menyesuaikan perilakunya:
GHC_FILESYSTEM_BUILD_TESTING - Tes kompilasi, default OFF saat digunakan sebagai submodule, jika ON .GHC_FILESYSTEM_BUILD_EXAMPLES - Kompilasi contoh, default OFF saat digunakan sebagai submodule, jika ON .GHC_FILESYSTEM_WITH_INSTALL - Tambahkan target instal ke membangun, default OFF saat digunakan sebagai submodule, jika ON .GHC_FILESYSTEM_BUILD_STD_TESTING - Kompilasi std_filesystem_test , varian suite uji yang berjalan melawan std::filesystem , default ke GHC_FILESYSTEM_BUILD_TESTING . Ini hanya dilakukan jika kompiler terdeteksi karena dapat melakukannya.GHC_FILESYSTEM_TEST_COMPILE_FEATURES dapat diatur ke daftar fitur untuk mengganti CMAKE_CXX_COMPILE_FEATURES ketika deteksi C ++ 17 atau C ++ 20 untuk pengujian tambahan tidak berfungsi (misalnya cxx_std_20 20) untuk menegakkan pembangunan filesystem_test_cpp20 .Harap gunakan hedronvision/bazel-cc-filesystem-backport, yang secara otomatis akan mengatur semuanya untuk Anda.
Ada versi Macro GHC_FILESYSTEM_VERSION yang didefinisikan dalam kasus perubahan di masa depan mungkin membuatnya diperlukan untuk bereaksi pada versi, tetapi saya tidak berencana untuk memecahkan apa pun. Ini adalah versi sebagai nomor desimal (major * 10000 + minor * 100 + patch) .
CATATAN: Hanya bahkan versi tambalan yang akan digunakan untuk rilis dan versi patch ganjil hanya akan digunakan untuk di antara komit -komit saat mengerjakan versi berikutnya.
Hampir tidak ada dokumentasi dalam rilis ini, karena dokumentasi std::filesystem akan berfungsi, selain beberapa perbedaan yang dijelaskan di bagian selanjutnya. Jadi Anda mungkin menuju ke https://en.cppreference.com/w/cpp/filesystem untuk deskripsi komponen perpustakaan ini.
Saat menyusun dengan C ++ 11, C ++ 14 atau C ++ 17, API mengikuti standar C ++ 17, jika memungkinkan, dengan pengecualian bahwa parameter std::string_view hanya didukung pada C ++ 17. Saat menyusun dengan C ++ 20, ghc::filesysytem default ke C ++ 20 API, dengan antarmuka char8_t dan std::u8string dan metode pabrik fs::u8path yang sudah usang.
CATATAN: Jika API C ++ 17 harus ditegakkan bahkan dalam mode C ++ 20, gunakan define GHC_FILESYSTEM_ENFORCE_CPP17_API . Even then it is possible to create fws::path from std::u8string but fs::path::u8string() and fs::path::generic_u8string() return normal UTF-8 encoded std::string instances, so code written for C++17 could still work with ghc::filesystem when compiled with C++20.
Satu -satunya tambahan standar didokumentasikan di sini:
ghc::filesystem::ifstream , ghc::filesystem::ofstream , ghc::filesystem::fstream Ini adalah pembungkus sederhana di sekitar std::ifstream , std::ofstream dan std::fstream . Mereka cukup menambahkan metode open() dan konstruktor dengan argumen ghc::filesystem::path sebagai varian fstream dalam C ++ 17 memilikinya.
ghc::filesystem::u8argumentsIni adalah kelas penolong yang saat ini memeriksa pengkodean UTF-8 pada platform non-windows tetapi pada Windows ia mengambil argumen baris perintah sebagai string unicode dari OS dengan
::CommandLineToArgvW (::GetCommandLineW(), &argc) dan kemudian mengubahnya menjadi UTF-8, dan menggantikan argc dan argv . Ini adalah kelas seperti penjaga yang mengembalikan perubahannya saat keluar dari ruang lingkup.
Jadi penggunaan dasar adalah:
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 ;
} Dengan cara itu argv adalah UTF-8 yang dikodekan selama ruang lingkup dari main adalah valid.
CATATAN: Pada macOS, saat debugging di bawah XCODE Kode saat ini akan mengembalikan false saat Xcode memulai aplikasi dengan US-ASCII sebagai pengkodean, tidak peduli apa pun pengkodean yang sebenarnya digunakan dan bahkan mengatur LC_ALL dalam skema produk tidak mengubah apa pun. Saya masih perlu menyelidiki ini.
Karena implementasi ini didasarkan pada kode yang ada dari kelas pembantu pribadi saya, ia memperoleh beberapa kendala. Mulai dari v1.5.0 Sebagian besar perbedaan antara ini dan standar C ++ 17/C ++ 20 API di mana dihapus.
Implementasi ini memiliki perilaku yang dapat dialihkan untuk Cacat LWG #2682, #2935, #2936 dan #2937. Perilaku yang saat ini dipilih (mulai dari v1.4.0) mengikuti #2682, #2936, #2937 tetapi tidak mengikuti fs::is_directory , karena saya merasa itu adalah bug untuk melaporkan tidak ada kesalahan pada create_directory() atau create_directories() di mana file rutin yang sama melarang ciptaan dari sutradara dan memaksa pengguna itu dari pengguna itu. bekerja. Pendekatan yang lebih intuitif untuk penciptaan direktori memperlakukan file dengan nama itu sebagai kesalahan juga dianjurkan oleh kertas yang lebih baru WG21 P1164R0, revisi P1161R1 disepakati pada pertemuan Kona 2019 lihat Gabungan dan GCC dengan sekarang beralih ke mengikuti proposal (GCC #86910).
// methods in ghc::filesystem::path:
path& operator +=(basic_string_view<value_type> x);
int compare (basic_string_view<value_type> s) const ; Ini tidak diimplementasikan di bawah C ++ 11 dan C ++ 14, karena tidak ada std::basic_string_view tersedia dan saya ingin menjaga implementasi ini mandiri dan tidak menulis C ++ 17-Upgrade lengkap untuk C ++ 11/14. Dimulai dengan v1.1.0 ini didukung saat menyusun ghc::filesystem di bawah C ++ 17 dari C ++ 20.
Dimulai dengan v1.5.2 ghc::filesystem akan mencoba untuk memungkinkan penggunaan std::experimental::basic_string_view di mana ia mendeteksi adalah ketersediaan. Selain itu, jika Anda memiliki implementasi C ++ 11 yang kompatibel basic_string_view itu dapat digunakan sebagai pengganti std::basic_string_view dengan mendefinisikan GHC_HAS_CUSTOM_STRING_VIEW dan mengimpor implementasi ke dalam Namespace ghc::filesystem dengan:
namespace ghc {
namespace filesystem {
using my::basic_string_view;
}
}sebelum memasukkan header sistem file.
Untuk tidak bergantung pada perpustakaan pihak ketiga eksternal dan tetap tetap portabel dan ringkas, implementasi ini mengikuti filosofi "UTF-8 di mana-mana" dalam hal semua instance std::string akan ditafsirkan sama dengan std::u8string encoding bijak dan seperti berada di UTF-8. std::u16string akan dilihat sebagai UTF-16 dan std::u32string akan dilihat sebagai codepoint unicode. Bergantung pada ukuran std::wstring karakter, itu akan menangani std::wstring sebagai utf-16 (misalnya windows) atau codepoints unicode char32_t (saat ini semua platform lainnya).
Dimulai dengan V1.5.0 ghc::filesystem mengikuti standar C ++ 17 dalam menggunakan wchar_t dan std::wstring pada Windows sebagai jenis yang digunakan secara internal untuk representasi jalur. Masih dimungkinkan untuk mendapatkan perilaku lama dengan mendefinisikan GHC_WIN_DISABLE_WSTRING_STORAGE_TYPE dan mendapatkan filesystem::path::string_type sebagai std::string dan filesystem::path::value_type sebagai wchar_t .
Jika Anda perlu menghubungi beberapa Windows API, dengan v1.5.0 dan di atasnya, cukup gunakan W-Variant dari panggilan Windows-API (misalnya GetFileAttributesW(p.c_str()) ).
Catatan: Saat menggunakan perilaku lama dengan mendefinisikan GHC_WIN_DISABLE_WSTRING_STORAGE_TYPE , gunakan path::wstring() anggota (misalnya GetFileAttributesW(p.wstring().c_str()) ). Ini memberi Anda varian Unicode yang independen dari Makro UNICODE dan membuat kode berbagi antara Windows, Linux dan MacOS lebih mudah dan berfungsi dengan std::filesystem dan 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 ; Jenis pengembalian dari kedua metode ini tergantung pada standar C ++ yang digunakan dan jika GHC_FILESYSTEM_ENFORCE_CPP17_API didefinisikan. Pada C ++ 11, C ++ 14 dan C ++ 17 atau ketika GHC_FILESYSTEM_ENFORCE_CPP17_API didefinisikan, tipe pengembalian adalah std::string , dan pada c ++ 20 tanpa define itu adalah std::u8string .
Saya membuat entri wiki tentang cukup banyak perbedaan perilaku antara berbagai implementasi std::filesystem yang dapat mengakibatkan disebutkan di sini, tetapi readme ini hanya mencoba untuk mengatasi perbedaan pilihan desain antara ghc::filesystem dan itu. Saya mencoba memperbarui halaman wiki dari waktu ke waktu.
Pengamatan tambahan apa pun dipersilakan!
Sejak v1.5.0 Mekanika batin lengkap dari implementasi ini fs::path di mana diubah menjadi format asli sebagai representasi internal. Membuat Slash fs::path Object apa pun di bawah Windows (misalnya dengan "C:foo/bar" ) akan memimpin jalur bersih dengan "C:foobar" melalui native() dan "C:/foo/bar" melalui API generic_string() . Pada semua platform pemisah tambahan yang berlebihan dihapus, bahkan jika ini tidak ditegakkan oleh standar dan implementasi lainnya sebagian besar tidak melakukan ini.
Selain itu, implementasi ini mengikuti saran standar untuk menangani jalur POSIX dari bentuk "//host/path" dan jalur USC pada windows juga memiliki nama root (misalnya "//host" ). Implementasi GCC tidak memilih untuk melakukan itu saat menguji Ubuntu 18.04 dan MacOS dengan GCC 8.1.0 atau Clang 7.0.0. Perbedaan ini akan ditampilkan sebagai peringatan di bawah std::filesystem . This leads to a change in the algorithm described in the standard for operator/=(path& p) where any path p with p.is_absolute() will degrade to an assignment, while this implementation has the exception where *this == *this.root_name() and p == preferred_separator a normal append will be done, to allow:
fs::path p1 = " //host/foo/bar/file.txt " ;
fs::path p2;
for ( auto p : p1) p2 /= p;
ASSERT (p1 == p2);Untuk semua jalur non-host memimpin perilaku akan cocok dengan yang dijelaskan oleh standar.
Sebagai tautan simbolis pada Windows, sementara didukung lebih atau kurang sejak Windows Vista (dengan beberapa kendala keamanan yang ketat) dan sepenuhnya karena beberapa pembuatan Windows 10 sebelumnya, ketika "mode pengembang" diaktifkan, pada saat penulisan (2018) jarang digunakan, masih mereka didukung dengan implementasi ini.
Fitur izin Windows ACL diterjemahkan dengan buruk ke mask bit izin POSIX yang digunakan dalam antarmuka sistem file C ++ 17. Oleh karena itu, izin yang dikembalikan dalam file_status saat ini disintesis untuk tingkat user dan disalin ke group -dan tingkat other . Masih ada beberapa potensi untuk lebih banyak interaksi dengan sistem izin Windows, tetapi saat ini mengatur atau membaca izin dengan implementasi ini pasti tidak akan mengarah pada perilaku yang diharapkan.
extension() memang mengembalikan hasil yang tidak kosong untuk nama direktori ".."ghcFilesystem::ghc_filesystem sekarang ditetapkan tanpa syaratstem() , filename() dan extension() dari fs::path akan mengembalikan hasil yang salah jika usus besar berada di nama filefs::last_write_time(path, time, ec) Setter di iOS, TVOS dan WatchOSfs::directory_entry::refresh() sekarang, secara konsisten dengan status() tidak akan melempar symlink ke target yang tidak ada, tetapi buat entri memiliki file_type::not_found sebagai jenisnyaEINTR pada iterasi direktori POSIX dan salinan file untuk menghindari kesalahan pada sistem file jaringanfs::copy_file() Sekarang juga menyalin izinfs::copy_file() mengabaikan opsi skip_existing .GHC_NO_DIRENT_D_TYPE pada sistem yang tidak mendukung dirent::d_type dan memperbaiki konfigurasi dan pengujian untuk mendukung Solaris sebagai platform baru.PATH_MAX , satu didefinisikan.fs::remove_all sekarang hanya menghapus tautan simbolik alih -alih mengikutinya.fs::space di mana overflow numerik dapat terjadi dalam perkalian.fs::create_directories di windows tidak lagi pecah pada nama file yang panjang.ghc::filesystem yang diperlakukan folder/volume yang dipasang secara keliru sebagai symlink, memimpin fs::canonical gagal di jalur yang berisi itu.recursive_directory_iterator tidak akan mencoba memasuki symlink mati.fs::remove gagal ketika jalur menunjuk ke entri hanya baca, lihat juga (Microsoft/STL #1511) untuk masalah yang sesuai di std::fs di windows.GHC_NO_DIRENT_D_TYPE memungkinkan deteksi OS untuk mendukung sistem tanpa anggota dirent.d_type , Eksperimental First Qnx Compile Dukungan sebagai kasus penggunaan awal, tetap masalah dengan sistem file yang mengembalikan dt_unknown (EG Reiserfs).string_view saat dentingan dengan libstdc ++ terdeteksi.<Availability.h> dimasukkan sebelum <ghc/fs_std.hpp> atau <ghc/fs_std_fwd.hpp> / <ghc/fs_std_impl.hpp> .std::filesystem didukung, dan digantikan oleh nama bab seperti tag yang tetap (kebanyakan) konsisten atas versi.recursive_directory_iterator di atas pohon besar sekarang di suatu tempat antara libc ++ dan libstdc ++.ghc::filesystem sekarang memiliki dukungan awal untuk Cygwin. Perubahan di mana dilakukan untuk memungkinkan tes untuk dikompilasi dan dijalankan dengan sukses (diuji dengan GCC 10.2.0), umpan balik dan PR tambahan disambut karena saat ini bukan bagian dari konfigurasi CI.GHC_FILESYSTEM_BUILD_STD_TESTING untuk mengganti build tambahan dari std::filesystem versi tes untuk perbandingan dan kemungkinan untuk menggunakan fitur GHC_FILESYSTEM_TEST_COMPILE_FEATURES untuk lebih CMAKE_CXX_COMPILE_FEATURES .directory_entry membuat sekitar 20% -25% dalam pengujian dengan recursive_directory_iterator di atas pohon direktori yang lebih besar.wchar_t tidak ada dalam daftar jenis char yang didukung pada backend non-windows.string_view yang Ditingkatkan memanfaatkan <string_view> atau <experimental/string_view> bila tersedia, dan memungkinkan penggunaan implementasi basic_string_view khusus saat mendefinisikan GHC_HAS_CUSTOM_STRING_VIEW dan mengimpor header String ke dalam header ghc::filesystem Namespace sebelum termasuk file header. File.std::filesystem Tes sekarang terhubung dengan -lrt untuk menghindari masalah.fs::hard_link_count gagal karena perilaku sistem file, test case diadaptasi untuk memperhitungkannya.GHC_FS_API dan GHC_FS_API_CLASS sekarang dihormati ketika diatur dari luar untuk mengizinkan override perilaku.make install .GHC_FILESYSTEM_BUILD_TESTING , GHC_FILESYSTEM_BUILD_EXAMPLES dan GHC_FILESYSTEM_WITH_INSTALL di mana diimplementasikan, dilarang mengaturnya dari proyek induk saat menggunakan ini melalui add_subdirectory , perbaiki ini untuk mengaturnya lagi.fs::path awalnya dibuat dari implementasi berbasis POSIX adalah, dengan adaptasi dari string yang masuk dan keluar. Ini menghasilkan cache yang dapat berubah di dalam fs::path di windows, yang secara inheren tidak aman, bahkan untuk metode const . Untuk tidak menambahkan tambalan tambahan ke solusi suboptimal, kali ini saya mengerjakan ulang kode path untuk sekarang menyimpan representasi jalur asli . Ini mengubah banyak kode, tetapi ketika dikombinasikan dengan wchar_t karena value_type membantu menghindari banyak konversi untuk panggilan ke Win-API.fs::path::native() dan fs::path::c_str() sekarang dapat menjadi noexcept sebagai mandat standarwchar_t sekarang merupakan default untuk fs::path::value_type dan std::wstring adalah default untuk fs::path::string_type .const Metode fs::path tidak lagi menjadi masalahGHC_WIN_DISABLE_AUTO_PREFIXES , untuk semua jenis awalan atau namespaces lainnya mengikuti perilaku msvc std::filesystem::pathchar / std::string yang lama untuk windows masih diperlukan, itu dapat diaktifkan dengan GHC_WIN_DISABLE_WSTRING_STORAGE_TYPEfs::file_status sekarang mendukung operator== Diperkenalkan dalam std::filesystem dengan C ++ 20.fs::path::parent_path() memiliki masalah kinerja, karena masih menggunakan pendekatan berbasis loop untuk menciptakan kembali orang tua dari elemen. Ini menciptakan banyak temporari dan terlalu lambat terutama di jalur panjang.char8_t dan std::u8string didukung di mana Source adalah jenis parameterfs::path::u8string() dan fs::path::generic_u8string() Sekarang kembalikan std::u8string<=> sekarang didukung untuk fs::pathGHC_FILESYSTEM_ENFORCE_CPP17_API ghc::filesystem akan kembali ke fs::path::u8string() dan fs::path::generic_u8string()fs::proximate(p, ec) di mana panggilan internal ke fs::current_path() tidak menggunakan varian error_code , melemparkan kemungkinan pengecualian alih -alih mengatur ec .LWG_2936_BEHAVIOUR sekarang aktif secara default.Source yang merupakan tampilan string.constexpr .__MAC_OS_X_VERSION_MIN_REQUIRED untuk memastikan bahwa std::filesystem hanya dipilih pada macOS jika target penyebaran setidaknya Catalina.directory_iterator dan recursive_directory_iterator memiliki masalah dengan opsi skip_permission_denied , yang mengarah pada ketidakmampuan untuk melewatkan folder yang dilindungi SIP pada macOS._MSVC_LANG sekarang digunakan jika tersedia, selain __cplusplus , di header bantuan untuk memungkinkan mereka bekerja bahkan ketika /Zc:__cplusplus tidak digunakan.false pada fs::exists atau tidak ditemukan-kesalahan pada fs::status . Jalur Namespaced tidak disaring lagi.TestAllocator di filesystem_test.cpp diselesaikan untuk memenuhi persyaratan untuk membangun di CentOS 7 dengan devtoolset-9 . Centos 7 dan Centos 8 sekarang menjadi bagian dari pembuatan CI.LWG_2936_BEHAVIOUR yang memungkinkan untuk mengaktifkan pos C ++ 17 fs::path::compare perilaku, di mana perbandingannya seolah -olah itu adalah perbandingan jalur bijak elemen seperti yang dijelaskan dalam LWG 2936 dan C ++ 20 [fs.path.compare] . Ini default di v1.3.6 dan akan default mulai dari v1.4.0 karena mengubah pemesanan.wchar_t dari std::fstream dari ghc::filesystem::fstream Wrappers di Windows jika menggunakan GCC dengan LIBC ++.fs::directory_options::skip_permission_denied dan dukungan awal untuk kompilasi dengan emscripten.ghc::filesystem sekarang mendukung penggunaan dalam proyek dengan pengecualian yang dinonaktifkan. Tanda tangan API menggunakan pengecualian untuk penanganan kesalahan tidak tersedia dalam mode ini, terima kasih untuk PR (ini menyelesaikan #60 dan #43)ERROR_FILE_TOO_LARGE yang tidak ditentukan.fs::lexically_relative tidak mengabaikan slash trailing pada parameter pangkalan, terima kasih untuk 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.
