Re: [boost] Vanished message! (was Re: pathname manipulation)

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2002-02-02 02:54:30

From: "mfdylan" <dylan_at_[hidden]>
Sent: Saturday, February 02, 2002 3:10 AM
> --- In boost_at_y..., "Anthony Williams" <anthony_w.geo_at_y...> wrote:
> 
> I replied to this but was logged in as the wrong user...my message 
> seems to have vanished...any clues where it might be?

Here:

--- In boost_at_y..., "Anthony Williams" <anthony_w.geo_at_y...> wrote:
> From: "mfdylan" <dylan_at_m...>
> Sent: Friday, February 01, 2002 1:02 AM
> >
> > assert(p.dirname() == "/home.dylan");
> > assert(p.dirname().dirname() == "/");
> > assert(p.dirname().suffix() == ".dylan");
> > assert(p.suffix().suffix() == ".cpp.keep");
> > assert(p.basename(".1").basename(".keep") == "file.cpp");
> 
> I like the idea of this sort of thing. The PathName class I use 
takes a
> filename, and converts it to cannonical form form internal storage 
(e.g.
> removing /./, making all slashes point the same way etc.). It then 
supports
> extracting path components, and building a new path from separate
> components. I think changing a path in-place is a no-goer, as Dylan
> suggests --- what consititues the suffix?
> 
See my other recent post, showing why in-place modification can be a 
definite advantage.  I agree it's not strictly necessary.

> 
> I also have a separate FileInfo class that accesses the filesystem 
to check
> for existence/type/size/permissions etc. for a file. It could be 
extended to
> compare PathNames --- are they the same object? --- where by 
default this is
> just a simple comparison, but on File Systems with links, it could 
check the
> inode (or something).
> 

I definitely think separating pathname manipulation functions from 
file-system functionality is the way to go, despite having combined 
them in my own code, and enjoyed the convenience it gives!
What I'm not sure of is whether it's better to have a 'filesystem' 
class/namespace with all the POSIX functions like:

access chdir chmod chown getcwd mkdir rename remove/unlink stat 
truncate etc. etc.

That can take 'pathname' objects or strings, or whether it's better 
to have a "file" object with its own pathname that can represent an 
actual file (although it needn't exist) for which the above relevant 
functions are members.  The latter is probably more 'OO' in the C++, 
sense, but leaves things like chdir/getcwd/mkdir in limbo, and often 
means having to construct an object simply to do a delete:

void foo(const pathname& pname)
{
   ...
   file(pname).delete();
}

as opposed to

filesystem::delete(pname);

On the other hand POSIX has a lot of 'double-up' functions where one 
acts on the filename, the other acts on a file descriptor, which 
would be nice if you could access through the same object.

Some extra functionality I definitely want on top of POSIX:

copy()    // read in whole file and write out elsewhere
exists()  // = access(name, 0) == 0
move()    // try rename, if fails, then copy & delete
readable() // readable by current user
writeable() // writeable "
executable() // exectuable "
modified()/accessed() // NB windows resolution is < seconds 
size()

These are all things I've personally needed for cross-platform 
software (POSIX and windows only), fortunately MSVC implements most 
of the standard POSIX functions (*), although the functions that deal 
with file permissions are not well done (it's not particularly hard 
to implement chmod or chown etc under Win32, but MS obviously didn't 
think it was worth doing.  Their chmod() can only be used for setting 
the readonly attribute, and chown() they just didn't bother with.)
But even on a POSIX system some of the above require more than a few 
lines of code.

Dylan

(*) Out of curiosity do all other popular Windows C++ compilers do 
the same?  Presumably you can always use MS's runtime library 
anyway...


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com