3

関数boost::filesystem::canonical()( 1.66のドキュメント、現在のリリースのドキュメント) は 2 つの引数を提供します (エラー コードのオーバーロードを無視します) base。最初の引数は正規化するパスです。2 番目の引数は、最初のパスが相対パスの場合に絶対パスにするために使用されるベース パスです。デフォルトでは、 current_path()がこの引数に使用されます。

Boost 1.60 では、いくつかの新機能が導入されていますboost::filesystem::weakly_canonical()( 1.66のドキュメント、現在のリリースのドキュメント)。この関数には、この 2 番目の引数がありません。標準化された (C++17) バリアントstd::filesystem::canonical()とstd::filesystem::weakly_canonical()( cppreferenceを参照) についても同じことが言えます。

canonical()と交換したいのですweakly_canonical()が、第二引数を使いました。それが、この議論が削除されたことに気付いた方法です。なぜそれが削除されたのか、どうすれば自分でパスを絶対にすることができるのか疑問に思っています。

C++17 のこの解決策をほのめかす欠陥レポートを見つけましたが、率直に言って、その根拠はよくわかりません。説明や、ベースのオーバーロードが過剰に指定されている例があれば幸いです。

そしてもちろん、現在のディレクトリではないベースディレクトリを使用して、相対パスを絶対パスに変換する方法を考えています。これが私のターゲット システム (Visual C++ を使用する Windows) で正しい形式であることがわかっているため、 cppreference for でbase / p示唆されているとおりに使用する必要がありますか?std::filesystem::absolute()

4

1 に答える 1

0

OK、相対パスがあり、そのような関数を呼び出したい場合の状況は次のとおりです。

  1. パスはcurrent_path.
  2. を呼び出すことでパスを絶対パスにすることができますabsolute。Windows のようなファイルシステムのおかげで、これはcurrent_path.
  3. パスが、現在のパスではない既知のパスに相対的であることはわかっていabsolute_pathます。
  4. パスが相対かどうかはわかりません。

ケース #4 の場合、最初のステップは、それが相対的かどうか、相対的である場合は何に対して相対的かを調べる必要があります。それが完了すると、ケース 1 ～ 3 に戻ります。

ケース 1 ～ 3 のそれぞれで、絶対パスを計算する直接的な方法があります。ケース 1 では、 を使用しますcurrent_path() / rel。ケース 2 では、 を使用しますabsolute(rel)。ケース 3 では、 を使用しますabsolute_path / rel。(注: これは「私のターゲット システム (Visual C++ を使用する Windows) での正しい形式」であるだけでなく、正しい形式の期間でもあります。)

の元のバージョンでcanonical/weakly_canonicalは、関数はケース 1 と 3 のみを処理しました。ケース 2 は関数内で処理できませんでした。関数を下位レベルにすることでabsolute、デフォルトのベース パスではなく相対パスを使用するcurrent_path()ようにすることで、関数はケース 2 と他のケースを処理できます。

current_path()を使用するパス（デフォルトではなく）を取らないオーバーロードが存在するように、彼らはそれを変更できたはずですabsolute。canonical(rel, absolute_path)しかし、実際には、との違いは何canonical(absolute_path / rel)ですか? 実際、後者は絶対パスを左側に配置するため、何をしているのかがより明確になります。

于 2018-01-12T16:40:22.517 に答える