From: Rob Stewart (stewart_at_[hidden])
Date: 2005-05-03 10:00:05
From: Beman Dawes <bdawes_at_[hidden]>
>
> I've completed an analysis of expectations for the exists() and is_xxx()
> family of functions, and the previously suggested status() and
> symlink_status() functions.
>
> See http://www.esva.net/~beman/filesystem_operations_predicates.htm
I like that you specify the behavior of the is_xxx functions in
terms of status(). That reduces the complexity of specifying the
is_xxx functions.
There's no mention of what exception is thrown for each of the
is_xxx functions.
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.)
The Effects sections are a little awkward to read because of all
of the "Otherwise, if"s. Perhaps something like this would work:
Effects: Queries the operating system to determine the
attributes of path p. If p is a symbolic link, the link is
resolved (that is, deep semantics). If the attributes indicate
that p is a directory (see expectations), it returns
directory_flag. If the attributes indicate that p is a file,
it returns file_flag. If the query results in an error
indicating that p could not be found footnote, it returns
not_found_flag. If the query results in any other error, it
returns error_flag.
What about the other attributes that one can get from many
(most?) OSes? Shouldn't status() report on read only, for
example? The good news is that the status() I/F is extensible.
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;