| ■17599 / ) |
Re[20]: フォルダ内のファイル名を取得する方法 |
□投稿者/ れい (513回)-(2008/04/28(Mon) 03:09:51)
|
2008/04/28(Mon) 03:18:26 編集(投稿者)
■No17597 (ネタ好き さん) に返信
> れいさんはファイルドライバを今まさに探求しているだけにすごく的確です。
実際作ってみて、
Win32APIを眺めてるだけでは理解できなかった部分のなぞがだいぶ解けました。
Windowsのファイルシステムは
ディレクトリエントリのリスティングと「リネーム」が非常に特徴的で、
設計思想がよく出ていると思います。
> 成る程、カーネルモードとユーザモードの切り替えコストを考えると、
> （モード切替は確かに遅い）
> カーネルモードでの処理時間を長くするために、Windowsに任せると良いというのは納得出来る判断です。
・問合せ/返信という形で要求する。問合せ側がバッファを用意する。
・バッファの自動伸長はない
・ディレクトリ構造はFS依存
・ファイル名は可変長。
・問合せ中にディレクトリを排他ロックしたくない
・何個エントリがあるのか分からない。個数の問合せもしたくない。(変更があるから)
などを考えると、
どうしても数エントリごとに1回はモードを切り替えないとうまくいかないので、
エントリをたくさん返すのは重い処理になります。
FSは「全部任せろ！」という設計思想なのに、
.NetのGetFiles/GetDirectoriesはいろいろやってくれちゃっていて、
ネタ好きさんと同様に好きではありません。
矛盾を感じます。
■No17596 (す さん) に返信
> ところで、この呪いに対するアプリ側のスマートな対策はないもんでしょうか？
> 二重に自分でフィルタリングするのはどうも不細工で。。。
> ヘルプに模範コードを書いてほしいけれど無理なのかも。
FindFirstFileなら、問題はありませんから、
これも同じ問題ですよね。
DirectorySeparatorなど、OSがサポートしない文字が含まれていないことを確認したら、
そのままFindFirstFileに渡してくれるだけでいいのに、と私は思います。
違うプラットフォームとかを考えてるのかもしれませんが。
> と言う事は一番パフォーマンスが望める方法は、Win32Native.FindFirstFileとかを、自分で呼び出して、
> Directoryクラスがやっている余分なユーザーモードの.NET処理を削り落とすと言う事ですね。
パフォーマンスがいいのはもちろんですが、
上記問題や、シンプルさからもそっちのほうがよい気がします。
ですが、なぜいろいろ処理せねばならなかったのか、詳細を私はまだよく検討していません。
FindFirstFileでほとんど足りるはずなんですが。
無駄なものは作らないはずで、きっと何か事情があったはずだと思います。
その事情がわからない以上、私はGetFilesを使うという方針です。
#FSDを作った身としては
#「せっかくカーネルモードで文字列マッチングまでやってるんだから使ってくれ」
#とか
#「ここまでやらせておいてまだユーザーモードでいろいろ処理しなきゃいけないなんておかしい」
#という気分ですが。
|
|
