Boost logo

Boost Users :

From: Martin (adrianm_at_[hidden])
Date: 2004-08-18 09:41:19

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

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()
>> 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
> 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

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

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at