Re: [boost] Re: [Filesystem] i18n

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-03-31 09:56:09

From: "Beman Dawes" <bdawes_at_[hidden]>
> "Martin" <adrianm_at_[hidden]> wrote in message 
> news:loom.20050330T110611-38_at_post.gmane.org...
> >
> > I also had hopes for some new things that didn't appear in the new
> > implementation.
> > - non-throwing is_* functions. I find it very inconvenient and error prune 
> > to
> > put try/catch around each is_directory call. Calling is_accessible before
> > every other is_* function is an option but not much easier and still 
> > leaves a
> > risk for an exception if another process is accessing the file.
> 
> If the is_* functions return false, rather than throwing, then testing for 
> the negative of a is_* function becomes unreliable. Does !is_directory( 
> "foo" ) mean that "foo" is a file, or is is just missing? The programmer 

Why should it answer both questions?  It means it isn't a
directory.  If you want to know more, ask other questions like
is_socket("foo"), exists("foo"), etc.

> > My suggestion is to add non-throwing overloads where a second parameter 
> > tells
> > what the function should return in case of error. e.g. is_directory(path,
> > true).
> 
> Interesting. That would cover my example about of wanting to detect a file. 
> The expressions would be written !is_directory("foo",true). But that seems a 
> bit obscure to me, and likely to be a cause of coding errors. Hum... it 

It's also unnecessary.  To detect a file, you'd write
is_file("foo").  (How you implement is_file() is another matter.)

> isn't even correct in the case a directory exists but is not accessible An 
> alternative would be named functions. These would be the so called 
> "compound" functions which were discussed at one time, but that gets really 
> messy. Where do you stop?

Compound functions are appropriate when you throw away
information that you otherwise get in one or two OS calls, such
that the query becomes atomic.  However, you don't have to have
separate functions for each combination.  Instead, you could
define a series of properties that can be queried -- most likely
as an enumerated type with binary values -- that can be bitwise
OR'ed to get the set of properties the caller wants you to
query.  If all such properties are set, then the function returns
true.

Such an approach means many current functions might be
implemented in terms of the omnibus function, and it means that
library users can define domain-specific, useful queries into
named functions of their choice.  You don't have to supply
everything that way, but you supply the means to do so.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;