Re: [boost] Re: Re: [Filesystem] i18n

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-04-07 17:44:35

Beman Dawes wrote:
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> news:003501c53b4b$8b6a1b60$6501a8c0_at_pdimov2...
>> 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)?

I've given it some thought, but I think that you are in a better position to 
choose between these alternatives than I am. Although I'd say that the first 
option should use a struct { name, attributes, [size...] } value type and 
not a pair with its nondescriptive first/second members and no room for 
future extensions.

An is_directory( i ) overload is certainly less intrusive in that it allows 
us to keep the current iterator intact. But (a) is_directory( i ) and 
is_directory( *i ) are too close to each other and the users may mistakenly 
use the second form when they mean the first, and (b) I'm not sure whether 
we should strive to keep the current iterator.

The reason I don't feel confident in choosing an alternative is that I don't 
know how important it is for the value_type of the iterator to be a path.