1. Why "directory_iterator->exists()" instead of "exists(directory_iterator)" 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) 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? 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";
"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
Beman Dawes wrote:
"Martin" <adrianm@touchdown.se> wrote in message news:loom.20051228T091806-138@post.gmane.org...
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.
:-) That's also what I asked when other_flag was proposed.
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:002101c60ca9$fbd7fb80$6407a8c0@pdimov2...
Beman Dawes wrote:
"Martin" <adrianm@touchdown.se> wrote in message news:loom.20051228T091806-138@post.gmane.org...
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.
:-)
That's also what I asked when other_flag was proposed.
Ah, yes! The discussion is coming back to me. I'll try to review some of the past postings. --Beman
If an "exists(directory_iterator)" overload was supplied, it would be really easy to write "exists(itr)" when you meant "exists(itr->path())".
I assume you mean exists(*itr) instead of exists(itr->path())
Functions with different semantics should have different syntax. At least that was the theory.
Don't agree in this case but it is your library. :-)
Is the litter just to deal with exceptions coming out of directory_iterator constructors? Or are there other use cases needing excessive try/catch blocks?
"exists", all "is_*" functions and direcory_iterator all throws on access denied so basicly a try/catch is needed for any use of these (at least for me). Sometimes I can let the exception propagate up to a top level catch handling filsystem corruption, network problems and race conditions but generally not. With the earlier code "exists" didn't throw and I created my own non-throwing overload of is_directory "is_directory(path&, bool errorreturn)" but with the new code I use status instead. Ideally for me would be the following // throws on error is_directory(const path&); // never throws (or is an implementation allowed to not cache status?) is_directory(const directory_iterator&); // don't throw and return errorreturn on error is_directory(status, bool errorreturn = false); Regarding the non-throwing directory_iterator. Couldn't the constructor return something that compares equal to the end iterator but is carrying a status member.
"Martin" <adrianm@touchdown.se> wrote in message news:loom.20051228T091806-138@post.gmane.org...
4. A suggestion is to overload exists, is_directory etc for status flags ...
This really does seem like a good idea. I'm kicking myself for not already thinking of it. Martin, what is your full name so I can give you credit in the docs? --Beman
"Martin" <adrianm@touchdown.se> wrote in message news:loom.20051228T091806-138@post.gmane.org...
4. A suggestion is to overload exists, is_directory etc for status flags ....
Status flags has morphed into a full-fledged file_status class, and, as you suggested, exists, is_directory, etc. have been overloaded. This makes user code much more readable and is much less error-prone, IMO. Thanks for the suggestion!
3. The documentation doesn't say how other_flag is supposed to work.
The docs now say: bool is_other(file_status s); Returns: return exists(s) && !is_regular(s) && !is_directory(s) && !is_symlink(s)
If an implementation adds more flags, will other_flag be set for these?
No. I'll update the docs to make that clear. Thanks, --Beman
participants (3)
-
Beman Dawes -
Martin -
Peter Dimov