Filesystem
Do-list
- Windows: さまざまなファイルはアクセスエラーなしで is_directory() させできない悪影響を与えるように思える。例えば、pagefile.sys である。directory_iterator はそれらのファイルを無視するべきか?
- Windows: //share スタイルパスのさらなる解析と system_complete() のテストケースが必要である。
- Windows: directory_itorator がワイド文字ファイル名に遭遇したとき何が起きるか?テストケースを書く必要がある。
- Windows: Some files seem to be poisoned to the point where you can't even
do is_directory() on them without an access error. For example, pagefile.sys. Should directory_iterator ignore these files?
- Windows: //share style paths need more analysis and test cases for system_complete()
and complete(). Also, path_test cases at line 410 need review, correction.
- Windows: What happens when a directory_itorator encounters a
wide-character filename? Write a test case.
- 一般的なパスをカレントディレクトリに付け加えるか?1 つか別のテストケースを追加。
- Mac など他のオペレーティングシステムに移植するための手助けを要求。
- Add "." current directory to generic path? Add test cases one
way or the other. Change simple_ls accordingly.
- Ask for help porting to other operating systems, such as the Mac, etc.
- システム精査を完了し、いろんな OS でそれを実行してもらうように Boost people に要求する。
- 移植ガイドと機能確認の完了。Boost や他の検査のデフォルト意見を入手する? POSIX か? Windows か? Mac か? ISO 6990 か?ドキュメントで機能確認。
- Operations_test 171 行目 - なぜイテレータタグだけを確認するのか?なぜ割り当てないと駄目なのか、それとも別の理由か?
- stream (*this) 型を返す fsteram 機能をラッパーさせることはラッパーされた型 (例えば boost::filesystem::ifstream よりはむしろ std::ifstream) の取得を無視されなければならない。重要であるか?用心する必要あるか?ある問題で失敗しないか?
- Finish the probe program, and ask Boost people to run it on various O/S's.
- Finish portability guide and checking functions. Get opinions on default, Boost, and other error checks. POSIX?
Windows? Mac? ISO 6990? Document the checking functions.
- Operations_test line 171 - why only check iterator tag? Why not
Assignable, etc?
- The wrapped fstream functions which return the type of the stream (*this)
would have to be overridden to get the wrapped type (boost::filesystem::ifstream
rather than std::ifstream, for example). But does it matter? Does anyone care?
Will any programs fail?
© Copyright Beman Dawes, 2002
Revised
04 January, 2003