[boost] Re: [Filesystem] i18n

From: Martin (adrianm_at_[hidden])
Date: 2005-03-31 02:23:16

> > The comments I have on the new implementation is:
> > - Operations are limited to std::string (and std::wstring on win32) as
> > external type. Why not allow any range of characters? Current 
> > implementation
> > will not work with const_string, flex_string and a basic_string with a 
> > custom
> > allocator.
> 
> That isn't correct. See lpath.hpp and wide_test.cpp in the test directory 
> for an example of using a basic_string<long> as the the underlying string 
> type.
Yes, you can use any string type as _internal_ type but since the external 
type must be std::string you have to supply a conversion function to  
std::string in the traits (like in your lpath_traits).
If the external type was a character range the same traits could be used for 
many string-like types and there would be no performance hit when converting.

Would also be nice if the path constructor and "/" operator worked with ranges 
so you could mix all string types with the same underlying character type.

> > My suggestion is to add non-throwing overloads where a second parameter 
> > tells
> > what the function should return in case of error. e.g. is_directory(path,
> > true).
> 
> Interesting. That would cover my example about of wanting to detect a file. 
> The expressions would be written !is_directory("foo",true). But that seems a 
> bit obscure to me, and likely to be a cause of coding errors. Hum... it 
> isn't even correct in the case a directory exists but is not accessible An 
> alternative would be named functions. These would be the so called 
> "compound" functions which were discussed at one time, but that gets really 
> messy. Where do you stop?

I assume that the most common use of the is_* function is as a filter. With an 
extra argument you specify if errors mean that the path should be excluded. 
For clarity you could use an enum like "treat_error_as_true" instead of the 
bool value.

> 
> > - The directory iterator is still very limited since you can't specify a
> > filter (e.g. "*.txt"). If used on a win32 system with a mounted posix disk 
> > or
> > a posix system with a CD problems might arise. (There is no portable way 
> > to
> > tell if "FILE.TXT" matches "*.txt").
> 
> There was discussion of a glob directory iterator at one time, but no one 
> ever came up with a final design. It is certainly a real need.

All suggestions of a glob directory iterator I have seen works only on the 
path. They ignore that fact that files can be both case sensitive and case-
insensitive on the same system.