|
Boost : |
From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-03-16 13:25:46
"Martin Adrian" <adrianm_at_[hidden]> wrote in message
news:loom.20060310T081501-996_at_post.gmane.org...
> 1. The exception specifications are not clear
> - All predicates (exists, is_*) will throw on errors but you need to look
> into
> the status functions to see it.
Yes, the predicates do throw exceptions, and if you don't want that
behavior, you would have to use the status functions. The thought is that it
providing non-throwing versions of each of the status functions isn't worth
the added convenience. I'm already worried about the size of the library.
> - What happens if an error occurs while iteratoring a directory
There is a non-throwing constructor available, but currently operator++ does
not have a non-throwing version.
>or when the recursive iterator can't descend into a sub-folder.
That case is treated as an empty sub-folder.
> 2. Why not include the system_error code in the file_status object?
Turn the question around. Why would it be desirable to include a
system_error code in the file status? I'm not seeing any real advantage -
perhaps I'm missing something?
> If you want to avoid exceptions with the currenct code you need to write
> code
> like:
>
> system_error_code ec;
> file_status f(status(p, ec));
>
> if (exists(f) && is_directory(f))
> ..
> else if (status_known(f))
> cout << "path is not a directory";
> else
> cout << system_error_message(ec); // can't find this function in the TR2
>
> and
>
> // I don't care what the problem is.
> system_error_code ec;
> if (is_regular(status(p, ec)))
> ...
>
> Which is kind of messy since the ec and f can't be scoped. It also seem
> strange that you need to define a system_error_code variable just to avoid
> exceptions.
>
> With a file_status object defined as
>
> struct file_status {
> explicit file_status(file_type v = status_unknown, system_error_code e =
> 0);
> file_type type() const;
> system_error_code error_code() const;
> std::string system_error_message() const;
> operator safe_bool() const { return ec == 0; }
> };
>
> the code can be written as:
>
> if (file_status f(p, std::nothrow_t))
> if (exists(f) && is_directory(f))
> ...
> else
> cout << "Path is not a directory";
> else
> cout << f.system_error_message();
>
> and
>
> if (is_regular(status(p, std::nothrow_t)))
I assume you meant "std::nothrow" rather than "std::nothrow_t".
If you provide "system_error_code nothrow;" somewhere, then you can already
write that. All we are talking about is the spelling of "nothrow", it seems
to me.
> 3. Why not differentiate storage type and interface type in the basic_path
> class?
Not sure what you mean. Could you give an example?
Thanks,
--Beman
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk