Boost logo

Boost :

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

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

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           
Susquehanna International Group, LLP  using std::disclaimer;

Boost list run by bdawes at, gregod at, cpdaniel at, john at