From: "Beman Dawes" <bdawes@acm.org>
"Martin" <adrianm@touchdown.se> wrote in message news:loom.20050330T110611-38@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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;