問題タブ [std-filesystem]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c++ - `std::filesystem::directory_iterator` コンパイラの問題
多くの人 (例1、2 ) が職場への行き方について尋ねてstd::filesystem::directory_iterator
きましたが、それらを読んでもまだ問題があります。
小さな静的ライブラリを構築しようとしています。ディレクトリ イテレータをいくつかのソース ファイルに追加した後、gcc を更新し、-lstdc++fs
ビットを追加しましたが、エラー メッセージが表示され続けるため、何も機能していないようです。
入力gcc --version
すると、取得します
そして、私がタイプgcc-8 --version
すると、
すべてをコンパイルする小さなシェル スクリプトを次に示します。他のバリエーションもいくつか試しました。
c++ - cmake istはスタティックライブラリ(c ++ fs)をリンカーコマンドの最後に配置していません
stdc++fs
(std::experimental::filesystem)へのリンクが機能しないという問題があります。
基本的に、ターゲットの呼び出しには次のものがあります。
その結果、
-lc++fs
静的ライブラリであるため、最後ではなく、リンクコマンドの途中にあるために失敗するのはどれですか? どうすればこれを回避できますか?また、cmake がこれを正しく実行できないのはなぜですか?つまり、リンカに正しい依存関係を提供することを意味します。ここで間違っていることは何ですか?
出力:
c++ - `std::filesystem::path` イテレータから `std::filesystem::path` を構築できないのはなぜですか?
次のコードは、パスが存在する場合にパスの最初の部分を削除することを目的としています。
(参照: https://godbolt.org/z/wkXhcw )
これがうまくいかないことに驚きました。パス コンストラクターは文字シーケンスを反復処理する反復子のみを受け取るため、コードはコンパイルされません。私はそれの使用を見ることができますが、なぜそれらの種類のイテレータだけに構築を制限するのですか? 私の意見では、独自のイテレータからのパスの構築をサポートしないのは直観に反します。私の知る限り、他のほとんどの STL タイプはこのイディオムをサポートしています。
新しいパスを完全に再構築する以外に、同じ目標を達成するための効率的な実装は何でしょうか?
更新: このコンテキストでは、次の議論が関連/面白いことがわかりました: http://boost.2283326.n4.nabble.com/boost-filesystem-path-frustration-td4641734.html。ここでデイブに同意します。パスをパス要素のコンテナーと見なすことは、(プログラマーの観点から) 非常に自然な見方だと思います。
c++ - Xcode で std::filesystem にリンクするライブラリ
Xcode 10.2 には<filesystem>
ヘッダーが含まれるようになりました。しかし、 を使用してコードを記述してstd::filesystem
いるときに、余分なリンク エラーが多数発生します。
ファイルシステムをサポートするために追加のライブラリをリンクする必要があると思いますが、それが何であるか、どこにあるかを特定できません。それが何と呼ばれているか分かりますか?
EDIT:libc ++はそれlibc++fs
が必要であると言いますが、少なくともデフォルトの検索ディレクトリでは、Xcodeで配布されていないようです。
c++ - filesystem::canonical を使用して、fstream に渡されるファイルパスのファイルパス インジェクションを防止できますか
pub
サブフォルダーとファイルを含むパブリック フォルダーがあります。ユーザーから相対ファイルパスが渡され、いくつかのマッピングを実行し、ファイルを読み取ってfstream
ユーザーに返します。
問題は、ユーザーが../fileXY.txt
パストラバーサルやその他のタイプのファイルパスインジェクションを考慮して、たとえば、またはその他の派手なもののようなパスを提供した場合です。fstream
それを受け入れて、私のパブリックpub
フォルダーの外にある可能性のあるファイルを読み取るか、さらに悪いことに、システム上のすべてのファイルのリストを提供します... .
車輪を再発明する前に、ファイルシステム ライブラリを検索したところ、このstd::filesystem::canonical関数があり、通常の形式についてかなりの話があることがわかりました。ここで一般的な質問があります。この関数とバリアントstd::filesystem::weakly_canonicalを使用して、この種の脆弱性を防ぐことはできますか? では、基本的には十分でしょうか?
さらに、私のシステムのファイルシステム ライブラリはまだ実験モードであり、std::filesystem::weakly_canonical
がありません。しかしcanonical
、ファイルは に存在する必要があるため、を使用できませんcanonical
。私の場合、特定のマッピングがあり、その意味でファイルは存在しません。したがって、weakly_canonical
関数を模倣する必要がありますが、どうすればよいでしょうか?
存在しないパスのリアルパスに関する関連するスタックオーバーフローの質問を見たことがあります。パスが存在する限り正規を繰り返してから、存在しない部分を追加するように提案されましたが、これもこれらのタイプのインジェクションに対して脆弱です。それで、自分でロールバックする必要がありますか、それともいくつかの機能weakly_canonical
を組み合わせて何とか模倣できますか?std::experimental::filesystem