Re: [boost] Re: [filesystem] Operations predicates

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-05-04 09:36:58

From: "Beman Dawes" <bdawes_at_[hidden]>
> "Rob Stewart" <stewart_at_[hidden]> wrote in message 
> news:200505031500.j43F05Z2022575_at_weezy.balstatdev.susq.com...
> > From: Beman Dawes <bdawes_at_[hidden]>
> >>
> > 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_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;