Boost logo

Boost :

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 message
> seems to have vanished...any clues where it might be?


--- 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
> removing /./, making all slashes point the same way etc.). It then
> 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)

as opposed to


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

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.


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

Do You Yahoo!?
Get your free address at

Boost list run by bdawes at, gregod at, cpdaniel at, john at