|
Boost : |
From: Ken Hagan (k.hagan_at_[hidden])
Date: 2002-01-30 09:20:22
From: "Jason Stewart" <res0054p_at_[hidden]>
>
> I know of no cross platform functions for doing this. Microsoft
> has a _splitpath function which is painful to use well. An earlier
> poster stated that everyone and their pet yak had implemented this
> functionality. This implies a general need.
But does nothing to prove that the need can be met.
> Again, you are talking about writing data. Tell me how to write
> the resource fork for a "foo" file on the Mac there is more to
> it than just writing ".foo" to a file.
My point exactly. Being able to generate a filename is not enough.
> If I were to specify a file called "myfile.foo" then it is just
> as valid on the Mac as it is on the PC. It does not matter what
> type the file is.
By constrast, if you "file" is a member of a partitioned dataset
on an IBM mainframe, it is not valid.
> No one has talked about writing an OS specific class. We have
> talked about policies that know how to interpret OS specific
> paths but the system should be cross-platform.
My point again. I've seen nothing in this thread that makes me
believe that the concept of "path" is meaningful on all systems.
That's why I keep asking about obscure cases.
Let's assume I have a string that names a file on a given system.
What range of purely textual operations can I perform on that
string and still be certain that the result is a legal filename
on that same system?
I can't add characters, since there will always be limits and those
limits generally depend on the file system (not the OS). I can't
change characters because the set of legal characters in a filename
is also system dependent. My options are really very limited unless
I am willing to restrict myself to particular subset of file systems
or operating systems. (At that point, I would make my point that
OS-specific solutions exist.)
If there are no portable, safe changes that I can make to the string,
why would I want a portable parsing library?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk