Re: [boost] [filesystem] Some comments

From: Martin Adrian (adrianm_at_[hidden])
Date: 2006-03-17 15:31:58

> 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.

I am not worried about the exceptions. What worries me is that it is not clear 
which functions will throw and when.

When I first started to use the library a long time ago I got the impression 
that exceptions were rare and came from filesystem corruption and racing 
conditions. Over time I have learned that filesystem exceptions are common and 
happens all the time also for trivial operations like exists and directory 
iterations in a perfectly helthy environment.

When reading the new documentation I still get the same impression. Exceptions 
are mentioned together with std::bad_alloc and "cannot successfully complete 
their operational specifications". Examples don't show exceptions or as 
in "simple_ls.cpp" only handle them in random places without explanations.

> 
> > - 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.

No problem, just say in the documentation that operator++ might throw.
(unfortunatly it makes the non-throwing constructor kind of useless since you 
still need a try/catch)

> 
> >or when the  recursive iterator can't descend into a sub-folder.
> 
> That case is treated as an empty sub-folder.

OK

> 
> > 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?

You get both the status and the system error from the same function. Why not 
keep them together so you don't have to use two variables all the time.

I get a feeling that you still think exceptions are rare and that is not 
common to write code to handle or avoid them.

> 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.

No, I'm trying to avoid extra variable declarations that I think make the code 
more difficult to understand. Using std::nothrow make the intention clear. 

Using a variable named nothrow will only add confusion.

> 
> > 3. Why not differentiate storage type and interface type in the basic_path
> > class?
> 
> Not sure what you mean. Could you give an example?

The path need a storage type with some requirements (basic_string interface?). 
I don't see why the interface must use the same type.

Lets say I want to store a path in shared memory and use a string with an 
shmem allocator. The effect is then that I can only use operations on the path 
with strings stored in the same memory area.

In short: Let the constructor, assign and operators always work on 
basic_string types regardless of what the storage type is.
something like
template <class TratitsT, class AllocatorT>
basic_path(basic_string<CharT, TraitsT AllocatorT>& str)
  : m_path(str.begin(), str.end()) { }