filesystem
v1.5.14
ghc::filesystem::ifstream 、 ghc::filesystem::ofstream 、 ghc::filesystem::fstreamghc::filesystem::u8argumentsこれは、C ++ 17およびC ++ 20の仕様に基づいて、ヘッダーのみのシングルファイルstd::filesystem互換ヘルパーライブラリですが、C ++ 11、C ++ 14、C ++ 17またはC ++ 20のために実装されています（文書化された例外はほとんどなくC ++ 17標準に従っています）。現在、MACOS 10.12/10.14/10.15/11.6、Windows 10、Ubuntu 18.04、Ubuntu 20.04、Centos 7、Centos 8、FreeBSD 12、Alpine ARM/ARM64 LinuxおよびSolaris 10でテストされていますが、他のシステムでも、C ++ 11の複雑なコンピルを使用している限り、他のシステムでも動作するはずです。 Android NDK、emscripten、および私は、iOSで使用されているという報告（サンドボックスの制約内）で動作するはずであり、v1.5.6でQNXの実験的サポートがあります。 Android NDK、Emscripten、QNX、および1.5.14 GNU/HurdおよびHaiku以降のサポートは自動化されたテストによってバックアップされていませんが、PRSおよびバグレポートもそれらを歓迎し、機能すると報告されています。もちろん、独自の名前空間ghc::filesystem通常のstd::filesystemを妨害しないようにします。混合C ++ 17環境で使用する場合（可能です）。
テストカバレッジは90％を大きく上回っており、v1.3.6から始まり、v1.5.0では、ライブラリのベンチマークと最適化にさらに時間が投資されました。一部の部品を最適化し、他の部品をリファクタリングし続け、追加のC ++ 17/C ++ 20の互換性の問題を導入しない限り、改善に努めています。フィードバックはいつでも大歓迎です。何かが欠けている、間違っているか、予想どおりに動作していない場合に問題を開くだけでコメントします。
私は多くの場合、ファイルシステムの機能を必要としていますが、ほとんどがfs::pathですが、ディレクトリアクセスもあります。C++ 11を使用し始めたとき、その言語の更新を使用してサードパーティの依存関係を削減しようとしました。使用したもののほとんどを落とすことができましたが、それでも私がそれを楽しんで実装し始めたものを逃しました。もともと私はこれらのヘルパーを自分のコーディングと命名の規則に基づいています。 C ++ 17が確定したとき、私はそのインターフェイスを使用したかったのですが、クラスを変換するために自分自身を押し進めるのに時間がかかりました。
この実装は、C ++ 17標準の第30.10章に密接に基づいており、そのバージョンに近いドラフトは、ドラフトN4687の動作です。 C ++ 17の標準化後のものですが、作業ドラフトN4659と比較して、最新のファイルシステムインターフェイスの変更が含まれています。 v1.4.0を凝視すると、C ++ 20を使用してコンパイルされると、パスソート順序とstd::u8stringドラフトN4860からの変更に応じて変化に適応します。
C ++の改善に取り組んでいる人々に感謝したいと思います。C++ 11と次の基準で言語がどのように進化したかが本当に気に入りました。良い仕事を続けてください！
ghcが立っていることを自問すると、それは単にgulraks helper classesです。ええ、あまり想像力豊かではありませんが、短い名前空間が欲しかったので、プライベートクラスのいくつかで使用します（ Haskellとは何の関係もありません。
ghc::filesystemはMacOSで開発されていますが、CIはMACO、Windows、さまざまなLinux分布、FreeBSDでテストされ、SolarisのV1.5.12でテストされています。 C ++ 11対応コンパイラを使用して、これらのいずれかで動作するはずです。また、Androidでの作業がうまくいくためのいくつかのチェックがありますが、現在Android NDKでテストしていないため、まだサポートされているプラットフォームとは呼ばず、Emscriptenで使用する場合も同じです。現在、検出されたプラットフォームの一部であり、明らかな問題を修正し、テストを実行したため、問題ありません。全体として、完全なC ++ 17またはC ++ 20が利用可能なstd::filesystemに置き換えることはありません。「より良い」 std::filesystemではなく、使用できない場合はほとんどドロップインします（UTF-8の好みを除く）。
重要：この実装は、すべてのstd::stringインスタンスがstd::u8stringを賢明にエンコードし、UTF-8であると解釈されるという点で、「UTF-8 Everywhere Where Where Where Where Where Whery」哲学に従っています。 std::u16string UTF-16と見なされます。詳細については、 APIの違いを参照してください。
現在、ユニットテストは次のように実行されます。
ヘッダーにはユニットテストのセットが付属しており、CMakeをビルドツールとして使用し、Catch2をテストフレームワークとして使用します。すべてのテストはcmakeで登録されているため、CTESTコマンドーを使用してテストを実行できます。
この実装に対するすべてのテストは成功する必要があります。環境に応じて、いくつかの警告がある可能性があります。
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で、ソースアーカイブはここにあります。
現在、最新のマイナーリリースバージョンのみがBugfixesを受信しているため、可能であれば、最新リリースを使用する必要があります。
ghc::filesystem最初はヘッダーのみのライブラリであるため、ヘッダーまたはinclude/ghcディレクトリをプロジェクトフォルダーにコピーするか、この場所へのパスをfilesystem.hppヘッダー（またはghc/filesystem.hppを使用する場合は、単にsub-directory.hppヘッダーを含めるだけで十分です。
すべてが名前空間ghc::filesystemにあるので、それをフォールバックとしてのみ使用する1つの方法は次のとおりです。
# if _MSVC_LANG >= 201703L || __cplusplus >= 201703L && defined(__has_include)
// ^ Supports MSVC prior to 15.7 without setting /Zc:__cplusplus to fix __cplusplus
// _MSVC_LANG works regardless. But without the switch, the compiler always reported 199711L: https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/
# if __has_include(<filesystem>) // Two stage __has_include needed for MSVC 2015 and per https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
# define GHC_USE_STD_FS
// Old Apple OSs don't support std::filesystem, though the header is available at compile
// time. In particular, std::filesystem is unavailable before macOS 10.15, iOS/tvOS 13.0,
// and watchOS 6.0.
# ifdef __APPLE__
# include < Availability.h >
// Note: This intentionally uses std::filesystem on any new Apple OS, like visionOS
// released after std::filesystem, where std::filesystem is always available.
// (All other __<platform>_VERSION_MIN_REQUIREDs will be undefined and thus 0.)
# if __MAC_OS_X_VERSION_MIN_REQUIRED && __MAC_OS_X_VERSION_MIN_REQUIRED < 101500
|| __IPHONE_OS_VERSION_MIN_REQUIRED && __IPHONE_OS_VERSION_MIN_REQUIRED < 130000
|| __TV_OS_VERSION_MIN_REQUIRED && __TV_OS_VERSION_MIN_REQUIRED < 130000
|| __WATCH_OS_VERSION_MAX_ALLOWED && __WATCH_OS_VERSION_MAX_ALLOWED < 60000
# undef GHC_USE_STD_FS
# endif
# endif
# endif
# endif
# ifdef GHC_USE_STD_FS
# include < filesystem >
namespace fs = std::filesystem;
# else
# include " filesystem.hpp "
namespace fs = ghc::filesystem;
# endif fstreamラッパーをフォールバックとしてpathサポートで使用する場合は、次のことを使用できます。
# if _MSVC_LANG >= 201703L || __cplusplus >= 201703L && defined(__has_include)
// ^ Supports MSVC prior to 15.7 without setting /Zc:__cplusplus to fix __cplusplus
// _MSVC_LANG works regardless. But without the switch, the compiler always reported 199711L: https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/
# if __has_include(<filesystem>) // Two stage __has_include needed for MSVC 2015 and per https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
# define GHC_USE_STD_FS
// Old Apple OSs don't support std::filesystem, though the header is available at compile
// time. In particular, std::filesystem is unavailable before macOS 10.15, iOS/tvOS 13.0,
// and watchOS 6.0.
# ifdef __APPLE__
# include < Availability.h >
// Note: This intentionally uses std::filesystem on any new Apple OS, like visionOS
// released after std::filesystem, where std::filesystem is always available.
// (All other __<platform>_VERSION_MIN_REQUIREDs will be undefined and thus 0.)
# if __MAC_OS_X_VERSION_MIN_REQUIRED && __MAC_OS_X_VERSION_MIN_REQUIRED < 101500
|| __IPHONE_OS_VERSION_MIN_REQUIRED && __IPHONE_OS_VERSION_MIN_REQUIRED < 130000
|| __TV_OS_VERSION_MIN_REQUIRED && __TV_OS_VERSION_MIN_REQUIRED < 130000
|| __WATCH_OS_VERSION_MAX_ALLOWED && __WATCH_OS_VERSION_MAX_ALLOWED < 60000
# undef GHC_USE_STD_FS
# endif
# endif
# endif
# endif
# ifdef GHC_USE_STD_FS
# include < filesystem >
namespace fs {
using namespace std ::filesystem ;
using ifstream = std::ifstream;
using ofstream = std::ofstream;
using fstream = std::fstream;
}
# else
# include " filesystem.hpp "
namespace fs {
using namespace ghc ::filesystem ;
using ifstream = ghc::filesystem::ifstream;
using ofstream = ghc::filesystem::ofstream;
using fstream = ghc::filesystem::fstream;
}
# endifこれでfs::ofstream out(somePath);そして、それはラッパーまたはC ++ 17 std::ofstreamいずれかです。
ヘッダーのみのライブラリとして、それはシステムを使用しているという事実を隠しているわけではないので、彼らはあなたのグローバルネームスペースを「汚染」します。これを避けるには、転送/実装ハイダーベースのアプローチ（以下を参照）を使用します。 Windowsの場合、 Windows.hが必要であるため、 filesystem.hppまたはfs_std.hppヘッダーを含める前に、 WIN32_LEAN_AND_MEANまたはNOMINMAXを定義して、グローバルネームスペースの汚染とコンパイル時間を削減することをお勧めします。 ghc::filesystemによって定義されていません。これは、UI要素の場合、完全なWindows.hが必要なコンテキストとの組み合わせを許可します。
ヒント： ghc/fs_std.hppという名前の追加のヘッダーがあり、ファイルシステムの実装のこの動的な選択を実装します。これは、 ghc/filesystem.hppの代わりにstd::filesystemが必要な場合は、 ghc::filesystemが必要な場合に含めることができます。
または、v1.1.0から始まるghc::filesystem 、2つの追加のラッパーヘッダーのいずれかを含めることも使用できます。これらを使用すると、ほとんどの場所（ ghc/fs_fwd.hpp ）に転送バージョンを含めることができ、 ghc/fs_impl.hppを含む単一のCPPファイルに実装の詳細を隠して、必要なコードを実装します。この方法でghc::filesystemを使用すると、CPPファイル内からのみシステムが表示されるようになり、他のすべての場所はクリーンです。
インターフェイス内のC ++標準テンプレートを使用したDLLインターフェイスは別の獣であるため、現在はWindows-DLLに実装を隠すことはサポートされていないことに注意してください。誰かがそれを試してみたいと思うなら、私はPRを統合するかもしれませんが、現在それに取り組んでいることは優先事項ではありません。
転送/実装アプローチを使用する場合でも、次のような動的スイッチングを使用できます。
# if _MSVC_LANG >= 201703L || __cplusplus >= 201703L && defined(__has_include)
// ^ Supports MSVC prior to 15.7 without setting /Zc:__cplusplus to fix __cplusplus
// _MSVC_LANG works regardless. But without the switch, the compiler always reported 199711L: https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/
# if __has_include(<filesystem>) // Two stage __has_include needed for MSVC 2015 and per https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
# define GHC_USE_STD_FS
// Old Apple OSs don't support std::filesystem, though the header is available at compile
// time. In particular, std::filesystem is unavailable before macOS 10.15, iOS/tvOS 13.0,
// and watchOS 6.0.
# ifdef __APPLE__
# include < Availability.h >
// Note: This intentionally uses std::filesystem on any new Apple OS, like visionOS
// released after std::filesystem, where std::filesystem is always available.
// (All other __<platform>_VERSION_MIN_REQUIREDs will be undefined and thus 0.)
# if __MAC_OS_X_VERSION_MIN_REQUIRED && __MAC_OS_X_VERSION_MIN_REQUIRED < 101500
|| __IPHONE_OS_VERSION_MIN_REQUIRED && __IPHONE_OS_VERSION_MIN_REQUIRED < 130000
|| __TV_OS_VERSION_MIN_REQUIRED && __TV_OS_VERSION_MIN_REQUIRED < 130000
|| __WATCH_OS_VERSION_MAX_ALLOWED && __WATCH_OS_VERSION_MAX_ALLOWED < 60000
# undef GHC_USE_STD_FS
# endif
# endif
# endif
# endif
# ifdef GHC_USE_STD_FS
# include < filesystem >
namespace fs {
using namespace std ::filesystem ;
using ifstream = std::ifstream;
using ofstream = std::ofstream;
using fstream = std::fstream;
}
# else
# include " fs_fwd.hpp "
namespace fs {
using namespace ghc ::filesystem ;
using ifstream = ghc::filesystem::ifstream;
using ofstream = ghc::filesystem::ofstream;
using fstream = ghc::filesystem::fstream;
}
# endifそして、CPPを隠す実装では、（ ghc/fs_fwd.hppを含む含まれるものがあり、優先順位を取得することができます。
# if _MSVC_LANG >= 201703L || __cplusplus >= 201703L && defined(__has_include)
// ^ Supports MSVC prior to 15.7 without setting /Zc:__cplusplus to fix __cplusplus
// _MSVC_LANG works regardless. But without the switch, the compiler always reported 199711L: https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/
# if __has_include(<filesystem>) // Two stage __has_include needed for MSVC 2015 and per https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
# define GHC_USE_STD_FS
// Old Apple OSs don't support std::filesystem, though the header is available at compile
// time. In particular, std::filesystem is unavailable before macOS 10.15, iOS/tvOS 13.0,
// and watchOS 6.0.
# ifdef __APPLE__
# include < Availability.h >
// Note: This intentionally uses std::filesystem on any new Apple OS, like visionOS
// released after std::filesystem, where std::filesystem is always available.
// (All other __<platform>_VERSION_MIN_REQUIREDs will be undefined and thus 0.)
# if __MAC_OS_X_VERSION_MIN_REQUIRED && __MAC_OS_X_VERSION_MIN_REQUIRED < 101500
|| __IPHONE_OS_VERSION_MIN_REQUIRED && __IPHONE_OS_VERSION_MIN_REQUIRED < 130000
|| __TV_OS_VERSION_MIN_REQUIRED && __TV_OS_VERSION_MIN_REQUIRED < 130000
|| __WATCH_OS_VERSION_MAX_ALLOWED && __WATCH_OS_VERSION_MAX_ALLOWED < 60000
# undef GHC_USE_STD_FS
# endif
# endif
# endif
# endif
# ifndef GHC_USE_STD_FS
# include " fs_impl.hpp "
# endifヒント：この手法を使用するghc/fs_std_fwd.hppとghc/fs_std_impl.hppという名前の追加のヘルパーヘッダーがあります。そのため、ファイルシステムの実装を動的に選択する場合は、簡単に含めることができます。
v1.1.0から始めて、 ghc::filesystem GITサブモジュールとして追加し、 add_subdirectory()を使用してCMakeLists.txtにディレクトリを追加し、ターゲット_link_libraries（Your-target #include <ghc/filesystem.hpp> target_link_libraries(your-target ghc_filesystem)を使用して、正しいパスを含めることができるようにします。
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 -Compile std_filesystem_test 、 std::filesystemに対して実行されているテストスイートのバリアント、 GHC_FILESYSTEM_BUILD_TESTINGにデフォルト。これは、コンパイラがそれを行うことができると検出された場合にのみ行われます。GHC_FILESYSTEM_TEST_COMPILE_FEATURES 、 CMAKE_CXX_COMPILE_FEATURESオーバーライドする機能のリストに設定できます。CMAKE_CXX_COMPILE_FEATURES追加テストのためにC ++ 17またはC ++ 20の検出が機能していない場合（例えば、 cxx_std_20作成して、C ++ 20でfilesystem_test_cpp20を作成します。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をコンパイルする場合、APIはC ++ 17標準に従っていますが、 std::string_viewパラメーターはC ++ 17でのみサポートされていることを除きます。 C ++ 20でコンパイルすると、 ghc::filesysytem 、 char8_tおよびstd::u8stringインターフェイスと非推奨fs::u8pathファクトリーメソッドを使用して、C ++ 20 APIにデフォルトです。
注： C ++ 17 APIをC ++ 20モードでも施行する必要がある場合は、define GHC_FILESYSTEM_ENFORCE_CPP17_APIを使用します。それでも、 std::u8stringからfws::pathを作成することができますが、 fs::path::u8string()およびfs::path::generic_u8string() return normal utf-8エンコードstd::string instancesであるため、c ++ 17のコードはまだghc::filesystemで動作する可能性があります。
標準への唯一の追加はここに記載されています：
ghc::filesystem::ifstream 、 ghc::filesystem::ofstream 、 ghc::filesystem::fstreamこれらはstd::ifstream 、 std::ofstreamおよびstd::fstream周辺の単純なラッパーです。 C ++ 17のfstreamバリアントが持っているように、 ghc::filesystem::path引数を備えたopen()メソッドとコンストラクターを追加するだけです。
ghc::filesystem::u8argumentsこれは、現在、非windowsプラットフォームでUTF-8エンコードをチェックしているヘルパークラスですが、Windowsでは、OSの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 、 mainからのスコープが有効である限り、UTF-8エンコードされます。
注： macOSでは、Xcode LC_ALL下でデバッグ中に、Xcodeが実際に使用されていても、XcodeがEncodingとしてUS-ASCIIを使用してアプリケーションを開始すると、コードが現在false返します。私はまだこれを調査する必要があります。
この実装は、私のプライベートヘルパークラスの既存のコードに基づいているため、それのいくつかの制約を導き出しました。 v1.5.0から始まるこの違いのほとんどと標準のC ++ 17/C ++ 20 APIが削除された場合。
この実装には、LWG欠陥＃2682、＃2935、＃2936および＃2937に対して切り替え可能な動作があります。現在選択されている動作（v1.4.0から始まる）は、＃2682、＃2936、＃2937に続いていますが、＃2935を追跡していませんfs::is_directory create_directory()またはcreate_directories()にエラーを報告しないことはバグだと感じています。働いた。その名前でファイルをエラーとして処理するディレクトリの作成に対するより直感的なアプローチは、新しい論文WG21 P1164R0によっても提唱されているため、改訂P1161R1はKONA 2019会議で合意されました。
// methods in ghc::filesystem::path:
path& operator +=(basic_string_view<value_type> x);
int compare (basic_string_view<value_type> s) const ; std::basic_string_view利用できないため、C ++ 11およびC ++ 14の下では実装されていません。この実装を自己完結型に保ち、C ++ 11/14の完全なC ++ 17アップグレードを書きませんでした。 V1.1.0から始めて、これらはC ++ 20のC ++ 17の下でghc::filesystemをコンパイルするときにサポートされます。
V1.5.2から始めるghc::filesystem std::experimental::basic_string_viewを検出する場所を使用できるようにします。さらに、 basic_string_view互換性のあるc ++ 11の実装がある場合は、 GHC_HAS_CUSTOM_STRING_VIEWを定義し、 ghc::filesystem namespaceに実装をインポートすることにより、 std::basic_string_viewの代わりに使用できます。
namespace ghc {
namespace filesystem {
using my::basic_string_view;
}
}ファイルシステムヘッダーを含める前。
外部のサードパーティライブラリに依存しないため、ポータブルでコンパクトなままであるために、この実装は、すべてのstd::stringインスタンスがstd::u8stringエンコードと同じようにUTF-8にあると解釈されるという「UTF-8どこでも」哲学に従っています。 std::u16string 、UTF-16およびstd::u32stringと見なされ、Unicode CodePointsと見なされます。 std::wstring文字のサイズに応じて、 std::wstring UTF-16（Windows）またはchar32_t Unicode CodePoints（現在は他のすべてのプラットフォーム）として処理します。
V1.5.0から始まるghc::filesystem 、パス表現に内部的に使用されるタイプとして、 wchar_tおよびstd::wstringを使用する際にC ++ 17標準に従っています。 GHC_WIN_DISABLE_WSTRING_STORAGE_TYPE :: STRING_TYPE AS std::stringおよびfilesystem::path::value_type AS wchar_tとしてGet filesystem::path::string_typeを取得することにより、古い動作を取得することはまだ可能です。
v1.5.0以降でWindows APIを呼び出す必要がある場合は、Windows-API呼び出しのw-Variant（ 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 ;これら2つの方法の返品タイプは、使用されている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実装の間に非常に多くの行動の違いについてWikiエントリを作成しましたが、このREADMEはghc::filesystemとそれらの間の設計選択の違いにのみ対処しようとします。 Wikiページを時々更新しようとしています。
追加の観察は大歓迎です！
v1.5.0以来、この実装の完全な内部メカニズムfs::pathが内部表現としてネイティブ形式に変更されました。混合スラッシュfs::path Windows（ "C:foo/bar"など）の下にあるパスオブジェクトを作成すると、 native()およびgeneric_string() APIを介して"C:foobar"を介して"C:/foo/bar"を使用してクリーンパスをリードします。すべてのプラットフォームでは、これが標準で施行されていなくても、他の実装によって施行されていなくても、冗長な追加のセパレータが削除されます。
さらに、この実装は、フォーム"//host/path"のPOSIXパスとWindowsのUSCパスをルート名（ "//host"など）とも処理するための標準提案に従います。 GCCの実装は、Ubuntu 18.04とGCC 8.1.0またはClang 7.0.0のMacOSでテスト中にそれを選択しませんでした。この違いはstd::filesystemの下で警告として表示されます。これは*this == *this.root_name() p.is_absolute()を搭載したパスpが割り当てに分解する場合、 operator/=(path& p)の標準で説明されて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の以前のビルド以降、執筆時にはめったに使用されないため、この実装がめったにサポートされていません。
Windows ACL許可機能は、C ++ 17ファイルシステムのインターフェイスで使用されるPOSIX許可ビットマスクにひどく変換されます。したがってother file_statusで返される権限は現在、 userレベル用に合成され、 groupにコピーされています。 Windows許可システムとの相互作用の可能性はまだいくつかありますが、現在、この実装で許可を設定または読み取りすることは、予想される動作につながることはありません。
extension()ディレクトリ名".."ghcFilesystem::ghc_filesystemが無条件に設定されるようになりましたfs::pathのposix stem() 、 filename() 、 extension()で、コロンがファイル名にある場合、パスは間違った結果を返しますfs::last_write_time(path, time, ec) ios、tvos、watchosのセッターを修正fs::directory_entry::refresh()を修正しましたが、 status()は一貫してSymlinksを存在しないターゲットにスローしませんが、エントリにfile_type::not_foundを型にします。EINTRを処理し、ネットワークファイルシステムのエラーを回避するためにコピーをファイルしますfs::copy_file()もアクセス許可をコピーしますskip_existingオプションを無視して、 fs::copy_file()の修正＃143をプルします。dirent::d_typeをサポートしないシステムでGHC_NO_DIRENT_D_TYPEの必要性が削除され、Solarisを新しいプラットフォームとしてサポートするためのビルド構成とテストを固定しました。PATH_MAXがない場合、プラットフォームがPOSIXバックエンドを使用している場合、1つが定義されています。fs::remove_all 、それらをフォローする代わりにシンボリックリンクを削除するだけです。fs::spaceを修正します。fs::create_directories長いファイル名で壊れなくなります。ghc::filesystemはマウントされたフォルダー/ボリュームをシンリンクとして誤って扱い、それらを含むパスで故障するようにfs::canonicalリードします。recursive_directory_iteratorをインクリメントすることで、デッドシンリンクに入ろうとはなりません。fs::removeパスが読み取り専用エントリを指したときに失敗しました。Windowsのstd::fsの対応する問題については（Microsoft/STL＃1511）も参照してください。GHC_NO_DIRENT_D_TYPE使用すると、OS検出がdirent.d_typeメンバーなしでシステムをサポートすることができます。string_viewサポートを追加しました。<ghc/fs_std.hpp>または< <ghc/fs_std_fwd.hpp> >/ <ghc/fs_std_impl.hpp>の前に<Availability.h>が含まれていた場合にのみ機能した場合にのみ機能しました。std::filesystem機能がサポートされているため、標準の章番号の使用は誤解を招き、バージョン上で（ほとんど）一貫しているタグのような章名に置き換えられました。recursive_directory_iteratorのパフォーマンス。ghc::filesystem 、Cygwinを予備的にサポートしています。テストをコンパイルして正常に実行できるようにするために行われた変更（GCC 10.2.0でテスト）、フィードバックと追加のPRは、現在CI構成の一部ではないためです。GHC_FILESYSTEM_BUILD_STD_TESTING std::filesystem files -stystem of test of test of test of test of test of test of test of raption and filet in futing fute fill CMAKE_CXX_COMPILE_FEATURES GHC_FILESYSTEM_TEST_COMPILE_FEATURES not now not now not not not not not not not not not not not notにdirectory_entry作成は、より大きなディレクトリツリー上のrecursive_directory_iteratorを使用したテストで約20％-25％になります。wchar_t 、非ワインドバックエンドのサポートされているcharタイプのリストに載っていませんでした。string_viewサポートを改善した場合、使用可能な場合は<string_view>または<experimental/string_view>を使用し、 GHC_HAS_CUSTOM_STRING_VIEWを定義するときにカスタムbasic_string_view実装を使用し、stringビューを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のWindowsバージョンは、もともとPOSIXベースの実装から作成されたものでした。これにより、Windows上のfs::path内の可変キャッシュが発生しました。これは、 constメソッドであっても、本質的にスレッドセーフではありませんでした。追加のパッチを準最適なソリューションに追加しないように、今回はpathコードを作り直して、ネイティブのパス表現を保存しました。これにより多くのコードが変更されましたが、 value_typeとしてwchar_tと組み合わせると、win-apiへの呼び出しのための多くの変換を回避するのに役立ちました。fs::path::native()およびfs::path::c_str() 、標準のマンデートとしてnoexceptなりますwchar_t fs::path::value_typeおよびstd::wstringのデフォルトになりましたfs::path::string_typeのデフォルトです。fs::pathのconstメソッドのスレッドセーフティはもはや問題ではありませんGHC_WIN_DISABLE_AUTO_PREFIXES std::filesystem::path定義して無効にできるようになりました。他のすべてのタイプのプレフィックスまたは名前空間についてchar / std::stringベースのアプローチがまだ必要な場合、 GHC_WIN_DISABLE_WSTRING_STORAGE_TYPEでアクティブにすることができますfs::file_status 、c ++ 20のstd::filesystemで導入されたoperator==サポートするようになりました。fs::path::parent_path()にはパフォーマンスの問題がありました。これは、要素から親を再現するためのループベースのアプローチを使用していたためです。これは多くの一時的なものを生み出し、特に長い道のりでは遅すぎました。char8_tおよびstd::u8stringはサポートされています。 Sourceがパラメータータイプですfs::path::u8string()およびfs::path::generic_u8string()は、 std::u8stringを返します<=>は、 fs::pathでサポートされていますGHC_FILESYSTEM_ENFORCE_CPP17_API ghc::filesystem古いfs::path::u8string()およびfs::path::generic_u8string() apiに戻ります。fs::proximate(p, ec)のbugfix fs::current_path()への内部呼び出しがerror_codeバリアントを使用していなかったため、 ecを設定する代わりに可能な例外をスローします。LWG_2936_BEHAVIOURはデフォルトでオンになっています。Sourceパラメーターの処理に関する問題を修正しました。constexprです。__MAC_OS_X_VERSION_MIN_REQUIREDを使用して、展開ターゲットが少なくともカタリナである場合にstd::filesystemがMACOでのみ選択されることを確認します。directory_iterator 、およびrecursive_directory_iterator 、 skip_permission_deniedオプションに問題があり、MacosのSIP保護フォルダーをスキップできないことにつながります。_MSVC_LANGは、 /Zc:__cplusplus cplusplusが使用されていても、 __cplusplusに加えて、__cplusplusに加えて、__cplusplusに加えて使用されるようになりました。fs::existsまたはfswound-errorsにfalse fs::statusにfalseにつながるマッピングボリュームを繰り返します。名前空間パスはもうフィルタリングされていません。filesystem_test.cppのTestAllocator完成し、 devtoolset-9でCentos 7に構築する要件を満たしました。 Centos 7とCentos 8は、CIビルドの一部になりました。LWG_2936_BEHAVIOURも追加されます。これにより、C ++ 17 fs::path::compare PATHを有効にします。これは、LWG 2936およびC ++ 20 [fs.path.compare]で説明されている要素ワイズパス比較であるかのようです。 v1.3.6ではデフォルトであり、注文が変更されるため、v1.4.0からデフォルトになります。ghc::filesystem::fstreamラッパーのstd::fstreamのwchar_tバージョンを使用します。fs::directory_options::skip_permission_deniedを使用する場合のディレクトリイテレーターの許可問題のより良い処理とemscriptenとのコンパイルの初期サポート。ghc::filesystem 、障害のある例外を備えたプロジェクトでの使用をサポートするようになりました。エラー処理の例外を使用したAPI署名は、このモードでは利用できません。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.
