From: "Beman Dawes" <bdawes@acm.org>
"Rob Stewart" <stewart@sig.com> wrote in message news:200505031500.j43F05Z2022575@weezy.balstatdev.susq.com...
From: Beman Dawes <bdawes@acm.org>
There's no mention of what exception is thrown for each of the is_xxx functions.
basic_filesystem_error<>.
OK, but I was suggesting that it would be helpful in the table.
I don't like the status()/symlink_status() split. How about overloading like this:
struct follow_symlink_t { }; extern const follow_symlink_t follow_symlink;
status_flags status(path const &); status_flags status(path const &, follow_symlink_t);
Client code will then always call status(), but will sometimes add follow_symlink. I think it reads better. (An OS that doesn't support symlinks can simply make the latter call the former.)
That seems more confusing than just having two separate functions.
I don't see how this if (symlink_flag == status(p) && directory_flag == status(p, follow_symlink)) is confusing, and this if (symlink_flag == symlink_status(p) && directory_flag == status(p)) is less so. With my suggested syntax, you're always asking a question about the supplied path if you don't add follow_symlink. The follow_symlink overload should, though I failed to mention it previously, ignore follow_symlink if the path is not that of a symlink. That does mean that getting the behavior of your status(p) means calling my status(p, follow_symlink) all of the time. Assuming that might be the normal desire -- a good assumption I think -- then I have the overloading wrong, and that may be what you thought was confusing. How about this instead: struct shallow_status_t { }; extern shallow_status_t shallow; status_flag status(path const &); // follows status_flag status(path const &, shallow); // doesn't follow (It occurred to me that including the term "symlink" is limiting since not all OSes have "symlinks" that have (at least partly) analogous concepts. That means naming the function "symlink_status" is similarly limiting.) -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;