"Rob Stewart" <stewart@sig.com> wrote in message news:200505031504.j43F48eL022587@weezy.balstatdev.susq.com...
From: "Peter Dimov" <pdimov@mmltd.net>
Beman Dawes wrote:
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
One quick comment about status(). I don't like the fact that the user effectively has to read a global variable to obtain the error code. I'd prefer something along the lines of
status_flag status( path const & p, int * error = 0 );
or packing the error code in the return value.
I also thought about that. system_error_code() can certainly be made threadsafe, and all commands can set a thread-specific error code.
The POSIX standard requires errno be thread safe: "For each thread of a process, the value of errno shall not be affected by function calls or assignments to errno by other threads." Ditto, Windows' ::GetLastError() function.
But it does mean that it is easy to ignore problems in calling status() ...
Yes, but otherwise identical functionality is available using the is_xxx() and exists() functions, which throw on errors. They would be preferred unless the program specifically needs to treat errors as non-throwing.
and that one must read the error code before calling it again.
Yes.
Perhaps the flags could be accumulated with the error code in a class that has a safe-bool conversion?
That's a possibility, although I think I like Peter's suggestion better just because it is a bit simpler. --Beman