This discussion started off with various questions, including the following:
1) Why does it implement any restrictions, by default, on what kind of files it allows?
2) I don't understand why boost::filesystem wants to restrict me to a set of filenames
that are portable
But the discussion quickly changed to deal with how to support more complex
"portability" schemes. I think that's important once a more basic question is
answered: What is the rationale for trying to achieve a portable path in the first
place and what are the use-cases where such a portable path is useful, and cannot be
solved by better means? I tried to think up such use cases, but in those I could
think up, I think the "need" for a "portable" path is flawed. In our own use of the
filesystem paths, we always use native paths, and read in values from configuration
files. It's simply not practical to expect the user to provide a relative path from
wherever the program is installed somewhere in "C:\Program Files", to C:\Log or
something of this sort.
I can consider several situations or use-cases:
1) A programmer hard-codes a path into the source. So this is to prevent him from
hard-coding a non-portable path, helping ensure that the resultant program will be
portable. However, if the programmer was concerned about portability in the first
place, he would place paths in configuration files, so that they could be
configurable. If he isn't concerned about portability, then nothing will prevent him
from hardcoding a path and using boost::filesystem::native.
2) A programmer reads paths in input from the keyboard, or elsewhere, such as
File->Open. However, this is not inherently non portable. Depending on the operating
system where the code is run, "File->Open" or equivalent will/should return a proper
native path for that system. The code itself is still portable.
3) Program data files are placed on various directories relative to the program's
executable directory, and the program uses relative paths to its executable directory
to access those data files. But the actual relative paths will usually be different
for different operating systems anyhow. "c:\program files" as opposed to /usr/local
or /bin. In fact, it might even be different for a single operating system but
different installation setup (for example, "d:\program files", and even though I am
less acquainted with unix, I'm sure that there are similar examples in unix). The
right thing in my opinion is to put these into configuration files or (in Windows) the
registry and read them when run.
Of course, in that case, the configuration file path would have to be specified, since
it's probably in a configuration directory and not where the executable resides. But
the question of how to figure out the configuration file's path isn't going to be
solved by forcing portable pathnames. In fact, the question of whether to read it
from a file is itself system specific, because on windows, you'd most likely want to
read it from the registry. And if it's not in the registry, it's probably hidden in
some "Application Data" directory or what not. On unix it might be in the user's home
directory ("~/.programrc") or someplace similar. In order to deal with this the
programmer will have to code non-portable code anyhow, compiling a
"windows_configuration_data_reader.cpp" in windows and a
"unix_configuration_data_reader.cpp" in unix. Or it might be just more easily solved
by passing the configuration pathname location as a program argument.
4) Paths from one system are serialized over a stream (file, tcp/ip, etc) and read on
another system. But who is to say that the path, even if it conforms to concepts of
portability, will be valid on that other system? Consider the examples above for
"c:\program files" vs. "d:\program files" vs /usr/local.
My feeling from all these examples is that a path string is inherently specific to the
system for which it was specified, and can't really be ported to anywhere else. Much
like a string is usually inherently specific in its encoding to the system-specified
encoding. However, the filesystem library can provide a portable way to manipulate
this system specific path, much like the string library provides a portable way to
manipulate the system-specific encoded string. In view of this, why try for a
"portable path" at all?
Yitzhak
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
