Boost logo

Boost :

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-24 15:39:38

From: Jani Kajala [SMTP:jani_at_[hidden]]
> > - I suppose it is reasonable to allow for ".", "..", and "/" in pathname
> > strings as standard notation that might get translated into
> > platform-specific delimiters, but I wonder how folks that work on other
> > platforms would feel.
> Could you explain more what you mean? I don't see any problem in using
".", ".."
> or "/" with the path class.

DOS/Windows platforms use "\", not "/" as a path separator. In practice,
many versions of Windows will accept "/", too, but users of those systems
are accustomed to using backslashes. Other OSes use ":" as the path
separator (Vax, I think, maybe others). I don't know how universal "." and
".." are among the various OSes. So, if someone uses a system where ":" is
the path separator, "<" means parent directory, and "@" means current
directory, you can imagine their trouble when using a component that
requires them to use "/", "..", and "." instead.

> > - I don't understand what an "abstract" pathname is.
> 'Path name' can be the name of a file or a directory. The name is
'abstract' in
> a sense that it might not be even valid file/path name for given platform.
> Example: Windows/DOS does not support '/' as separator, even though every
> library on the platform happens to do it for compatibility. I think it is
> to make distinction which is platform specific name and which isn't.

Ah, I see. My suggestion to separate pathname modification separately from
an filesystem access would account for that, don't you think? IOW, when you
work with a pathname object, it is always "abstract." When you are ready to
deal with the OS, then the file or directory class will translate from the
pathname class' format to the OS-specific representation.

> > - In Unix, files have suffixes, not extensions, so I wonder whether
> > should be a "suffix" mf, too.
> suffix() actually sounds better, and it's shorter too. Maybe extension()
> be replaced with suffix().

Yes, but then you'd have those DOS/Windows programmers asking, "What's a

> > - There are more attributes available, via stat(), under Unix than you
> > accessors for. What if I want to know whether the sticky bit is set?
> struct stat buf;
> stat( p.norm_path().c_str(), &buf );
> ...

That is certainly possible, but you had to stat() the file to learn whether
it exists or whether the pathname is a dictionary. Why stop there?

> > - There is no information available on file permissions.
> Neither has C or C++. :)

C and C++ have no notion of directories as distinct from files, nor of
pathnames either. That hasn't stopped you from proposing to add these
facilities. So, my question is why you want to represent only a portion of
the domain.

> > - "list" is poorly named; how about "subdirectories?"
> list() does not list only subdirectories, it lists all files also (it does
> recurse).

I see. You mean "list" as in directory listing. The problem is that only
applies to a directory, so it should be in a directory class, not the
pathname manipulation class.

> > - Accepted terminology for pathname components are: pathname, filename,
> > basename, extension/suffix, parent, child, subdirectory.
> 'Accepted' depends much from the point of view. I find name() more
> than basename(), maybe because file/path names make up a hierarchy, and if
> think of 'base class'... You probably get my point.

Does "name" include the path? How about the suffix/extension? "name" is
ambiguous. "basename" clearly refers to the last component in the pathname
less any suffix/extension. "pathname" is the entire thing that has been
built. "filename" is the last component in the pathname, regardless of
whether it refers to a directory or file (which are the same in many

> > - "norm_case" should be a variant of "abstract." That is, "abstract"
> > be overloaded or have a default parameter that controls whether to
> > the pathname's case.
> Uh? As the documentation says, 'normalized' path names are platform
> 'abstract' path names are not. Maybe the documentation about used
> should be clarified? Besides, having different functions doing different
> is cleaner and less error prone. Or what about C realloc...

If the platform-specific aspects were handled separately, say using a
dos_pathname derived class, then there would be no need for "abstract"
versus "normalized." That aside, my point was that you could just ask for
the pathname and indicate, via a parameter, whether it was to be "abstract"
or "normalized."

> > - In DOS/Windows, pathnames are case insensitive, but they are stored in
> > upper case, so "norm_case" returns the wrong case. Other case
> > platforms may conventionally use lower case, so this should be
> The whole idea of norm_case is that by using the function you know what
case it
> will return if the platform does not make a difference between uppercase
> lowercase. I think there is no 'right' or 'wrong' casing here.

If you're going to account for platform-specific case issues, then the
platform-specific programmer has the right to work in terms of that
platform's norms. The case should be based upon the norms of the platform,
not a one-size-fits-all approach. That is, instead of deciding that all
lower case is what you get for non-case-sensitive filesystems, you should
return all upper or all lower case, depending upon the norms for that

> > - I don't understand what "norm_path" does that "abstract" doesn't. (I
> > know what either function does.)
> norm_path converts the path name to platform-dependent form -- in
Windows/DOS it
> converts forward slashes to backslashes.

This should be done in a separate file/directory class or via a
platform-specific derived class so all accesses are platform specific.

> > Instead, why not separate path manipulations from file/directory
> Because you can't completely separate those. For example how can you
> absolute path name of "./" without accessing file system in any way? Of
> you can consider absolute paths as 'file operation' but there would be not
> much use for path name manipulation without such basic functionality.

I don't understand your point. I can create a pathname based upon the
current directory (by asking a directory class for the current directory)
and then adding to or subtracting from that pathname. Whether the result is
a valid pathname in the filesystem is a separate issue, the answer to which
I'll get when I try to open a file (fstream, etc.) object using that

See Jan Langer post on this point of separating concerns into separate

> For other references about path manipulation, see for example
> and the Python link which Dave posted. I think you find functionality of
> path class very much similar to approach taken by those languages (it's
not a
> coincidence of course). I think it is important to try to avoid
reinventing the
> wheel here.

I have no experience with either of those approaches to files and pathname
manipulation, but reinventing the wheel is appropriate if there's a markedly
better way to make it.

Susquehanna International Group, LLP

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