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.