Strangly enough boost::filesystem works activly against this by enforcing that you use "portable" filenames (unless you specificly turn it off).
Exactly. In many cases, making a completely portable application goes beyond compilation and includes the form of the data -- namely the file paths. There are many applications where the developer wants to ensure that the paths will work on all platforms without having to actually test on them.
Can you give an example of such an application because I have difficult to picture an application that will on purpose not accept all paths that are valid on the operating system where it runs. The only use I can see is that you at run-time can ensure that some application generated paths (e.g. path(root / "mysubdir")) are portable but why base an entire library on such a small thing.
Why would I want to force a windows user to only enter filenames that are portable?
That works for your application, but not for others. You are taking user input and want native paths. I think this option is clearly documented in the library.
as above. Why would an application work with paths that don't come from user input or a configuration file.
From a user perspective native_file_string() is portable while string() isn't since it doesn't present the path in a way that the user recognize. Perhaps they need to be educated
I saw the smiley but don't understand if you agree or not.
Same thing with wide-character filenames. Why should boost::filesystem::path care if the path it carries is in a std::string or std::wstring? The wide- character filesystem operations can be difficult/impossible to implement on some systems but so are probably other operations. The alternative today is to not use boost::filesystem at all.
This is simply a question of timing. Beman had been working on a wide string extension for the library. I don't know where it stands, but clearly his intent is to add this capability. My understanding is he is recovering from an illness and is not following the list at the moment.
From the FAQ: "Wide-character names would provide an illusion of portability where portability does not in fact exist. Behavior would be completely different on operating systems (Windows, for example) that support wide-character names, than on systems which don't (POSIX). Providing functionality that appears to provide portability but in fact delivers only implementation-defined behavior is highly undesirable. Programs would not even be portable between library implementations on the same operating system, let alone portable to different operating systems."
From that I understood that wide-character support is against the portability philosphy and will not be implemented. Didn't know that someone is working on it.
Add to that the possibility to only iterate over specific files like "*.txt". Only the filsystem knows if "file.TXT" matches "*.txt" so the directory_iterator can't be used for this simple case
Search the developer mailing list for 'globbing iterator' and you should find links to a package that does this. It's not officially part of boost, but I think the author was planning on trying to include it.
As I said: 'Only the filsystem knows if "file.TXT" matches "*.txt"'. No external function can work it out by just looking at the filename. One example: Under Win32 you can have both case insensitive and case sensitive files even in the same directory (depending on a POSIX_somthing file attribute). AFAIK the only way to know which files matches "*.txt" is to pass "*.txt" to "FindFirstFile" but the directory_iterator always uses "*". I assume the situation is the same if you mount some case-insensitive filesystem under posix.