Re: [boost] Review Request: Filesystem Library

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 
places.
 >(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 
compilation
 >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
 >filesystem format.

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 
I'm
 >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 
want
 >to similarly parse and turn into local calls, without being on a Windows
 >box.

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.

Thanks,

--Beman