From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-08-03 14:12:24
At 06:50 PM 8/2/2002, Alex Rosenberg wrote:
>* The line endings don't seem consistent. I see 0xD,0xA,0xA in some
>(This could be an artifact of the unzip program I used.)
They are inconsistent. I was holding off fixing them because there is a
general fix for all Boost libraries in the works, but maybe I'll go ahead
and fix these now in the sandbox.
>* All the conditional compilation makes it hard to read.
Agreed, but the only alternative I could see was to have separate POSIX and
Windows implementation files, and this seemed a poor approach when most of
the contents are identical.
>* The validation and parsing rules seem unified and tied to the
>host. Inheritance may be of use here? (class posix_path : path, etc.) The
>compilation host only controls which APIs are used to talk to the
>filesystem, not how paths are parsed or names are validated for a given
I think you may be mixed up several separate facilities.
The validation facilities (which still need some work) are completely
independent of the compilation host. Thus you can validate that a name is
valid for system A even though you are running on system B.
The portable generic grammar, and thus the parsing rules for it, is the
same on all systems, so never changes regardless of the compilation host.
The only thing that changes from system to system is the "system_specific"
path constructor. Even for cross-platform compilation, that would seem be
better handled by macros rather than burdening all users with something
needed only by a tiny percentage of users.
>There is no untar implementation for Classic Mac OS that preserves long
>filenames properly, so I'm writing one. Tar contains POSIX paths, which
>parsing and turning into local filesystem calls. The local system is not
>POSIX; it's Classic Mac OS. I want POSIX path parsing, not the local
>filesystem. Other file formats might store a Windows path that I would
>to similarly parse and turn into local calls, without being on a Windows
A side-effect of the portable generic format being the same as POSIX is
that you can use filesystem::path to perform that conversion, at least for
relative paths, which are what is likely found in such archives. Likewise
with Windows relative paths all you have to do is change any '\' characters
to '/' and you are in business.
>Tiny XML is a very promising start. I've never been too happy with the
>Xerces object model.
It is just an implementation detail of the status reporting system; it
isn't really part of the Filesystem Library. I wouldn't be surprised if
the Spirit parser about to come up for formal review makes such
hand-written little parsers obsolete.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk