"Peter Dimov" <pdimov@mmltd.net> wrote in message news:003501c53b4b$8b6a1b60$6501a8c0@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