"Martin" <adrianm@touchdown.se> wrote in message news:loom.20051228T091806-138@post.gmane.org...
1. Why "directory_iterator->exists()" instead of "exists(directory_iterator)"
If an "exists(directory_iterator)" overload was supplied, it would be really easy to write "exists(itr)" when you meant "exists(itr->path())". Functions with different semantics should have different syntax. At least that was the theory.
2. Any chance of having a non-throwing version of directory_iterator (similar to status). Since such a common error like not having access to a directory throws an exception, every directory_iterator construction needs a try/catch. The recursive_directory_iterator is kind of useless since it will stop as soon as you get an "access denied". (Maybe a portable can_be_iterated function can be added)
Hum. Worth considering. Aside: I'm fascinated with the idea of non-ignorable error codes. With a constructor, the code would have to be by argument rather than return.
3. The documentation doesn't say how other_flag is supposed to work. If an implementation adds more flags, will other_flag be set for these?
I don't know. Haven't given it any thought yet.
4. A suggestion is to overload exists, is_directory etc for status flags and let the error condition be statusflags == 0. (or make status_flags a class with a bool conversion)
In the code you could then write like
if (status_flags s = status(path)) { if (!exists(s) || !is_directory(s)) cout << "bad directory"; } else cout << "error";
In the current implementation you need to remember if you should use == or & when checking the status flags.
status_flags s = status(path); if (s == error_flag) // must test with == here cout << "error"; else if ((s & directory_flag) == 0) // must test with & here cout << "bad directory";
Interesting idea. POSIX does something similar with macros. I'll give it some thought. Thanks for the comments, --Beman