[boost] Re: [filesystem] Operations predicates

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-05-03 19:50:43

"Rob Stewart" <stewart_at_[hidden]> wrote in message 
news:200505031504.j43F48eL022587_at_weezy.balstatdev.susq.com...
> From: "Peter Dimov" <pdimov_at_[hidden]>
>> 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