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