[boost] Re: Re: [Filesystem] i18n

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-04-07 17:23:12

"Peter Dimov" <pdimov_at_[hidden]> wrote in message 
news:003501c53b4b$8b6a1b60$6501a8c0_at_pdimov2...
> Beman Dawes wrote:
>> I agree to the extent that some of the cases when the current
>> implementation throws can be eliminated. For example, is_directory()
>> can safely be changed to return false rather than throwing in the
>> case of a non-existant path. (And we would add a similar is_path()).
>> But I just can't convince myself that silently swallowing an I/O error 
>> would be safe And given the
>> plan to add a status() function which can provide error swallowing 
>> behavior, a
>> programmer can get that behavior if really, really, required.
>
> I find it much more natural for stat() to throw:

Rob's suggestion was that the function have an argument enabling or 
disabling throwing.

>    attributes stat( path const & p );
>
> because on error it can't return a valid value.

Sometimes some of the attributes are known, depending on the exact error. So 
if the attribute bits include both "exists" and "does not exist" bits, then 
in the face of an error it is still possible to know if one of those 
attributes is known.

I'll try to get a spec together for comment, but it will be awhile.
>
> If you fix the original defect that directory iteration only gives names 
> without attributes, the use of is_directory in iteration loops will be 
> eliminated. We'll then be left with its other uses, which may be easier to 
> analyze.

How would you do that? Change the directory_iterator value_type to 
std::pair< path, attributes >, or leave directory_iterator alone but provide 
a stat() overload taking a directory_iterator (which presumably has the 
attributes cached on systems which provide attributes automatically during 
directory iteration)?

--Beman